From: dominick.grift@gmail.com (Dominick Grift)
Date: Sun, 02 Sep 2012 21:51:43 +0200
Subject: [refpolicy] [PATCH v1 5/5] Udev's tables (run data) is stored
 in directories
In-Reply-To: <1346587580.7338.0.camel@vortex>
References: <1346268526-22260-1-git-send-email-sven.vermeulen@siphos.be>
	<1346268526-22260-6-git-send-email-sven.vermeulen@siphos.be>
	<1346269075.15262.3.camel@d30.localdomain>
	<20120829195527.GA22738@siphos.be>
	<1346270641.15262.10.camel@d30.localdomain>
	<1346271637.15262.13.camel@d30.localdomain>
	<1346272266.15262.19.camel@d30.localdomain>
	<1346587580.7338.0.camel@vortex>
Message-ID: <1346615503.15262.23.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com



On Sun, 2012-09-02 at 14:06 +0200, Guido Trentalancia wrote:
> On Wed, 2012-08-29 at 22:31 +0200, Dominick Grift wrote:
> > 
> > On Wed, 2012-08-29 at 22:20 +0200, Dominick Grift wrote:
> > > 
> > > On Wed, 2012-08-29 at 22:04 +0200, Dominick Grift wrote:
> > > > 
> > > > On Wed, 2012-08-29 at 21:55 +0200, Sven Vermeulen wrote:
> > > > > On Wed, Aug 29, 2012 at 09:37:55PM +0200, Dominick Grift wrote:
> > > > > > > -# create udev database in /dev/.udevdb
> > > > > > > -allow udev_t udev_tbl_t:file manage_file_perms;
> > > > > > > +allow udev_t udev_tbl_t:dir relabelto;
> > > > > > > +manage_dirs_pattern(udev_t, udev_tbl_t, udev_tbl_t)
> > > > > > > +manage_files_pattern(udev_t, udev_tbl_t, udev_tbl_t)
> > > > > > > +manage_lnk_files_pattern(udev_t, udev_tbl_t, udev_tbl_t)
> > > > > > > +
> > > > > > >  dev_filetrans(udev_t, udev_tbl_t, file)
> > > > > > 
> > > > > > This doesnt make sense to me.
> 
> [cut]
> 
> > > > > Well, the udev code (looking at udev-182 here) has the code for relabeling
> > > > > in it. For instance, when copy_dev_dir is called, it has
> > > > > 
> > > > > #v+
> > > > >                         udev_selinux_setfscreateconat(udev, dirfd(dir_to), dent->d_name, S_IFDIR|0755);
> > > > >                         mkdirat(dirfd(dir_to), dent->d_name, 0755);
> > > > >                         udev_selinux_resetfscreatecon(udev);
> > > > > #v-
> > > > > 
> > > > > I believe this is the source, but I'm no master in this. I mainly based
> > > > > myself on the denials and errors I got. If I put in an "auditallow" to show
> > > > > this, this is the result:
> 
> At a quick look, the code in most recent versions (the one merged in
> systemd) apparently has been extended even further in that direction by
> adding a shared label.c source file.
> 
> As for such labelling issue, since it is usually always preferable that
> each one sticks to its own job, perhaps it can be dontaudited and then
> the relevant "dynamic" path added to restorecond.conf ?
> 
> The strange thing is that I am running latest udev without any of these
> modifications (thus including the relabel permission)...

I am currently rewriting udev policy as part of my project to write a
systemd policy and i havent noticed this either yet, although it is
hinting at it (it needs setfscreate capability and so does systemd by
the way)

I am not letting these daemons run my security though.

> Regards,
> 
> Guido
> 
> 
>