From: guido@trentalancia.com (Guido Trentalancia)
Date: Tue, 04 Sep 2012 16:51:09 +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: <5046155D.8030100@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.
>
> 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 ?

Init is supposed to be a simple thing in functionality which switches 
the runlevels and eventually shuts down the system...

Is this going to be a third replacement of old good init ? Perhaps 
aiming at centralizing everything in one daemon ?

Everything is digital there will always going to be one single point of 
failure anyway, from a single line of C code for example, down to an 
assembly instruction and ultimately to the value of one single bit...

The system I am using for testing is still using upstart as init and it 
is now a bit unstable after all these changes...

This centralization is diverting from modularity, while the point of 
failure will always ultimately be one single bit.

Hopefully it will become stable again soon...

Regards,

Guido