[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Václav Ovsík]

Hi,
I am running Debian unstable (Sid) with latest refpolicy packaged by
Russel Coker (2:0.0.20080702-6) with unconfined module (permissive
mode). I have caught problem with running update-initramfs under
unconfined user (system initrd image generation). The hook script udev
is trying to discover libraries used by udev running command "ldd
/sbin/udev", which emits:

[  180.506850] type=1400 audit(1219673765.136:5): avc:  denied  { use } for  pid=1944 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
[  180.534524] type=1300 audit(1219673765.136:5): arch=40000003 syscall=11 success=yes exit=0 a0=8f93ee8 a1=8f93e68 a2=8f7d008 a3=0 items=0 ppid=1936 pid=1944 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)

One wants to see output from udevd --help e.g. also...
So attached is a patch.
Thanks
-- 
Zito
-------------- next part --------------
Index: selinux-policy-src/policy/modules/system/udev.te
===================================================================
--- selinux-policy-src.orig/policy/modules/system/udev.te	2008-08-14 15:44:13.000000000 +0200
+++ selinux-policy-src/policy/modules/system/udev.te	2008-08-14 15:45:56.000000000 +0200
@@ -106,6 +106,7 @@
 
 domain_read_all_domains_state(udev_t)
 domain_dontaudit_ptrace_all_domains(udev_t) #pidof triggers these 
+domain_use_interactive_fds(udev_t)
 
 files_read_usr_files(udev_t)
 files_read_etc_runtime_files(udev_t)

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Christopher J. PeBenito]

On Mon, 2008-09-01 at 19:12 +0200, V?clav Ovs?k wrote:
> I am running Debian unstable (Sid) with latest refpolicy packaged by
> Russel Coker (2:0.0.20080702-6) with unconfined module (permissive
> mode). I have caught problem with running update-initramfs under
> unconfined user (system initrd image generation). The hook script udev
> is trying to discover libraries used by udev running command "ldd
> /sbin/udev", which emits:
> 
> [  180.506850] type=1400 audit(1219673765.136:5): avc:  denied  { use } for  pid=1944 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
> [  180.534524] type=1300 audit(1219673765.136:5): arch=40000003 syscall=11 success=yes exit=0 a0=8f93ee8 a1=8f93e68 a2=8f7d008 a3=0 items=0 ppid=1936 pid=1944 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
> 
> One wants to see output from udevd --help e.g. also...
> So attached is a patch.

The denials aren't consistent with 'ldd /sbin/udev', otherwise comm=
would be ldd.  I also can't reproduce this type of denial while using
ldd.  As for 'ldd --help', there shouldn't really be a transition.  In
fact I think Dan may have suggested removing the domain transition from
DIRECT_INITRC and just leave a role transition.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Václav Ovsík]

On Tue, Sep 02, 2008 at 09:19:53AM -0400, Christopher J. PeBenito wrote:
> On Mon, 2008-09-01 at 19:12 +0200, V?clav Ovs?k wrote:
> > I am running Debian unstable (Sid) with latest refpolicy packaged by
> > Russel Coker (2:0.0.20080702-6) with unconfined module (permissive
> > mode). I have caught problem with running update-initramfs under
> > unconfined user (system initrd image generation). The hook script udev
> > is trying to discover libraries used by udev running command "ldd
> > /sbin/udev", which emits:
> > 
> > [  180.506850] type=1400 audit(1219673765.136:5): avc:  denied  { use } for  pid=1944 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
> > [  180.534524] type=1300 audit(1219673765.136:5): arch=40000003 syscall=11 success=yes exit=0 a0=8f93ee8 a1=8f93e68 a2=8f7d008 a3=0 items=0 ppid=1936 pid=1944 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
> > 
> > One wants to see output from udevd --help e.g. also...
> > So attached is a patch.
> 
> The denials aren't consistent with 'ldd /sbin/udev', otherwise comm=
> would be ldd.  I also can't reproduce this type of denial while using
> ldd.  As for 'ldd --help', there shouldn't really be a transition.  In
> fact I think Dan may have suggested removing the domain transition from
> DIRECT_INITRC and just leave a role transition.
> 
> -- 
> Chris PeBenito
> Tresys Technology, LLC
> (410) 290-1411 x150

Sorry for a confusion and for my bad English.

Again:

sid:~# ldd /sbin/udevd
[   32.842803] type=1400 audit(1220364759.873:3): avc:  denied  { use } for  pid=1823 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
[   32.850142] type=1300 audit(1220364759.873:3): arch=40000003 syscall=11 success=yes exit=0 a0=a073a88 a1=a06b1e8 a2=a06a308 a3=0 items=0 ppid=1822 pid=1823 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1
ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
        linux-gate.so.1 =>  (0xb7f55000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7f34000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7dd9000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7dd4000)
        /lib/ld-linux.so.2 (0xb7f56000)
sid:~#

I think, that
ldd /sbin/udevd
is nothing more than
/lib/ld-linux.so.2 --list /sbin/udevd

That is - application is dynamically linked, SOs info is dumped and than
linker exits. So udevd command is emited in denial (it is really linked,
but not started).


sid:~# udevd --help
[  104.129673] type=1400 audit(1220364831.157:5): avc:  denied  { use } for  pid=1834 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
[  104.136232] type=1300 audit(1220364831.157:5): arch=40000003 syscall=11 success=yes exit=0 a0=8861aa8 a1=8861b48 a2=884b008 a3=0 items=0 ppid=1813 pid=1834 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1
ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
Usage: udevd [--help] [--daemon] [--debug-trace] [--debug] [--version]
sid:~#

There is run udevd directly and I think this should work too.


Yes, domain transition is sometimes unwanted.
Currently I have a similar problem with rsync. I'm using rsync over ssh,
so without policy module for rsync it is ok (rsync stays in callers
domain). What if rsync is run in daemon mode on server? Than rsync
policy module should be included, but rsync over ssh (e.g. to transfer
files from my home directory) is the problem - transition into rsync_t
occurs and denials are emitted.

Regards
-- 
Zito

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Martin Orr]

On 02/09/08 14:19, Christopher J. PeBenito wrote:
> On Mon, 2008-09-01 at 19:12 +0200, V?clav Ovs?k wrote:
>> I am running Debian unstable (Sid) with latest refpolicy packaged by
>> Russel Coker (2:0.0.20080702-6) with unconfined module (permissive
>> mode). I have caught problem with running update-initramfs under
>> unconfined user (system initrd image generation). The hook script udev
>> is trying to discover libraries used by udev running command "ldd
>> /sbin/udev", which emits:
>>
>> [  180.506850] type=1400 audit(1219673765.136:5): avc:  denied  { use } for  pid=1944 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
>> [  180.534524] type=1300 audit(1219673765.136:5): arch=40000003 syscall=11 success=yes exit=0 a0=8f93ee8 a1=8f93e68 a2=8f7d008 a3=0 items=0 ppid=1936 pid=1944 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
>>
>> One wants to see output from udevd --help e.g. also...
>> So attached is a patch.
> 
> The denials aren't consistent with 'ldd /sbin/udev', otherwise comm=
> would be ldd.  I also can't reproduce this type of denial while using
> ldd.  As for 'ldd --help', there shouldn't really be a transition.  In
> fact I think Dan may have suggested removing the domain transition from
> DIRECT_INITRC and just leave a role transition.

ldd is just a shell script, which does "LD_TRACE_LOADED_OBJECTS=1 $cmd" (you
can run that on the command line if you want).  Setting
LD_TRACE_LOADED_OBJECTS causes the dynamic linker to link the program and
output the objects it has linked but then exit without calling main().

Since $cmd is never properly executed, it doesn't make sense to be
transitioning to its domain.  So I think ldd should have a domain of its
own, which has no privileges except to write to the terminal and to
execute_no_trans everything.

-- 
Martin Orr

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Václav Ovsík]

On Wed, Sep 03, 2008 at 12:22:25PM +0100, Martin Orr wrote:
> On 02/09/08 14:19, Christopher J. PeBenito wrote:
> > On Mon, 2008-09-01 at 19:12 +0200, V?clav Ovs?k wrote:
> >> I am running Debian unstable (Sid) with latest refpolicy packaged by
> >> Russel Coker (2:0.0.20080702-6) with unconfined module (permissive
> >> mode). I have caught problem with running update-initramfs under
> >> unconfined user (system initrd image generation). The hook script udev
> >> is trying to discover libraries used by udev running command "ldd
> >> /sbin/udev", which emits:
> >>
> >> [  180.506850] type=1400 audit(1219673765.136:5): avc:  denied  { use } for  pid=1944 comm="udevd" path="/dev/tty1" dev=tmpfs ino=998 scontext=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 tcontext=system_u:system_r:getty_t:s0 tclass=fd
> >> [  180.534524] type=1300 audit(1219673765.136:5): arch=40000003 syscall=11 success=yes exit=0 a0=8f93ee8 a1=8f93e68 a2=8f7d008 a3=0 items=0 ppid=1936 pid=1944 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=unconfined_u:system_r:udev_t:s0-s0:c0.c1023 key=(null)
> >>
> >> One wants to see output from udevd --help e.g. also...
> >> So attached is a patch.
> > 
> > The denials aren't consistent with 'ldd /sbin/udev', otherwise comm=
> > would be ldd.  I also can't reproduce this type of denial while using
> > ldd.  As for 'ldd --help', there shouldn't really be a transition.  In
> > fact I think Dan may have suggested removing the domain transition from
> > DIRECT_INITRC and just leave a role transition.
> 
> ldd is just a shell script, which does "LD_TRACE_LOADED_OBJECTS=1 $cmd" (you
> can run that on the command line if you want).  Setting
> LD_TRACE_LOADED_OBJECTS causes the dynamic linker to link the program and
> output the objects it has linked but then exit without calling main().
> 
> Since $cmd is never properly executed, it doesn't make sense to be
> transitioning to its domain.  So I think ldd should have a domain of its
> own, which has no privileges except to write to the terminal and to
> execute_no_trans everything.
> -- 
> Martin Orr

Hmm, it sounds like the right way to solve this.
Maybe this could solve the problem with the transition to rsync_t from user
domains while rsync is running over ssh. Great.
Thanks for suggestion.
-- 
Zito

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[V�clav Ovs�k]

On Wed, Sep 03, 2008 at 03:52:37PM +0200, V?clav Ovs?k wrote:
> > ...
> > ldd is just a shell script, which does "LD_TRACE_LOADED_OBJECTS=1 $cmd" (you
> > can run that on the command line if you want).  Setting
> > LD_TRACE_LOADED_OBJECTS causes the dynamic linker to link the program and
> > output the objects it has linked but then exit without calling main().
> > 
> > Since $cmd is never properly executed, it doesn't make sense to be
> > transitioning to its domain.  So I think ldd should have a domain of its
> > own, which has no privileges except to write to the terminal and to
> > execute_no_trans everything.
> > -- 
> > Martin Orr
> 
> Hmm, it sounds like the right way to solve this.
> Maybe this could solve the problem with the transition to rsync_t from user
> domains while rsync is running over ssh. Great.
> Thanks for suggestion.
> -- 
> Zito

Please hit me to the right direction. ;)

I have prepared a patch - domain for ldd, but did not know, how to
prevent SE Linux from trying transition into other domains.

For this time I allow ldd only for sysadm.

test at sid:~$ ldd /sbin/udevd
[ 7994.537291] type=1401 audit(1220882097.504:11): security_compute_sid:  invalid context sysadm_u:system_r:ldd_t:s0 for scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=process
[ 7994.541371] type=1400 audit(1220882097.504:11): avc:  denied  { transition }
for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=sysadm_u:system_r:ldd_t:s0 tclass=process
[ 7994.547602] type=1400 audit(1220882097.504:11): avc:  denied  { entrypoint }
for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:system_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=file
[ 7994.566746] type=1300 audit(1220882097.504:11): arch=40000003 syscall=11 success=yes exit=0 a0=9d21fc8 a1=9d21928 a2=9d19008 a3=0 items=0 ppid=4282 pid=4283
auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=sysadm_u:system_r:ldd_t:s0 key=(null)
        linux-gate.so.1 =>  (0xb7f30000)
        libselinux.so.1 => /lib/libselinux.so.1 (0xb7f0f000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7db4000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7daf000)
        /lib/ld-linux.so.2 (0xb7f31000)
test at sid:~$


zito at sid:~$ sesearch -T -t udev_exec_t
Found 6 semantic te rules:
   type_transition sysadm_t udev_exec_t : process udev_t; 
   type_transition unconfined_t udev_exec_t : process udev_t; 
   type_transition kernel_t udev_exec_t : process udev_t; 
   type_transition hald_t udev_exec_t : process udev_t; 
   type_transition initrc_t udev_exec_t : process udev_t; 
   type_transition hotplug_t udev_exec_t : process udev_t; 

There is no type_transition rule for ldd_t.


zito at sid:~$ sesearch -A -s ldd_t -t udev_exec_t
Found 1 semantic av rules:
   allow ldd_t @ttr0292 : file { ioctl read getattr lock execute execute_no_trans } ; 

Ldd has allow rule for execute_no_trans, so SE Linux should quietly
execute udevd without transition. Am I wrong?

Should be there a separate module for ldd or is the draft acceptable?
Thanks
-- 
Zito
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldd.patch
Type: text/x-diff
Size: 4281 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20080908/0725f93f/attachment.bin 

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Christopher J. PeBenito]

On Mon, 2008-09-08 at 16:15 +0200, V?clav Ovs?k wrote:
> On Wed, Sep 03, 2008 at 03:52:37PM +0200, V?clav Ovs?k wrote:
> > > ...
> > > ldd is just a shell script, which does "LD_TRACE_LOADED_OBJECTS=1 $cmd" (you
> > > can run that on the command line if you want).  Setting
> > > LD_TRACE_LOADED_OBJECTS causes the dynamic linker to link the program and
> > > output the objects it has linked but then exit without calling main().
> > > 
> > > Since $cmd is never properly executed, it doesn't make sense to be
> > > transitioning to its domain.  So I think ldd should have a domain of its
> > > own, which has no privileges except to write to the terminal and to
> > > execute_no_trans everything.
> > 
> > Hmm, it sounds like the right way to solve this.

I'm not entirely convinced that ldd should have its own domain.  ldd
should only have access to binaries that the caller has access to.  By
having a special domain you lose that.

I'm kicking around the idea that ldd should just setexeccon() to the
current domain when it does the "LD_TRACE_LOADED_OBJECTS=1 $cmd" to
override any transition that might exist in the policy.  But that causes
problems if the domain can't setexeccon(), unless those failures are
nonfatal.  But then you could still be denied if the caller domain
doesn't have execute_no_trans permission on the binary.  So even this
isn't a perfect solution.

> > Maybe this could solve the problem with the transition to rsync_t from user
> > domains while rsync is running over ssh. Great.

I don't know what problem you're referring to.

> Please hit me to the right direction. ;)
> 
> I have prepared a patch - domain for ldd, but did not know, how to
> prevent SE Linux from trying transition into other domains.
> 
> For this time I allow ldd only for sysadm.
> 
> test at sid:~$ ldd /sbin/udevd
> [ 7994.537291] type=1401 audit(1220882097.504:11): security_compute_sid:  invalid context sysadm_u:system_r:ldd_t:s0 for scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=process
> [ 7994.541371] type=1400 audit(1220882097.504:11): avc:  denied  { transition }
> for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=sysadm_u:system_r:ldd_t:s0 tclass=process
> [ 7994.547602] type=1400 audit(1220882097.504:11): avc:  denied  { entrypoint }
> for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:system_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=file
> [ 7994.566746] type=1300 audit(1220882097.504:11): arch=40000003 syscall=11 success=yes exit=0 a0=9d21fc8 a1=9d21928 a2=9d19008 a3=0 items=0 ppid=4282 pid=4283
> auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=sysadm_u:system_r:ldd_t:s0 key=(null)
>         linux-gate.so.1 =>  (0xb7f30000)
>         libselinux.so.1 => /lib/libselinux.so.1 (0xb7f0f000)
>         libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7db4000)
>         libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7daf000)
>         /lib/ld-linux.so.2 (0xb7f31000)
> test at sid:~$
> 
> 
> zito at sid:~$ sesearch -T -t udev_exec_t
> Found 6 semantic te rules:
>    type_transition sysadm_t udev_exec_t : process udev_t; 
>    type_transition unconfined_t udev_exec_t : process udev_t; 
>    type_transition kernel_t udev_exec_t : process udev_t; 
>    type_transition hald_t udev_exec_t : process udev_t; 
>    type_transition initrc_t udev_exec_t : process udev_t; 
>    type_transition hotplug_t udev_exec_t : process udev_t; 
> 
> There is no type_transition rule for ldd_t.
> 
> 
> zito at sid:~$ sesearch -A -s ldd_t -t udev_exec_t
> Found 1 semantic av rules:
>    allow ldd_t @ttr0292 : file { ioctl read getattr lock execute execute_no_trans } ; 
> 
> Ldd has allow rule for execute_no_trans, so SE Linux should quietly
> execute udevd without transition. Am I wrong?

Unfortunately I don't see why you are encountering this behavior, based
on the messages and the patch you attached.  Without the type_transition
there shouldn't be a transition, unless there was a setexeccon() in the
ldd script, in which case you'd see a corresponding denial for that
permission.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Martin Orr]

On 08/09/08 16:31, Christopher J. PeBenito wrote:
> On Mon, 2008-09-08 at 16:15 +0200, V?clav Ovs?k wrote:
>> On Wed, Sep 03, 2008 at 03:52:37PM +0200, V?clav Ovs?k wrote:
>>>> ...
>>>> ldd is just a shell script, which does "LD_TRACE_LOADED_OBJECTS=1 $cmd" (you
>>>> can run that on the command line if you want).  Setting
>>>> LD_TRACE_LOADED_OBJECTS causes the dynamic linker to link the program and
>>>> output the objects it has linked but then exit without calling main().
>>>>
>>>> Since $cmd is never properly executed, it doesn't make sense to be
>>>> transitioning to its domain.  So I think ldd should have a domain of its
>>>> own, which has no privileges except to write to the terminal and to
>>>> execute_no_trans everything.
>>> Hmm, it sounds like the right way to solve this.
> 
> I'm not entirely convinced that ldd should have its own domain.  ldd
> should only have access to binaries that the caller has access to.  By
> having a special domain you lose that.

Hmm, that's true.

> I'm kicking around the idea that ldd should just setexeccon() to the
> current domain when it does the "LD_TRACE_LOADED_OBJECTS=1 $cmd" to
> override any transition that might exist in the policy.  But that causes
> problems if the domain can't setexeccon(), unless those failures are
> nonfatal.  But then you could still be denied if the caller domain
> doesn't have execute_no_trans permission on the binary.  So even this
> isn't a perfect solution.

It occurs to me that any time a domain transtion occurs when ldd does
"LD_TRACE_LOADED_OBJECTS=1 $cmd", AT_SECURE will kick in and the linker
will refuse to do the tracing. So ldd will fall back to
"LD_TRACE_LOADED_OBJECTS=1 $rtld $cmd" (where rtld=/lib/ld-linux.so.2 or
whatever your system's dynamic linker is).

If ldd always did "LD_TRACE_LOADED_OBJECTS=1 $rtld $cmd" then it would
always run with no transition (although I assume there is some reason
why it tries "LD_TRACE_LOADED_OBJECTS=1 $rtld $cmd" first).

Note that any domain which runs ldd already needs to be able to execute
$rtld, as ldd does "$rtld --verify $cmd" before running $cmd.

However, by allowing a domain to run $rtld, you are effectively giving it
execute_no_trans permission on all files it has execute permission to. I
doubt it is possible to get a perfect solution if the same linker is used
for ldd and for actually executing programs (except by putting more
enforcement logic in the linker).

>>> Maybe this could solve the problem with the transition to rsync_t from user
>>> domains while rsync is running over ssh. Great.
> 
> I don't know what problem you're referring to.
> 
>> Please hit me to the right direction. ;)
>>
>> I have prepared a patch - domain for ldd, but did not know, how to
>> prevent SE Linux from trying transition into other domains.
>>
>> For this time I allow ldd only for sysadm.
>>
>> test at sid:~$ ldd /sbin/udevd
>> [ 7994.537291] type=1401 audit(1220882097.504:11): security_compute_sid:  invalid context sysadm_u:system_r:ldd_t:s0 for scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=process
>> [ 7994.541371] type=1400 audit(1220882097.504:11): avc:  denied  { transition }
>> for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=sysadm_u:system_r:ldd_t:s0 tclass=process
>> [ 7994.547602] type=1400 audit(1220882097.504:11): avc:  denied  { entrypoint }
>> for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:system_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=file
>> [ 7994.566746] type=1300 audit(1220882097.504:11): arch=40000003 syscall=11 success=yes exit=0 a0=9d21fc8 a1=9d21928 a2=9d19008 a3=0 items=0 ppid=4282 pid=4283
>> auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=sysadm_u:system_r:ldd_t:s0 key=(null)
>>         linux-gate.so.1 =>  (0xb7f30000)
>>         libselinux.so.1 => /lib/libselinux.so.1 (0xb7f0f000)
>>         libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7db4000)
>>         libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7daf000)
>>         /lib/ld-linux.so.2 (0xb7f31000)
>> test at sid:~$
>>
>>
>> zito at sid:~$ sesearch -T -t udev_exec_t
>> Found 6 semantic te rules:
>>    type_transition sysadm_t udev_exec_t : process udev_t; 
>>    type_transition unconfined_t udev_exec_t : process udev_t; 
>>    type_transition kernel_t udev_exec_t : process udev_t; 
>>    type_transition hald_t udev_exec_t : process udev_t; 
>>    type_transition initrc_t udev_exec_t : process udev_t; 
>>    type_transition hotplug_t udev_exec_t : process udev_t; 
>>
>> There is no type_transition rule for ldd_t.
>>
>>
>> zito at sid:~$ sesearch -A -s ldd_t -t udev_exec_t
>> Found 1 semantic av rules:
>>    allow ldd_t @ttr0292 : file { ioctl read getattr lock execute execute_no_trans } ; 
>>
>> Ldd has allow rule for execute_no_trans, so SE Linux should quietly
>> execute udevd without transition. Am I wrong?

Is it a consequence of
role_transition sysadm_r udev_exec_t system_r
(if you have DIRECT_INITRC)?

Best wishes,

-- 
Martin Orr

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Václav Ovsík]

On Thu, Sep 11, 2008 at 08:00:36PM +0100, Martin Orr wrote:
> On 08/09/08 16:31, Christopher J. PeBenito wrote:
> > On Mon, 2008-09-08 at 16:15 +0200, V?clav Ovs?k wrote:
> >> On Wed, Sep 03, 2008 at 03:52:37PM +0200, V?clav Ovs?k wrote:
> >>>> ...
> >>>> ldd is just a shell script, which does "LD_TRACE_LOADED_OBJECTS=1 $cmd" (you
> >>>> can run that on the command line if you want).  Setting
> >>>> LD_TRACE_LOADED_OBJECTS causes the dynamic linker to link the program and
> >>>> output the objects it has linked but then exit without calling main().
> >>>>
> >>>> Since $cmd is never properly executed, it doesn't make sense to be
> >>>> transitioning to its domain.  So I think ldd should have a domain of its
> >>>> own, which has no privileges except to write to the terminal and to
> >>>> execute_no_trans everything.
> >>> Hmm, it sounds like the right way to solve this.
> > 
> > I'm not entirely convinced that ldd should have its own domain.  ldd
> > should only have access to binaries that the caller has access to.  By
> > having a special domain you lose that.
> 
> Hmm, that's true.
> 
> > I'm kicking around the idea that ldd should just setexeccon() to the
> > current domain when it does the "LD_TRACE_LOADED_OBJECTS=1 $cmd" to
> > override any transition that might exist in the policy.  But that causes
> > problems if the domain can't setexeccon(), unless those failures are
> > nonfatal.  But then you could still be denied if the caller domain
> > doesn't have execute_no_trans permission on the binary.  So even this
> > isn't a perfect solution.
> 
> It occurs to me that any time a domain transtion occurs when ldd does
> "LD_TRACE_LOADED_OBJECTS=1 $cmd", AT_SECURE will kick in and the linker
> will refuse to do the tracing. So ldd will fall back to
> "LD_TRACE_LOADED_OBJECTS=1 $rtld $cmd" (where rtld=/lib/ld-linux.so.2 or
> whatever your system's dynamic linker is).
> 
> If ldd always did "LD_TRACE_LOADED_OBJECTS=1 $rtld $cmd" then it would
> always run with no transition (although I assume there is some reason
> why it tries "LD_TRACE_LOADED_OBJECTS=1 $rtld $cmd" first).
> 
> Note that any domain which runs ldd already needs to be able to execute
> $rtld, as ldd does "$rtld --verify $cmd" before running $cmd.
> 
> However, by allowing a domain to run $rtld, you are effectively giving it
> execute_no_trans permission on all files it has execute permission to. I
> doubt it is possible to get a perfect solution if the same linker is used
> for ldd and for actually executing programs (except by putting more
> enforcement logic in the linker).

While I was reading this, I opened /usr/bin/ldd to look in it and was
a bit surprise with a block:

=> # The following use of cat is needed to make ldd work in SELinux
=> # environments where the executed program might not have permissions
=> # to write to the console/tty.  But only bash 3.x supports the pipefail
=> # option, and we don't bother to handle the case for older bash versions.
=> if set -o pipefail 2> /dev/null; then
=>   try_trace() {
=>     eval $add_env '"$@"' | cat
=>   }
=> else
=>   try_trace() {
=>     eval $add_env '"$@"'
=>   }
=> fi

I must completely overlook this for the first time. I am going to play
with it a bit. I hope some correction of this can eliminate our headache
on the policy side. I will write a next week.


> >>> Maybe this could solve the problem with the transition to rsync_t from user
> >>> domains while rsync is running over ssh. Great.
> > 
> > I don't know what problem you're referring to.
> > 
> >> Please hit me to the right direction. ;)
> >>
> >> I have prepared a patch - domain for ldd, but did not know, how to
> >> prevent SE Linux from trying transition into other domains.
> >>
> >> For this time I allow ldd only for sysadm.
> >>
> >> test at sid:~$ ldd /sbin/udevd
> >> [ 7994.537291] type=1401 audit(1220882097.504:11): security_compute_sid:  invalid context sysadm_u:system_r:ldd_t:s0 for scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=process
> >> [ 7994.541371] type=1400 audit(1220882097.504:11): avc:  denied  { transition }
> >> for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:sysadm_r:ldd_t:s0 tcontext=sysadm_u:system_r:ldd_t:s0 tclass=process
> >> [ 7994.547602] type=1400 audit(1220882097.504:11): avc:  denied  { entrypoint }
> >> for  pid=4283 comm="ldd" path="/sbin/udevd" dev=hda2 ino=114501 scontext=sysadm_u:system_r:ldd_t:s0 tcontext=system_u:object_r:udev_exec_t:s0 tclass=file
> >> [ 7994.566746] type=1300 audit(1220882097.504:11): arch=40000003 syscall=11 success=yes exit=0 a0=9d21fc8 a1=9d21928 a2=9d19008 a3=0 items=0 ppid=4282 pid=4283
> >> auid=4294967295 uid=1001 gid=1001 euid=1001 suid=1001 fsuid=1001 egid=1001 sgid=1001 fsgid=1001 tty=tty1 ses=4294967295 comm="udevd" exe="/sbin/udevd" subj=sysadm_u:system_r:ldd_t:s0 key=(null)
> >>         linux-gate.so.1 =>  (0xb7f30000)
> >>         libselinux.so.1 => /lib/libselinux.so.1 (0xb7f0f000)
> >>         libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7db4000)
> >>         libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7daf000)
> >>         /lib/ld-linux.so.2 (0xb7f31000)
> >> test at sid:~$
> >>
> >>
> >> zito at sid:~$ sesearch -T -t udev_exec_t
> >> Found 6 semantic te rules:
> >>    type_transition sysadm_t udev_exec_t : process udev_t; 
> >>    type_transition unconfined_t udev_exec_t : process udev_t; 
> >>    type_transition kernel_t udev_exec_t : process udev_t; 
> >>    type_transition hald_t udev_exec_t : process udev_t; 
> >>    type_transition initrc_t udev_exec_t : process udev_t; 
> >>    type_transition hotplug_t udev_exec_t : process udev_t; 
> >>
> >> There is no type_transition rule for ldd_t.
> >>
> >>
> >> zito at sid:~$ sesearch -A -s ldd_t -t udev_exec_t
> >> Found 1 semantic av rules:
> >>    allow ldd_t @ttr0292 : file { ioctl read getattr lock execute execute_no_trans } ; 
> >>
> >> Ldd has allow rule for execute_no_trans, so SE Linux should quietly
> >> execute udevd without transition. Am I wrong?
> 
> Is it a consequence of
> role_transition sysadm_r udev_exec_t system_r
> (if you have DIRECT_INITRC)?
> 
> Best wishes,
> 
> -- 
> Martin Orr

Yes, this role_transition is present:

sid:~# sesearch --role_trans -t udev_exec_t
Found 2 role_transition rules:
   role_transition sysadm_r udev_exec_t system_r;
   role_transition unconfined_r udev_exec_t system_r;

And can be above denials consequence of this role_transition rule?

Regards
-- 
Zito

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Václav Ovsík]

On Fri, Sep 12, 2008 at 04:29:22PM +0200, V?clav Ovs?k wrote:
> While I was reading this, I opened /usr/bin/ldd to look in it and was
> a bit surprise with a block:
> 
> => # The following use of cat is needed to make ldd work in SELinux
> => # environments where the executed program might not have permissions
> => # to write to the console/tty.  But only bash 3.x supports the pipefail
> => # option, and we don't bother to handle the case for older bash versions.
> => if set -o pipefail 2> /dev/null; then
> =>   try_trace() {
> =>     eval $add_env '"$@"' | cat
> =>   }
> => else
> =>   try_trace() {
> =>     eval $add_env '"$@"'
> =>   }
> => fi
> 
> I must completely overlook this for the first time. I am going to play
> with it a bit. I hope some correction of this can eliminate our headache
> on the policy side. I will write a next week.

A little improvement of workaround already part of ldd:

--- /usr/bin/ldd.orig	2008-07-29 07:21:35.000000000 +0200
+++ /usr/bin/ldd	2008-09-15 12:22:01.000000000 +0200
@@ -114,7 +114,7 @@
 # option, and we don't bother to handle the case for older bash versions.
 if set -o pipefail 2> /dev/null; then
   try_trace() {
-    eval $add_env '"$@"' | cat
+    eval $add_env '"$@"' <&- 2>&1 | cat
   }
 else
   try_trace() {

That is - all inherited file descriptors connected to an user terminal
are moved away. The SE Linux denial disappeared. Sorry for noise with
ldd domain, it can be forgotten.
Reported as bug in Debian BTS:
...hmm, still not arrived assignment after several hours...
I will send a bug number later.
Regards
-- 
Zito

[refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds

[Václav Ovsík]

On Mon, Sep 15, 2008 at 03:36:30PM +0200, V?clav Ovs?k wrote:
> ...
> Reported as bug in Debian BTS:
> ...hmm, still not arrived assignment after several hours...
> I will send a bug number later.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499016

-- 
Zito