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 > > >