I have got the following AVC message: type=AVC msg=audit(1200003288.583:16): avc: denied { execheap } for pid=3452 comm="beagled" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=process type=SYSCALL msg=audit(1200003288.583:16): arch=c000003e syscall=10 success=yes exit=0 a0=f04000 a1=1000 a2=7 a3=3688d529f0 items=0 ppid=1 pid=3452 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) comm="beagled" exe="/usr/bin/mono" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) because beagled is a mono application, a domain transition from the xdm_t to the mono_t domain is required.
Created attachment 293457 [details] Pwatch which allows domtrans from xdm_t to mono_t
Why would xdm_t ever run beagled. This looks like when you login you are logging in as xdm_t which indicates something far worse is going on, on your machine. You should be logged in as unconfined_t. What does # id -Z Do you have a special configuration of /etc/pam.d/gdm?
I'm using kdm for login and i thing xdm_t may be the right domain for the diskplay mananger. $ id -Z system_u:system_r:xdm_t:SystemLow-SystemHigh xmd_t in the Konsole windows??? I think, we need the domtrans to unconfined_T after the login in kdm. Best Regards:
Does the /etc/pam.d/kdm have pam_selinux in it?
I believe this is a configuration problem. Closing as notabug, reopen if you still have problems.
I have tryout gdm and kde and the domain will stall stay in xdm_t. So I want to reopen this bug.
Ok you can try relabeling. First make sure you are up to date on policy yum -y upgrade selinux-policy touch /.autorelabel reboot Login via gdm_greater and see what context you have? id -Z If you login via login or sshd what context do you have? id -Z
The relabeling of the system doesn't solve the issue.
Please attach your audit.log ps -eZ | grep xdm
Created attachment 296518 [details] The audit log this file contains the audit log
Created attachment 296519 [details] Output of ps -eZ | grep xdm Because the output of ps -eZ | grep xdm is large, I have created an attachment.
You have /dev/null labeled as etc_runtime_t? You have device files under fusefs? /mnt/winxp/SFU/dev/comport1 Can you attach /etc/pam.d/gdm
(In reply to comment #12) > You have /dev/null labeled as etc_runtime_t? No, It's labled as system_u:object_r:null_device_t > You have device files under fusefs? Yes. > /mnt/winxp/SFU/dev/comport1 /mnt/wixp is a ntfs partition. > Can you attach /etc/pam.d/gdm Of Corse.
Created attachment 296626 [details] PAM gdm configuration file
I have no idea what is going on here. It seems that you are never transitioning from xdm_t to unconfined_t. Looks like all the context are correct, gdm pam config is correct. If you login via local login or sshd what does id -Z show?
Your avc messages show /dev/null labeled etc_runtime_t? grep /dev/null in the audit.log. What file system are you using?
(In reply to comment #15) > If you login via local login or sshd what does id -Z show? $ id -Z system_u:system_r:unconfined_t:SystemLow-SystemHigh
Which is what is supposed to happen.
are you using autologin in gdm?
No.
(In reply to comment #18) > Which is what is supposed to happen. I expect the the context should be: unconfined_t
Execute # semanage user -a -P unconfined -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u If this fails execute # semanage user -m -P unconfined -R "unconfined_r system_r" -r s0-s0:c0.c1023 unconfined_u Finally execute # semanage login -m -s unconfined_u -r s0-s0:c0.c1023 __default__ Now try to login.
I have tried your suggestion. Unfortunately, I don't get the expected result. $ id -Z system_u:system_r:xdm_t:SystemLow-SystemHigh
semodule login -l semodule user -l
Your suggested commands didn't worked: # semodule login -l unknown additional arguments: login
Sorry, should have been semanage. What does the output of these commands show? semanage login -l semanage user -l
Sorry seems that you went away, I am closing this as worksforme or you can reopen if you are still having the problem.
Unfortunately, the reported issue still exist, so I will reopen this but. # export LANG="C"; semanage login -l Login Name SELinux User MLS/MCS Range __default__ unconfined_u SystemLow-SystemHigh root system_u SystemLow-SystemHigh system_u system_u SystemLow-SystemHigh # export LANG="C"; semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm s0 SystemLow-SystemHigh system_r sysadm_r staff_r staff_u staff s0 SystemLow-SystemHigh sysadm_r staff_r sysadm_u sysadm s0 SystemLow-SystemHigh sysadm_r system_u user s0 SystemLow-SystemHigh system_r unconfied_u unconfined s0 -s0:c0 system_r unconfined_r unconfined_u unconfined s0 SystemLow-SystemHigh system_r unconfined_r user_u user s0 s0 system_r user_r xguest_u xguest s0 s0 xguest_r
semanage login -m -s unconfined_u root