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

[martin@martinorr.name (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