-----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@xxxxxxxxxxxxxxxxxxxxxxx >>>> 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: > > 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. > >> We do have use_nfs_home_dirs --> on > > 4. is something misconfigured? > 5. is something buggy? > 6. is this some kind of intrusion attempt? - -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux >> > -- > selinux mailing list > selinux@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/selinux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkz/SIoACgkQMlxVo39jgT+xHgCgvpJH1rYnbKCgO73kH2qGssAU YKQAnjepHt5fw06kb7tn01gozCX5/rKG =4/bj -----END PGP SIGNATURE----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux