From: mgrepl@redhat.com (Miroslav Grepl)
Date: Tue, 04 Sep 2012 12:18:58 +0200
Subject: [refpolicy] [PATCH v1 5/5] Udev's tables (run data) is stored
 in directories
In-Reply-To: <1346615503.15262.23.camel@d30.localdomain>
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>
Message-ID: <5045D592.7050701@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 09/02/2012 09:51 PM, 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
Is it based on Fedora 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
>>
>>
>>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy