-----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?