On Sun, Jan 03, 2010 at 04:51:37PM +0100, Göran Uddeborg wrote:
> Göran Uddeborg:
> > It seems to be so. I can't trigger it any more.
>
> When I stopped trying, I could trigger it again. :-(
>
> I did "su" in an xterm (NOT from an ssh session) and got the avc:s
> below again. Looking at root's home directory after it happened, I
> see these files
>
> mimmi# ll .xauth*
> -rw------- 1 root root 51 3 jan 11.48 .xauth2nqqtg
> -rw------- 1 root root 0 3 jan 11.48 .xauthrZ8z8F
> -rw------- 2 root root 0 3 jan 11.48 .xauthrZ8z8F-c
> -rw------- 2 root root 0 3 jan 11.48 .xauthrZ8z8F-l
> mimmi# ll -Z .xauth*
> -rw------- root root unconfined_u:object_r:xauth_home_t:SystemLow .xauth2nqqtg
> -rw------- root root system_u:object_r:xauth_home_t:SystemLow .xauthrZ8z8F
This (above) is the entry i am most interested in. The file apears created by system_u (some system service). Could it be that we are missing an domain transition somewhere?
This command, i think, returns potential problems:
sesearch --allow -t xauth_exec_t | grep execute_no_trans
Do you have stuff running initrc_t? (ps auxZ | grep initrc_t)
This i dont think is related but may be something to keep in mind also as potential issues for xauth:
[root@localhost selinux-modules]# sesearch --allow -t xauth_exec_t | grep execute_no_trans | grep sudo
allow sysadm_sudo_t exec_type : file { ioctl read getattr lock execute execute_no_trans open } ;
allow staff_sudo_t exec_type : file { ioctl read getattr lock execute execute_no_trans open } ;
> -rw------- root root unconfined_u:object_r:xauth_home_t:SystemLow .xauthrZ8z8F-c
> -rw------- root root unconfined_u:object_r:xauth_home_t:SystemLow .xauthrZ8z8F-l
>
> TWO .xauth*-files were generated at the same time, the time when I did
> "su". But only one of them triggered these avc:s. The su session
> points its XAUTHORITY to .xauth2nqqtg, i.e. the one which didn't
> trigger any avc:s.
>
> Furthermore, now the file does have the correct context, xauth_home_t!
>
> Of course, simply trying another "su" in the same way doesn't trigger
> anything. The search goes on.
>
> time->Sun Jan 3 11:48:42 2010
> type=SYSCALL msg=audit(1262515722.636:63657): arch=c000003e syscall=21 success=no exit=-13 a0=7fff04ce14dc a1=2 a2=0 a3=7fff04cdf4c0 items=0 ppid=21356 pid=21406 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=137 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(1262515722.636:63657): avc: denied { write } for pid=21406 comm="xauth" name=".xauthrZ8z8F" dev=dm-0 ino=25002031 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
> ----
> time->Sun Jan 3 11:48:42 2010
> type=SYSCALL msg=audit(1262515722.637:63658): arch=c000003e syscall=2 success=no exit=-13 a0=7fff04ce14dc a1=0 a2=1b6 a3=0 items=0 ppid=21356 pid=21406 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=137 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null)
> type=AVC msg=audit(1262515722.637:63658): avc: denied { read } for pid=21406 comm="xauth" name=".xauthrZ8z8F" dev=dm-0 ino=25002031 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Attachment:
pgp4KkaW0cs7n.pgp
Description: PGP signature
-- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
