5:29 p.m.
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 ~]$
4:57 a.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
11:04 a.m.
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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
------------------------------------------------------------------------
--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
3:32 p.m.
New subject: AVC:s on xauth file when doing su
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
3:50 p.m.
New subject: AVC:s on xauth file when doing su
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
3:57 p.m.
New subject: AVC:s on xauth file when doing su
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
4:29 p.m.
New subject: AVC:s on xauth file when doing su
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
5:11 p.m.
New subject: AVC:s on xauth file when doing su
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
10:14 a.m.
New subject: AVC:s on xauth file when doing su
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.)
8:09 a.m.
New subject: AVC:s on xauth file when doing su
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(a)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.
6:51 a.m.
New subject: AVC:s on xauth file when doing su
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.
9:51 a.m.
New subject: AVC:s on xauth file when doing su
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
10:32 a.m.
New subject: AVC:s on xauth file when doing su
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
11:19 a.m.
New subject: AVC:s on xauth file when doing su
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
11:48 a.m.
New subject: AVC:s on xauth file when doing su
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
3 p.m.
New subject: AVC:s on xauth file when doing su
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.
5241
days inactive
5247
days old
selinux@lists.fedoraproject.org
15 comments
4 participants
participants (4)
-
Andy Warner -
Daniel J Walsh -
Dominick Grift -
Göran Uddeborg