From: guido@trentalancia.com (Guido Trentalancia) Date: Sun, 09 Sep 2012 18:51:33 +0200 Subject: [refpolicy] [PATCH v1 5/5] Udev's tables (run data) is stored in directories In-Reply-To: <1346761622.2250.14.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> <1346615503.15262.23.camel@d30.localdomain> <1346615998.15262.25.camel@d30.localdomain> <1346761622.2250.14.camel@vortex> Message-ID: <504CC915.4050409@trentalancia.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 04/09/2012 14:27, Guido Trentalancia wrote: > 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. Yes, I am personally starting to drop this in favour of reverting back to sysvinit and perhaps even drop udev, because it seems to be just evolving towards overengineering with no tangible benefit at all... > 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 Apart from the warning, that is due to a printout message recently added in the source code, it can essentially proceed without relabelling /run/udev as that is SELinux domain and almost no application or daemon should be relabelling filesystems (with the exception of a few applications such as the installers from the various distributions, if the relative module is loaded in modular policy). As already said, it should be possible to tackle such problem by adding /run to restorecond.conf and making sure that restorecond is started early enough during boot and/or statically relabel runtime udev files at boot-time (restorecon calls from rc startup scripts or similar methods). > udev: failed to create queue file: No such file or directory The latter is not related to SELinux but to local misconfiguration. > 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