From: vaclav.ovsik@i.cz (=?iso-8859-2?Q?V=E1clav_Ovs=EDk?=)
Date: Tue, 2 Sep 2008 16:27:39 +0200
Subject: [refpolicy] Debian: ldd /sbin/udevd, need to use interactive	fds
In-Reply-To: <1220361593.28287.8.camel@gorn>
References: <20080901171232.GA4104@bobek.pm.i.cz>
	<1220361593.28287.8.camel@gorn>
Message-ID: <20080902142739.GA21152@bobek.pm.i.cz>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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