[refpolicy] [PATCH v1 5/5] Udev's tables (run data) is stored in directories

[guido@trentalancia.com (Guido Trentalancia)]

On Sun, 2012-09-02 at 21:59 +0200, Dominick Grift wrote:
> 
> On Sun, 2012-09-02 at 21:51 +0200, Dominick Grift wrote:
> > 
> > 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.

As already said, relabelling is critical, it is SELinux-domain by
definition and therefore it should not normally be required/allowed. It
makes me wonder whether the daemon is getting slightly over-engineered ?

>From raw testing, it seems that it produces a few warnings:

udev: Failed to initialize SELinux context: No such file or directory
udev: failed to create queue file: No such file or directory

Have you tried to test it without the new permissions ?

> That plus i do not like hard-coding types. it is degrading selinux

What do you mean exactly for hard-coding types ?

Degradation just for the sake of keeping things running is bad as in
allowing permissions that are not normally required for carrying out a
given task.

At the end, it has just more or less rebased from /var/run and /dev
to /run/udev.

Regards,

Guido