-----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@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.
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?
-----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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
