Got the following output from using the newrole command on Fedora 12. Not sure where to properly report such bugs.
If it helps, the rubix_remote_client_r role transition should fail (as it does) as there are no role transition rules for it. The role is associated with the current SELinux user.
I believe my system just updated to the newest newrole package. [warner@Fedora12-Dev ~]$ yum info policycoreutils Loaded plugins: presto, refresh-packagekit Installed Packages Name : policycoreutils Arch : i686 Version : 2.0.78 Release : 3.fc12 Size : 3.3 M Repo : installed
From repo : updates
Error output from newrole follows:
[warner@Fedora12-Dev ~]$ newrole -r rubix_remote_client_r Password: failed to exec shell : Permission denied *** glibc detected *** newrole: double free or corruption (out): 0x01726138 *** ======= Backtrace: ========= /lib/libc.so.6(-0xff836d9f)[0x233261] /lib/libselinux.so.1(freecon+0x1e)[0x9fd42e] newrole(main+0x6eb)[0x119d6b] /lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6] newrole(+0x16f1)[0x1186f1] ======= Memory map: ======== 00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole 0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole 0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole 0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so 00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so 00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so 00137000-00139000 rw-p 00000000 00:00 0 001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so 001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so 001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so 001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so 00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so 00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so 00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so 00337000-0033a000 rw-p 00000000 00:00 0 0055f000-00560000 r-xp 00000000 00:00 0 [vdso] 005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0 005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0 0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so 00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so 00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so 008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0 008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0 00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16 0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16 00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so 00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so 00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so 009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1 00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1 00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1 00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1 00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1 00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0 00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0 00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0 00ea9000-00ec6000 r-xp 00000000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00ec6000-00ec7000 rw-p 0001c000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so 00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so 00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so 01724000-017a9000 rw-p 00000000 00:00 0 [heap] b7627000-b7827000 r--p 00000000 fd:00 12545 /usr/lib/locale/locale-archive b7827000-b782a000 rw-p 00000000 00:00 0 b783b000-b7842000 r--s 00000000 fd:00 10739 /usr/lib/gconv/gconv-modules.cache b7842000-b7843000 rw-p 00000000 00:00 0 bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack] [warner@Fedora12-Dev ~]$
On Mon, Dec 28, 2009 at 06:29:02PM -0500, Andy Warner wrote:
Got the following output from using the newrole command on Fedora 12. Not sure where to properly report such bugs.
If it helps, the rubix_remote_client_r role transition should fail (as it does) as there are no role transition rules for it. The role is associated with the current SELinux user.
I believe my system just updated to the newest newrole package. [warner@Fedora12-Dev ~]$ yum info policycoreutils Loaded plugins: presto, refresh-packagekit Installed Packages Name : policycoreutils Arch : i686 Version : 2.0.78 Release : 3.fc12 Size : 3.3 M Repo : installed
From repo : updates
Error output from newrole follows:
[warner@Fedora12-Dev ~]$ newrole -r rubix_remote_client_r
Does it behave as expected if you use sudo instead?
sudo -r rubix_remote_client_r -t rubix_remote_client_t -s
Eitherway looks like a bug in newrole
Password: failed to exec shell : Permission denied *** glibc detected *** newrole: double free or corruption (out): 0x01726138 *** ======= Backtrace: ========= /lib/libc.so.6(-0xff836d9f)[0x233261] /lib/libselinux.so.1(freecon+0x1e)[0x9fd42e] newrole(main+0x6eb)[0x119d6b] /lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6] newrole(+0x16f1)[0x1186f1] ======= Memory map: ======== 00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole 0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole 0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole 0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so 00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so 00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so 00137000-00139000 rw-p 00000000 00:00 0 001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so 001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so 001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so 001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so 00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so 00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so 00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so 00337000-0033a000 rw-p 00000000 00:00 0 0055f000-00560000 r-xp 00000000 00:00 0 [vdso] 005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0 005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0 0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so 00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so 00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so 008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0 008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0 00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16 0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16 00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so 00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so 00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so 009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1 00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1 00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1 00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1 00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1 00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0 00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0 00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0 00ea9000-00ec6000 r-xp 00000000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00ec6000-00ec7000 rw-p 0001c000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so 00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so 00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so 01724000-017a9000 rw-p 00000000 00:00 0 [heap] b7627000-b7827000 r--p 00000000 fd:00 12545 /usr/lib/locale/locale-archive b7827000-b782a000 rw-p 00000000 00:00 0 b783b000-b7842000 r--s 00000000 fd:00 10739 /usr/lib/gconv/gconv-modules.cache b7842000-b7843000 rw-p 00000000 00:00 0 bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack] [warner@Fedora12-Dev ~]$
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Dominick Grift wrote:
On Mon, Dec 28, 2009 at 06:29:02PM -0500, Andy Warner wrote:
Got the following output from using the newrole command on Fedora 12. Not sure where to properly report such bugs.
If it helps, the rubix_remote_client_r role transition should fail (as it does) as there are no role transition rules for it. The role is associated with the current SELinux user.
I believe my system just updated to the newest newrole package. [warner@Fedora12-Dev ~]$ yum info policycoreutils Loaded plugins: presto, refresh-packagekit Installed Packages Name : policycoreutils Arch : i686 Version : 2.0.78 Release : 3.fc12 Size : 3.3 M Repo : installed
From repo : updates
Error output from newrole follows:
[warner@Fedora12-Dev ~]$ newrole -r rubix_remote_client_r
Does it behave as expected if you use sudo instead?
sudo -r rubix_remote_client_r -t rubix_remote_client_t -s
Eitherway looks like a bug in newrole
Yes, sudo behaves as expected. The problem does not happen. The sudo command fails normally being unable to exec bash do to a lack of a transition rule.
Password: failed to exec shell : Permission denied *** glibc detected *** newrole: double free or corruption (out): 0x01726138 *** ======= Backtrace: ========= /lib/libc.so.6(-0xff836d9f)[0x233261] /lib/libselinux.so.1(freecon+0x1e)[0x9fd42e] newrole(main+0x6eb)[0x119d6b] /lib/libc.so.6(__libc_start_main+0xe6)[0x1dbbb6] newrole(+0x16f1)[0x1186f1] ======= Memory map: ======== 00117000-0011d000 r-xp 00000000 fd:00 126525 /usr/bin/newrole 0011d000-0011e000 r--p 00005000 fd:00 126525 /usr/bin/newrole 0011e000-0011f000 rw-p 00006000 fd:00 126525 /usr/bin/newrole 0011f000-00135000 r-xp 00000000 fd:00 56679 /lib/libpthread-2.11.so 00135000-00136000 r--p 00015000 fd:00 56679 /lib/libpthread-2.11.so 00136000-00137000 rw-p 00016000 fd:00 56679 /lib/libpthread-2.11.so 00137000-00139000 rw-p 00000000 00:00 0 001a5000-001c3000 r-xp 00000000 fd:00 56677 /lib/ld-2.11.so 001c3000-001c4000 r--p 0001d000 fd:00 56677 /lib/ld-2.11.so 001c4000-001c5000 rw-p 0001e000 fd:00 56677 /lib/ld-2.11.so 001c5000-00333000 r-xp 00000000 fd:00 56678 /lib/libc-2.11.so 00333000-00334000 ---p 0016e000 fd:00 56678 /lib/libc-2.11.so 00334000-00336000 r--p 0016e000 fd:00 56678 /lib/libc-2.11.so 00336000-00337000 rw-p 00170000 fd:00 56678 /lib/libc-2.11.so 00337000-0033a000 rw-p 00000000 00:00 0 0055f000-00560000 r-xp 00000000 00:00 0 [vdso] 005f6000-005fa000 r-xp 00000000 fd:00 1331 /lib/libattr.so.1.1.0 005fa000-005fb000 rw-p 00003000 fd:00 1331 /lib/libattr.so.1.1.0 0062d000-00638000 r-xp 00000000 fd:00 10441 /lib/libnss_files-2.11.so 00638000-00639000 r--p 0000a000 fd:00 10441 /lib/libnss_files-2.11.so 00639000-0063a000 rw-p 0000b000 fd:00 10441 /lib/libnss_files-2.11.so 008a3000-008a5000 r-xp 00000000 fd:00 15448 /lib/libpam_misc.so.0.82.0 008a5000-008a6000 rw-p 00001000 fd:00 15448 /lib/libpam_misc.so.0.82.0 00928000-0092c000 r-xp 00000000 fd:00 1332 /lib/libcap.so.2.16 0092c000-0092d000 rw-p 00003000 fd:00 1332 /lib/libcap.so.2.16 00992000-00995000 r-xp 00000000 fd:00 56684 /lib/libdl-2.11.so 00995000-00996000 r--p 00002000 fd:00 56684 /lib/libdl-2.11.so 00996000-00997000 rw-p 00003000 fd:00 56684 /lib/libdl-2.11.so 009f3000-00a0f000 r-xp 00000000 fd:00 56687 /lib/libselinux.so.1 00a0f000-00a10000 r--p 0001b000 fd:00 56687 /lib/libselinux.so.1 00a10000-00a11000 rw-p 0001c000 fd:00 56687 /lib/libselinux.so.1 00c8b000-00c97000 r-xp 00000000 fd:00 15447 /lib/libpam.so.0.82.1 00c97000-00c98000 rw-p 0000b000 fd:00 15447 /lib/libpam.so.0.82.1 00e6f000-00e85000 r-xp 00000000 fd:00 15446 /lib/libaudit.so.1.0.0 00e85000-00e86000 r--p 00015000 fd:00 15446 /lib/libaudit.so.1.0.0 00e86000-00e87000 rw-p 00016000 fd:00 15446 /lib/libaudit.so.1.0.0 00ea9000-00ec6000 r-xp 00000000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00ec6000-00ec7000 rw-p 0001c000 fd:00 51325 /lib/libgcc_s-4.4.2-20091027.so.1 00f05000-00f0c000 r-xp 00000000 fd:00 56680 /lib/librt-2.11.so 00f0c000-00f0d000 r--p 00006000 fd:00 56680 /lib/librt-2.11.so 00f0d000-00f0e000 rw-p 00007000 fd:00 56680 /lib/librt-2.11.so 01724000-017a9000 rw-p 00000000 00:00 0 [heap] b7627000-b7827000 r--p 00000000 fd:00 12545 /usr/lib/locale/locale-archive b7827000-b782a000 rw-p 00000000 00:00 0 b783b000-b7842000 r--s 00000000 fd:00 10739 /usr/lib/gconv/gconv-modules.cache b7842000-b7843000 rw-p 00000000 00:00 0 bfcce000-bfce3000 rw-p 00000000 00:00 0 [stack] [warner@Fedora12-Dev ~]$
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Whenever I do "su" in an xterm window, I get two AVC denials. The command xauth is denied to read and write a file .xauthXXXXX where XXXXX is some random string different each time. (I encose an example below.)
I would bugzilla this, but I'm (as often) not quite sure if it's the policy or if it's me. That is, if maybe this is not intended to be allowed? Or if there there something else I might be missing? I can't see any boolean I would connect to this.
So, is this a bug I should report, or is it intentional?
---- time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file ---- time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
On Tue, Dec 29, 2009 at 10:32:19PM +0100, Göran Uddeborg wrote:
Whenever I do "su" in an xterm window, I get two AVC denials. The command xauth is denied to read and write a file .xauthXXXXX where XXXXX is some random string different each time. (I encose an example below.)
I would bugzilla this, but I'm (as often) not quite sure if it's the policy or if it's me. That is, if maybe this is not intended to be allowed? Or if there there something else I might be missing? I can't see any boolean I would connect to this.
So, is this a bug I should report, or is it intentional?
Well for starters the file is mislabeled:
[root@localhost Desktop]# matchpathcon /root/.xauthbDy84s /root/.xauthbDy84s system_u:object_r:xauth_home_t:s0
If the file was properly labeled the access would be allowed:
[root@localhost Desktop]# sesearch --allow -s xauth_t -t xauth_home_t Found 2 semantic av rules: allow xauth_t xauth_home_t : file { ioctl read write create getattr setattr lock append unlink link rename open } ; allow xauth_t file_type : filesystem getattr ;
The following policy would make source process type xauth_t create .xauth* files in /root with type xauth_home_t:
allow xauth_t xauth_home_t:file manage_file_perms; userdom_admin_home_dir_filetrans(xauth_t, xauth_home_t, file) /root/.xauth.* -- gen_context(system_u:object_r:xauth_home_t,s0)
The Question is: why did this not happen?
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Dominick Grift:
Well for starters the file is mislabeled:
The Question is: why did this not happen?
Thanks for your analysis.
I'll try to investigate exactly when this happens. And if it turns out to be something policy-related (rather than something that has gone wrong locally) I'll file a bugzilla.
Remove the file and see if xauth creates a new one and what the type of the newly created file is: ls -alZ /root | grep .xauth
Now it gets a context of xauth_home_t. (As usual, bugs hide when you start looking for them!)
What distro are you using?
Fedora 12. I recently upgraded the policy to selinux-policy-3.6.32-63.fc12.
BTW: It is not encouraged to login as root via ssh (-X)
:-) Between two trusted hosts on a trusted local, wired, network, I'm not too worried. (I don't actually log in as root. I log in as myself and do su or sudo. But I guess that part doesn't really make much difference.)
On 12/30/2009 11:14 AM, Göran Uddeborg wrote:
Dominick Grift:
Well for starters the file is mislabeled:
The Question is: why did this not happen?
Thanks for your analysis.
I'll try to investigate exactly when this happens. And if it turns out to be something policy-related (rather than something that has gone wrong locally) I'll file a bugzilla.
Remove the file and see if xauth creates a new one and what the type of the newly created file is: ls -alZ /root | grep .xauth
Now it gets a context of xauth_home_t. (As usual, bugs hide when you start looking for them!)
What distro are you using?
Fedora 12. I recently upgraded the policy to selinux-policy-3.6.32-63.fc12.
BTW: It is not encouraged to login as root via ssh (-X)
:-) Between two trusted hosts on a trusted local, wired, network, I'm not too worried. (I don't actually log in as root. I log in as myself and do su or sudo. But I guess that part doesn't really make much difference.)
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
There have been some fixes around the handling of xauth in the latest policies, so this might have fixed your problems.
Daniel J Walsh:
There have been some fixes around the handling of xauth in the latest policies, so this might have fixed your problems.
It seems to be so. I can't trigger it any more. The latest policy updates appears to have fixed this too.
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 -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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
Dominick Grift:
-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
That didn't find anything at all. (And consequently, adding a grep for sudo at the end didn't show anything either.)
Do you have stuff running initrc_t? (ps auxZ | grep initrc_t)
There are (now) four such processes:
system_u:system_r:initrc_t:SystemLow nobody 1899 0.0 0.0 105448 876 ? Ss 2009 4:04 /bin/bash /usr/local/sbin/adslmon system_u:system_r:initrc_t:SystemLow-SystemHigh root 2552 0.0 0.0 52088 1640 ? S 2009 0:05 /usr/libexec/polkit-1/polkitd unconfined_u:system_r:initrc_t:SystemLow root 25981 0.0 0.0 39280 536 ? Ss 2009 0:14 hostapd -B -ddK /etc/hostapd/hostapd.conf system_u:system_r:initrc_t:SystemLow nobody 29310 0.0 0.0 104648 656 ? S 18:12 0:00 sleep 10
adslmon is a script I use to monitor when my ADSL connection goes down and when it comes up again. The sleep is called from that script. I can't imagine it would be involved, but just in case you want to see it I put a copy at ftp://ftp.uddeborg.se/pub/adslmon
On Sun, Jan 03, 2010 at 06:19:05PM +0100, Göran Uddeborg wrote:
Dominick Grift:
-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
That didn't find anything at all. (And consequently, adding a grep for sudo at the end didn't show anything either.)
That is odd, these commands do return stuff on my f12 system(s)
Do you have stuff running initrc_t? (ps auxZ | grep initrc_t)
There are (now) four such processes:
system_u:system_r:initrc_t:SystemLow nobody 1899 0.0 0.0 105448 876 ? Ss 2009 4:04 /bin/bash /usr/local/sbin/adslmon system_u:system_r:initrc_t:SystemLow-SystemHigh root 2552 0.0 0.0 52088 1640 ? S 2009 0:05 /usr/libexec/polkit-1/polkitd
Looks like polkit runs in the wrong SELinux environment (do not know if this at all related though): That might signal that some files on your system may be mislabeled (i would suggest a file system relabel just for peace of mind)
[dgrift@localhost selinux-modules]$ ps auxZ | grep polkit-1 system_u:system_r:policykit_t:s0-s0:c0.c1023 root 1712 0.0 0.0 51524 3636 ? S 12:58 0:00 /usr/libexec/polkit-1/polkitd
unconfined_u:system_r:initrc_t:SystemLow root 25981 0.0 0.0 39280 536 ? Ss 2009 0:14 hostapd -B -ddK /etc/hostapd/hostapd.conf system_u:system_r:initrc_t:SystemLow nobody 29310 0.0 0.0 104648 656 ? S 18:12 0:00 sleep 10
adslmon is a script I use to monitor when my ADSL connection goes down and when it comes up again. The sleep is called from that script. I can't imagine it would be involved, but just in case you want to see it I put a copy at ftp://ftp.uddeborg.se/pub/adslmon
Dominick Grift:
That is odd, these commands do return stuff on my f12 system(s)
Odd indeed. Are we on the same policy? I have 3.6.32-63.fc12.
If you wish to compare, I've placed the output of "sesearch --allow -t xauth_exec_t" in ftp://ftp.uddeborg.se/pub/sesearch
Looks like polkit runs in the wrong SELinux environment
I ran restorecon on polkitd, and its type was indeed changed. I restarted it, and it looks better now.
mimmi$ ps -ZC polkitd LABEL PID TTY TIME CMD system_u:system_r:policykit_t:SystemLow-SystemHigh 723 ? 00:00:00 polkitd
(i would suggest a file system relabel just for peace of mind)
Probably a good idea. First, I'm running a "fixfiles check" on everything now, to see if I can find anything that would explain the behaviour. So far it has only found pretty unimportant things, like files under ~/.gconf that had user_home_t rather than gconf_home_t.
On Tue, Dec 29, 2009 at 10:32:19PM +0100, Göran Uddeborg wrote:
Whenever I do "su" in an xterm window, I get two AVC denials. The command xauth is denied to read and write a file .xauthXXXXX where XXXXX is some random string different each time. (I encose an example below.)
I would bugzilla this, but I'm (as often) not quite sure if it's the policy or if it's me. That is, if maybe this is not intended to be allowed? Or if there there something else I might be missing? I can't see any boolean I would connect to this.
So, is this a bug I should report, or is it intentional?
Remove the file and see if xauth creates a new one and what the type of the newly created file is: ls -alZ /root | grep .xauth
What distro are you using?
If xauth creates the file it should be type xauth_home_t, not admin_home_t. Maybe something else creates it?
The fact is that the file is mislabeled.
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, Dec 29, 2009 at 10:32:19PM +0100, Göran Uddeborg wrote:
Whenever I do "su" in an xterm window, I get two AVC denials. The command xauth is denied to read and write a file .xauthXXXXX where XXXXX is some random string different each time. (I encose an example below.)
I would bugzilla this, but I'm (as often) not quite sure if it's the policy or if it's me. That is, if maybe this is not intended to be allowed? Or if there there something else I might be missing? I can't see any boolean I would connect to this.
So, is this a bug I should report, or is it intentional?
I think this may be a bug here:
optional_policy(` domain_trans(sshd_t, xauth_exec_t, userdomain) ')
I do not think we want sshd_t to domain transition to a user domain upon executing files with type xauth_exec_t.
Instead i would argue for a xauth_domtrans(sshd_t)
I could be wrong and i do not know about any complications.
I think this is a valid bug. consider reporting it with the AVC denials and my analys to bugzilla/selinux-policy.
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
On Tue, Dec 29, 2009 at 10:32:19PM +0100, Göran Uddeborg wrote:
Whenever I do "su" in an xterm window, I get two AVC denials. The command xauth is denied to read and write a file .xauthXXXXX where XXXXX is some random string different each time. (I encose an example below.)
I would bugzilla this, but I'm (as often) not quite sure if it's the policy or if it's me. That is, if maybe this is not intended to be allowed? Or if there there something else I might be missing? I can't see any boolean I would connect to this.
So, is this a bug I should report, or is it intentional?
Hmm ignore my latest reply. Seems there is a rule that does the domain transition:
optional_policy(` xserver_domtrans_xauth(sshd_t) ')
So, i am running out of clues.
BTW: It is not encouraged to login as root via ssh (-X)
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.835:41732): arch=c000003e syscall=21 success=no exit=-13 a0=7fff99bd14d5 a1=2 a2=0 a3=7fff99bcfd10 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.835:41732): avc: denied { write } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 scontext=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
time->Tue Dec 29 21:32:48 2009 type=SYSCALL msg=audit(1262118768.836:41733): arch=c000003e syscall=2 success=no exit=-13 a0=7fff99bd14d5 a1=0 a2=1b6 a3=0 items=0 ppid=5506 pid=5511 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts6 ses=96 comm="xauth" exe="/usr/bin/xauth" subj=unconfined_u:unconfined_r:xauth_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1262118768.836:41733): avc: denied { read } for pid=5511 comm="xauth" name=".xauthbDy84s" dev=dm-0 ino=5341320 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org