Keep getting AVC's when I log into multiple Fedora 14 systems with automounted home directories. Labels keep getting mucked up after logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done semanage fcontext -a -e /home /export/home. They automount to /home/<user>.
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file ---- time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/05/2010 09:09 PM, David Highley wrote:
Keep getting AVC's when I log into multiple Fedora 14 systems with automounted home directories. Labels keep getting mucked up after logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done semanage fcontext -a -e /home /export/home. They automount to /home/<user>.
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like for some reason the ~/.xsession-errors file is mislabeled. it should have been type xdm_home_t instead of user_home_t.
It seems that gdm itself did not create it but that instead some program that runs in the user domain created it.
You should first try to reproduce this issue by removing the file and see if this file gets created again with type user_home_t in enforcing mode.
When this is verified, you should see if you have a file context specification for ~/.xsession-errors:
$ matchpathcon ~/.xsession-errors /root/.xsession-errors staff_u:object_r:xdm_home_t:s0
use the path to your unprivileged user home directory instead of /root in my example.
If it is verified that something running in the user domain is creating the .xsession-errors file, then we must figure out what and why.
We can do that by loading a "auditallow" rule. for example:
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0) gen_require(` attribute domain; type user_home_t; ') allow domain user_home_t:file create;" > mytest.te;
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
(after reproducing testing remove the installed module: sudo semodule -r mytest)
(not this may cause many avc granted messages in audit.log)
Now you should remove the ~/.xsession-errors file again and reproduce the creation of it. Once it is recreated, search /var/log/audit/audit.log for avcgrants regarding xsession-errors:
cat /var/log/audit/audit.log | grep -i grant | grep xsession
That avc denial may expose some information as to which program creates it, Then a solution can be considered.
Basically a few options:
1. file was somehow just mislabled (cannot reproduce) 2. file gets created by some application running in the user domain: 2. a. can we confine this application and make it create the file with type xdm_home_t instead so that xdm_t can interact with it? 2. b. if all else fails, we can consider allowing xdm access to user_home_t typed files. 3. are we missing a boolean that can be toggled to allow this access (pipe avc denial into audit2why/ use sesearch to see if there are rules in the policy database that permit this access. 4. is something misconfigured? 5. is something buggy? 6. is this some kind of intrusion attempt?
"Dominick Grift wrote:"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/05/2010 09:09 PM, David Highley wrote:
Keep getting AVC's when I log into multiple Fedora 14 systems with automounted home directories. Labels keep getting mucked up after logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done semanage fcontext -a -e /home /export/home. They automount to /home/<user>.
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like for some reason the ~/.xsession-errors file is mislabeled. it should have been type xdm_home_t instead of user_home_t.
Agree it should be labeled as xdm_home_t.
It seems that gdm itself did not create it but that instead some program that runs in the user domain created it.
You should first try to reproduce this issue by removing the file and see if this file gets created again with type user_home_t in enforcing mode.
Remove the file and then logged back into the NFS server and the file is recreated with the proper label.
When this is verified, you should see if you have a file context specification for ~/.xsession-errors:
$ matchpathcon ~/.xsession-errors /root/.xsession-errors staff_u:object_r:xdm_home_t:s0
Verified using matchpatchcon as above.
Now log into an NFS client host and get the following: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:nfs_t:s0 .xsession-errors
ls -Zd /home/dhighley drwxr-x---. dhighley staff system_u:object_r:nfs_t:s0 /home/dhighley
ls -Zd /home drwxr-xr-x. root root system_u:object_r:autofs_t:s0 /home
Note: from above that the label for .xsession-errors is now incorrect. I would submitt that the Gnome/X11 session start is mucking the file label.
use the path to your unprivileged user home directory instead of /root in my example.
If it is verified that something running in the user domain is creating the .xsession-errors file, then we must figure out what and why.
We can do that by loading a "auditallow" rule. for example:
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0) gen_require(` attribute domain; type user_home_t; ') allow domain user_home_t:file create;" > mytest.te;
Created and installed the policy on the NFS client system.
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
(after reproducing testing remove the installed module: sudo semodule -r mytest)
(not this may cause many avc granted messages in audit.log)
Reviewing audit log on client system I only see the following logged: type=USER_AUTH msg=audit(1291776422.987:31974): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:auth entication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr =? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1291776422.990:31975): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=failed' type=USER_AUTH msg=audit(1291776434.310:31976): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1291776434.323:31977): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=CRED_ACQ msg=audit(1291776434.350:31978): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=LOGIN msg=audit(1291776434.358:31979): login pid=16804 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=72 type=USER_ROLE_CHANGE msg=audit(1291776434.501:31980): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1291776434.593:31981): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_LOGIN msg=audit(1291776434.595:31982): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=success'
Now you should remove the ~/.xsession-errors file again and reproduce the creation of it. Once it is recreated, search /var/log/audit/audit.log for avcgrants regarding xsession-errors:
cat /var/log/audit/audit.log | grep -i grant | grep xsession
Found none. But oddly this time I see: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:user_home_t:s0 .xsession-errors
That avc denial may expose some information as to which program creates it, Then a solution can be considered.
Basically a few options:
- file was somehow just mislabled (cannot reproduce)
- file gets created by some application running in the user domain:
- a. can we confine this application and make it create the file with
type xdm_home_t instead so that xdm_t can interact with it? 2. b. if all else fails, we can consider allowing xdm access to user_home_t typed files. 3. are we missing a boolean that can be toggled to allow this access (pipe avc denial into audit2why/ use sesearch to see if there are rules in the policy database that permit this access.
We do have use_nfs_home_dirs --> on
- is something misconfigured?
- is something buggy?
- is this some kind of intrusion attempt?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkz79W8ACgkQMlxVo39jgT+5VACfV6KlSAZNFfHsKTzqPmWSwB5b sZsAoIJ8mN7NTT4AyiPlgVh6gGl+pzp/ =1ga2
-----END PGP SIGNATURE-----
selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/08/2010 04:06 AM, David Highley wrote:
"Dominick Grift wrote:"
On 12/05/2010 09:09 PM, David Highley wrote:
Keep getting AVC's when I log into multiple Fedora 14 systems with automounted home directories. Labels keep getting mucked up after logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done semanage fcontext -a -e /home /export/home. They automount to /home/<user>.
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like for some reason the ~/.xsession-errors file is mislabeled. it should have been type xdm_home_t instead of user_home_t.
Agree it should be labeled as xdm_home_t.
I guess in this case it should be labeled nfs_t.
It seems that gdm itself did not create it but that instead some program that runs in the user domain created it.
You should first try to reproduce this issue by removing the file and see if this file gets created again with type user_home_t in enforcing mode.
Remove the file and then logged back into the NFS server and the file is recreated with the proper label.
When this is verified, you should see if you have a file context specification for ~/.xsession-errors:
$ matchpathcon ~/.xsession-errors /root/.xsession-errors staff_u:object_r:xdm_home_t:s0
Verified using matchpatchcon as above.
Now log into an NFS client host and get the following: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:nfs_t:s0 .xsession-errors
ls -Zd /home/dhighley drwxr-x---. dhighley staff system_u:object_r:nfs_t:s0 /home/dhighley
ls -Zd /home drwxr-xr-x. root root system_u:object_r:autofs_t:s0 /home
Note: from above that the label for .xsession-errors is now incorrect. I would submitt that the Gnome/X11 session start is mucking the file label.
It could be restorecond -u messing with it, try disabling restorecond -u in your gnome-session(s) and try reproduce it again (system > preferences > startup applications > File context maintainer (off)
use the path to your unprivileged user home directory instead of /root in my example.
If it is verified that something running in the user domain is creating the .xsession-errors file, then we must figure out what and why.
We can do that by loading a "auditallow" rule. for example:
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0) gen_require(` attribute domain; type user_home_t; ') allow domain user_home_t:file create;" > mytest.te;
Created and installed the policy on the NFS client system.
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
(after reproducing testing remove the installed module: sudo semodule -r mytest)
(not this may cause many avc granted messages in audit.log)
Reviewing audit log on client system I only see the following logged: type=USER_AUTH msg=audit(1291776422.987:31974): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:auth entication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr =? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1291776422.990:31975): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=failed' type=USER_AUTH msg=audit(1291776434.310:31976): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1291776434.323:31977): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=CRED_ACQ msg=audit(1291776434.350:31978): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=LOGIN msg=audit(1291776434.358:31979): login pid=16804 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=72 type=USER_ROLE_CHANGE msg=audit(1291776434.501:31980): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1291776434.593:31981): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_LOGIN msg=audit(1291776434.595:31982): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=success'
Now you should remove the ~/.xsession-errors file again and reproduce the creation of it. Once it is recreated, search /var/log/audit/audit.log for avcgrants regarding xsession-errors:
cat /var/log/audit/audit.log | grep -i grant | grep xsession
Found none. But oddly this time I see: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:user_home_t:s0 .xsession-errors
i guess the rule in mytest.te is not broad enough; We can make it a bit broader by adding:
gen_require(` attribute userdomain; type user_home_dir_t; ')
allow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
and then rebuild the mytest module and reinstall it.
That avc denial may expose some information as to which program creates it, Then a solution can be considered.
Basically a few options:
- file was somehow just mislabled (cannot reproduce)
- file gets created by some application running in the user domain:
- a. can we confine this application and make it create the file with
type xdm_home_t instead so that xdm_t can interact with it? 2. b. if all else fails, we can consider allowing xdm access to user_home_t typed files. 3. are we missing a boolean that can be toggled to allow this access (pipe avc denial into audit2why/ use sesearch to see if there are rules in the policy database that permit this access.
We do have use_nfs_home_dirs --> on
- is something misconfigured?
- is something buggy?
- is this some kind of intrusion attempt?
- -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/08/2010 09:57 AM, Dominick Grift wrote:
On 12/08/2010 04:06 AM, David Highley wrote:
"Dominick Grift wrote:"
On 12/05/2010 09:09 PM, David Highley wrote:
Keep getting AVC's when I log into multiple Fedora 14 systems with automounted home directories. Labels keep getting mucked up after logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done semanage fcontext -a -e /home /export/home. They automount to /home/<user>.
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like for some reason the ~/.xsession-errors file is mislabeled. it should have been type xdm_home_t instead of user_home_t.
Agree it should be labeled as xdm_home_t.
I guess in this case it should be labeled nfs_t.
It seems that gdm itself did not create it but that instead some program that runs in the user domain created it.
You should first try to reproduce this issue by removing the file and see if this file gets created again with type user_home_t in enforcing mode.
Remove the file and then logged back into the NFS server and the file is recreated with the proper label.
When this is verified, you should see if you have a file context specification for ~/.xsession-errors:
$ matchpathcon ~/.xsession-errors /root/.xsession-errors staff_u:object_r:xdm_home_t:s0
Verified using matchpatchcon as above.
Now log into an NFS client host and get the following: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:nfs_t:s0 .xsession-errors
ls -Zd /home/dhighley drwxr-x---. dhighley staff system_u:object_r:nfs_t:s0 /home/dhighley
ls -Zd /home drwxr-xr-x. root root system_u:object_r:autofs_t:s0 /home
Note: from above that the label for .xsession-errors is now incorrect. I would submitt that the Gnome/X11 session start is mucking the file label.
It could be restorecond -u messing with it, try disabling restorecond -u in your gnome-session(s) and try reproduce it again (system > preferences > startup applications > File context maintainer (off)
use the path to your unprivileged user home directory instead of /root in my example.
If it is verified that something running in the user domain is creating the .xsession-errors file, then we must figure out what and why.
We can do that by loading a "auditallow" rule. for example:
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0) gen_require(` attribute domain; type user_home_t; ') allow domain user_home_t:file create;" > mytest.te;
Created and installed the policy on the NFS client system.
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
(after reproducing testing remove the installed module: sudo semodule -r mytest)
(not this may cause many avc granted messages in audit.log)
Reviewing audit log on client system I only see the following logged: type=USER_AUTH msg=audit(1291776422.987:31974): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:auth entication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr =? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1291776422.990:31975): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=failed' type=USER_AUTH msg=audit(1291776434.310:31976): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1291776434.323:31977): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=CRED_ACQ msg=audit(1291776434.350:31978): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=LOGIN msg=audit(1291776434.358:31979): login pid=16804 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=72 type=USER_ROLE_CHANGE msg=audit(1291776434.501:31980): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1291776434.593:31981): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_LOGIN msg=audit(1291776434.595:31982): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=success'
Now you should remove the ~/.xsession-errors file again and reproduce the creation of it. Once it is recreated, search /var/log/audit/audit.log for avcgrants regarding xsession-errors:
cat /var/log/audit/audit.log | grep -i grant | grep xsession
Found none. But oddly this time I see: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:user_home_t:s0 .xsession-errors
i guess the rule in mytest.te is not broad enough; We can make it a bit broader by adding:
gen_require(` attribute userdomain; type user_home_dir_t; ')
allow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
Whoops! abviously make that auditallow instead of allow:
auditallow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
(but chances are that restorecond -u just reset the context of ~/.xsession-errors, so try disabling restorecond -u first)
and then rebuild the mytest module and reinstall it.
That avc denial may expose some information as to which program creates it, Then a solution can be considered.
Basically a few options:
- file was somehow just mislabled (cannot reproduce)
- file gets created by some application running in the user domain:
- a. can we confine this application and make it create the file with
type xdm_home_t instead so that xdm_t can interact with it? 2. b. if all else fails, we can consider allowing xdm access to user_home_t typed files. 3. are we missing a boolean that can be toggled to allow this access (pipe avc denial into audit2why/ use sesearch to see if there are rules in the policy database that permit this access.
We do have use_nfs_home_dirs --> on
- is something misconfigured?
- is something buggy?
- is this some kind of intrusion attempt?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/08/2010 10:53 AM, Dominick Grift wrote:
On 12/08/2010 09:57 AM, Dominick Grift wrote:
On 12/08/2010 04:06 AM, David Highley wrote:
"Dominick Grift wrote:"
On 12/05/2010 09:09 PM, David Highley wrote:
Keep getting AVC's when I log into multiple Fedora 14 systems with automounted home directories. Labels keep getting mucked up after logging into a client NFS host.
NFS directory server has files located in /export/home/<user>. Have done semanage fcontext -a -e /home /export/home. They automount to /home/<user>.
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file
time->Sat Dec 4 15:36:14 2010 type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:user_home_t:s0 tclass=file -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like for some reason the ~/.xsession-errors file is mislabeled. it should have been type xdm_home_t instead of user_home_t.
Agree it should be labeled as xdm_home_t.
I guess in this case it should be labeled nfs_t.
It seems that gdm itself did not create it but that instead some program that runs in the user domain created it.
You should first try to reproduce this issue by removing the file and see if this file gets created again with type user_home_t in enforcing mode.
Remove the file and then logged back into the NFS server and the file is recreated with the proper label.
When this is verified, you should see if you have a file context specification for ~/.xsession-errors:
$ matchpathcon ~/.xsession-errors /root/.xsession-errors staff_u:object_r:xdm_home_t:s0
Verified using matchpatchcon as above.
Now log into an NFS client host and get the following: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:nfs_t:s0 .xsession-errors
ls -Zd /home/dhighley drwxr-x---. dhighley staff system_u:object_r:nfs_t:s0 /home/dhighley
ls -Zd /home drwxr-xr-x. root root system_u:object_r:autofs_t:s0 /home
Note: from above that the label for .xsession-errors is now incorrect. I would submitt that the Gnome/X11 session start is mucking the file label.
It could be restorecond -u messing with it, try disabling restorecond -u in your gnome-session(s) and try reproduce it again (system > preferences > startup applications > File context maintainer (off)
use the path to your unprivileged user home directory instead of /root in my example.
If it is verified that something running in the user domain is creating the .xsession-errors file, then we must figure out what and why.
We can do that by loading a "auditallow" rule. for example:
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0) gen_require(` attribute domain; type user_home_t; ') allow domain user_home_t:file create;" > mytest.te;
Created and installed the policy on the NFS client system.
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
(after reproducing testing remove the installed module: sudo semodule -r mytest)
(not this may cause many avc granted messages in audit.log)
Reviewing audit log on client system I only see the following logged: type=USER_AUTH msg=audit(1291776422.987:31974): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:auth entication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr =? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1291776422.990:31975): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=failed' type=USER_AUTH msg=audit(1291776434.310:31976): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1291776434.323:31977): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=CRED_ACQ msg=audit(1291776434.350:31978): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=LOGIN msg=audit(1291776434.358:31979): login pid=16804 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=72 type=USER_ROLE_CHANGE msg=audit(1291776434.501:31980): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1291776434.593:31981): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_LOGIN msg=audit(1291776434.595:31982): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=success'
Now you should remove the ~/.xsession-errors file again and reproduce the creation of it. Once it is recreated, search /var/log/audit/audit.log for avcgrants regarding xsession-errors:
cat /var/log/audit/audit.log | grep -i grant | grep xsession
Found none. But oddly this time I see: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:user_home_t:s0 .xsession-errors
There is some strange stuff going on, and its hard to tell what it is since i am missing some information.
When this happened; how was /home/dhighley labelled? If it was labelled nfs_t, then .xsession-errors could never have get labelled user_home_t.
Also the above suggest that some system process running as dhighley:staff created this file. That is conflicting as well.
system_u is a selinux identity for system services, it is not the selinux identity for dhighley:staff
we just really need to audit what creates the file and then figure out how to fix it.
i guess the rule in mytest.te is not broad enough; We can make it a bit broader by adding:
gen_require(` attribute userdomain; type user_home_dir_t; ')
allow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
Whoops! abviously make that auditallow instead of allow:
auditallow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
(but chances are that restorecond -u just reset the context of ~/.xsession-errors, so try disabling restorecond -u first)
Actually no, i do not think restorecond -u is involved here on second thought.
You may also want to add:
auditallow domain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
just in case it is not an user domain creating the file.
and then rebuild the mytest module and reinstall it.
That avc denial may expose some information as to which program creates it, Then a solution can be considered.
Basically a few options:
- file was somehow just mislabled (cannot reproduce)
- file gets created by some application running in the user domain:
- a. can we confine this application and make it create the file with
type xdm_home_t instead so that xdm_t can interact with it? 2. b. if all else fails, we can consider allowing xdm access to user_home_t typed files. 3. are we missing a boolean that can be toggled to allow this access (pipe avc denial into audit2why/ use sesearch to see if there are rules in the policy database that permit this access.
We do have use_nfs_home_dirs --> on
- is something misconfigured?
- is something buggy?
- is this some kind of intrusion attempt?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/08/2010 07:23 AM, Dominick Grift wrote:
On 12/08/2010 10:53 AM, Dominick Grift wrote:
On 12/08/2010 09:57 AM, Dominick Grift wrote:
On 12/08/2010 04:06 AM, David Highley wrote:
"Dominick Grift wrote:"
On 12/05/2010 09:09 PM, David Highley wrote:
> Keep getting AVC's when I log into multiple Fedora 14 systems with > automounted home directories. Labels keep getting mucked up after > logging into a client NFS host. > > NFS directory server has files located in /export/home/<user>. Have done > semanage fcontext -a -e /home /export/home. They automount to > /home/<user>. > > time->Sat Dec 4 15:36:14 2010 > type=SYSCALL msg=audit(1291505774.397:17149): arch=c000003e syscall=21 > success=no exit=-13 a0=2320f80 a1=6 a2=20 a3=0 items=0 ppid=23814 > pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 > egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 > comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1291505774.397:17149): avc: denied { write } for > pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 > ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:user_home_t:s0 tclass=file > ---- > time->Sat Dec 4 15:36:14 2010 > type=SYSCALL msg=audit(1291505774.397:17150): arch=c000003e syscall=77 > success=no exit=-13 a0=c a1=0 a2=7fff53028020 a3=0 items=0 ppid=23814 > pid=23980 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 > egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2462 > comm="gdm-session-wor" exe="/usr/libexec/gdm-session-worker" > subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) > type=AVC msg=audit(1291505774.397:17150): avc: denied { write } for > pid=23980 comm="gdm-session-wor" name=".xsession-errors" dev=dm-2 > ino=392531 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 > tcontext=system_u:object_r:user_home_t:s0 tclass=file > -- > selinux mailing list > selinux@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux
Looks like for some reason the ~/.xsession-errors file is mislabeled. it should have been type xdm_home_t instead of user_home_t.
Agree it should be labeled as xdm_home_t.
I guess in this case it should be labeled nfs_t.
It seems that gdm itself did not create it but that instead some program that runs in the user domain created it.
You should first try to reproduce this issue by removing the file and see if this file gets created again with type user_home_t in enforcing mode.
Remove the file and then logged back into the NFS server and the file is recreated with the proper label.
When this is verified, you should see if you have a file context specification for ~/.xsession-errors:
> $ matchpathcon ~/.xsession-errors > /root/.xsession-errors staff_u:object_r:xdm_home_t:s0
Verified using matchpatchcon as above.
Now log into an NFS client host and get the following: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:nfs_t:s0 .xsession-errors
ls -Zd /home/dhighley drwxr-x---. dhighley staff system_u:object_r:nfs_t:s0 /home/dhighley
ls -Zd /home drwxr-xr-x. root root system_u:object_r:autofs_t:s0 /home
Note: from above that the label for .xsession-errors is now incorrect. I would submitt that the Gnome/X11 session start is mucking the file label.
It could be restorecond -u messing with it, try disabling restorecond -u in your gnome-session(s) and try reproduce it again (system > preferences > startup applications > File context maintainer (off)
use the path to your unprivileged user home directory instead of /root in my example.
If it is verified that something running in the user domain is creating the .xsession-errors file, then we must figure out what and why.
We can do that by loading a "auditallow" rule. for example:
mkdir ~/mytest; cd ~/mytest; echo "policy_module(mytest,1.0.0) gen_require(` attribute domain; type user_home_t; ') allow domain user_home_t:file create;" > mytest.te;
Created and installed the policy on the NFS client system.
make -f /usr/share/selinux/devel/Makefile mytest.pp sudo semodule -i mytest.pp
(after reproducing testing remove the installed module: sudo semodule -r mytest)
(not this may cause many avc granted messages in audit.log)
Reviewing audit log on client system I only see the following logged: type=USER_AUTH msg=audit(1291776422.987:31974): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:auth entication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr =? terminal=:0 res=failed' type=USER_LOGIN msg=audit(1291776422.990:31975): user pid=16805 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=failed' type=USER_AUTH msg=audit(1291776434.310:31976): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_ACCT msg=audit(1291776434.323:31977): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=CRED_ACQ msg=audit(1291776434.350:31978): user pid=16804 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=LOGIN msg=audit(1291776434.358:31979): login pid=16804 uid=0 old auid=4294967295 new auid=1000 old ses=4294967295 new ses=72 type=USER_ROLE_CHANGE msg=audit(1291776434.501:31980): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected-context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=? res=success' type=USER_START msg=audit(1291776434.593:31981): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open acct="dhighley" exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=:0 res=success' type=USER_LOGIN msg=audit(1291776434.595:31982): user pid=16804 uid=0 auid=1000 ses=72 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='uid=1000: exe="/usr/libexec/gdm-session-worker" hostname=? addr=? terminal=/dev/tty7 res=success'
Now you should remove the ~/.xsession-errors file again and reproduce the creation of it. Once it is recreated, search /var/log/audit/audit.log for avcgrants regarding xsession-errors:
cat /var/log/audit/audit.log | grep -i grant | grep xsession
Found none. But oddly this time I see: ls -Z .xsession-errors -rw-------. dhighley staff system_u:object_r:user_home_t:s0 .xsession-errors
There is some strange stuff going on, and its hard to tell what it is since i am missing some information.
When this happened; how was /home/dhighley labelled? If it was labelled nfs_t, then .xsession-errors could never have get labelled user_home_t.
Also the above suggest that some system process running as dhighley:staff created this file. That is conflicting as well.
system_u is a selinux identity for system services, it is not the selinux identity for dhighley:staff
we just really need to audit what creates the file and then figure out how to fix it.
i guess the rule in mytest.te is not broad enough; We can make it a bit broader by adding:
gen_require(` attribute userdomain; type user_home_dir_t; ')
allow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
Whoops! abviously make that auditallow instead of allow:
auditallow userdomain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
(but chances are that restorecond -u just reset the context of ~/.xsession-errors, so try disabling restorecond -u first)
Actually no, i do not think restorecond -u is involved here on second thought.
You may also want to add:
auditallow domain { user_home_t user_home_dir_t }:{ dir file } { relabelto relabelfrom create read write };
just in case it is not an user domain creating the file.
and then rebuild the mytest module and reinstall it.
That avc denial may expose some information as to which program creates it, Then a solution can be considered.
Basically a few options:
- file was somehow just mislabled (cannot reproduce)
- file gets created by some application running in the user domain:
- a. can we confine this application and make it create the file with
type xdm_home_t instead so that xdm_t can interact with it? 2. b. if all else fails, we can consider allowing xdm access to user_home_t typed files. 3. are we missing a boolean that can be toggled to allow this access (pipe avc denial into audit2why/ use sesearch to see if there are rules in the policy database that permit this access.
We do have use_nfs_home_dirs --> on
- is something misconfigured?
- is something buggy?
- is this some kind of intrusion attempt?
- -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
My guess is that you are logging into the client and the server using NFS client Homedir.
If you login to the client, the .xsession-errors will show up as nfs_t on the client, but on the server, the file will get created as user_home_t, I believe. Since there is a rule that says files created by kernel_t in user_home_dir_t get created as user_home_t. When you login to the nfs server directly you get an error saying xdm is not allowed to write user_home_t. I really do not have a solution other then running restorecond on the server to watch this file.
Daniel J Walsh:
If you login to the client, the .xsession-errors will show up as nfs_t on the client, but on the server, the file will get created as user_home_t, I believe. Since there is a rule that says files created by kernel_t in user_home_dir_t get created as user_home_t. When you login to the nfs server directly you get an error saying xdm is not allowed to write user_home_t.
That is probably what happens. At least for us. We are also seeing this problem, and what you describe above matches very well what we see.
I really do not have a solution other then running restorecond on the server to watch this file.
That would mean adding "/home/*/.xsession-errors" to /etc/selinux/restorecond.conf, right? Is there some comment syntax for this file? (So I can add a note why I did this?)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/09/2010 04:52 AM, Göran Uddeborg wrote:
Daniel J Walsh:
If you login to the client, the .xsession-errors will show up as nfs_t on the client, but on the server, the file will get created as user_home_t, I believe. Since there is a rule that says files created by kernel_t in user_home_dir_t get created as user_home_t. When you login to the nfs server directly you get an error saying xdm is not allowed to write user_home_t.
That is probably what happens. At least for us. We are also seeing this problem, and what you describe above matches very well what we see.
I really do not have a solution other then running restorecond on the server to watch this file.
That would mean adding "/home/*/.xsession-errors" to /etc/selinux/restorecond.conf, right? Is there some comment syntax for this file? (So I can add a note why I did this?) -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
~/.xsessions-errors Should work, although I have a bug report on this not working. Could you see if it works for you.
Göran Uddeborg:
Daniel J Walsh:
~/.xsessions-errors Should work, although I have a bug report on this not working. Could you see if it works for you.
I'm testing now. I saw your other mail warning that it might not work. But I'll let you know what actually happens.
Following up on my promise:
As you suspected in another mail, ~/.xsession-errors didn't work. I also tried /home/*/.xsession-errors, but that didn't work either. Apparently asterisks in restorecond.conf are expanded only if they are the last component in the path, not in the middle as above.
What I had to do was to list /home/.../.xsession-errors for all users active on the machines. It obviously doesn't scale very nicely. But this is a home environment, and there are only a handful of users.
So it works for me! :-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/09/2010 04:52 AM, Göran Uddeborg wrote:
Daniel J Walsh:
If you login to the client, the .xsession-errors will show up as nfs_t on the client, but on the server, the file will get created as user_home_t, I believe. Since there is a rule that says files created by kernel_t in user_home_dir_t get created as user_home_t. When you login to the nfs server directly you get an error saying xdm is not allowed to write user_home_t.
That is probably what happens. At least for us. We are also seeing this problem, and what you describe above matches very well what we see.
I really do not have a solution other then running restorecond on the server to watch this file.
That would mean adding "/home/*/.xsession-errors" to /etc/selinux/restorecond.conf, right? Is there some comment syntax for this file? (So I can add a note why I did this?) -- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
Then again it might not because restorecond watches for users logging in to figure out which files to watch.
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
David Highley -
Dominick Grift -
Göran Uddeborg