-----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@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
>
> 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:
>
>>>> 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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkz/1aYACgkQrlYvE4MpobNsRgCfSFIKLX3az4/AijFHRm9xX2/L
YTkAn1M2d0syJregvqikDx45i2ZeeUUw
=/H70
-----END PGP SIGNATURE-----
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
