From: vaclav.ovsik@i.cz (=?iso-8859-1?Q?V=E1clav_Ovs=EDk?=) Date: Fri, 12 Sep 2008 16:29:22 +0200 Subject: [refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds In-Reply-To: <48C96AD4.1000009@martinorr.name> References: <20080901171232.GA4104@bobek.pm.i.cz> <1220361593.28287.8.camel@gorn> <48BE7371.2000100@martinorr.name> <20080903135237.GA7644@bobek.pm.i.cz> <20080908141529.GA22294@bobek.pm.i.cz> <1220887889.28287.117.camel@gorn> <48C96AD4.1000009@martinorr.name> Message-ID: <20080912142922.GA29549@bobek.pm.i.cz> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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