From: martin@martinorr.name (Martin Orr) Date: Thu, 11 Sep 2008 20:00:36 +0100 Subject: [refpolicy] Debian: ldd /sbin/udevd, need to use interactive fds In-Reply-To: <1220887889.28287.117.camel@gorn> 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> Message-ID: <48C96AD4.1000009@martinorr.name> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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