F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

Miloslav Trmač mitr at volny.cz
Thu Mar 27 20:03:20 UTC 2014


2014-03-27 20:57 GMT+01:00 Daniel J Walsh <dwalsh at redhat.com>:
>
> On 03/27/2014 01:49 PM, Miloslav Trmač wrote:
>> 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik <jreznik at redhat.com>:
>>> == Detailed Description ==
>>> When PrivateDevices=yes...
>>> Furthermore, the
>>> CAP_MKNOD capability is removed. Finally, the "devices" cgroup controller is
>>> used to ensure that no access to device nodes except the listed ones is
>>> possible.
>>> When PrivateNetwork=yes ...
>>>     4. This also disconnects the AF_UNIX abstract namespace
>>>     5. This also disconnects the AF_NETLINK and AF_AUDIT socket families
>> How much does this overlap existing SELinux policy?  Would it make
>> sense to have both configured from a single source?  It seems to me
>> that every inconsistency between the systemd unit file and the SELinux
>> policy must be a bug; could we eliminate this class of bugs entirely,
>> or if fully automated extraction of the information between the two
>> data sets weren't feasible, would it make sense to have and regularly
>> run tools that compare the two policies?
>>     Mirek
> It doesn't really overlap with SELinux, just adds another layer of
> security.
Layers tend to overlap :) in affected areas, if not in specific implementation.

> And gives the administrator more flexibility on how he
> configures his services.  I do not think there are two many confined
> domains that need mknod, and most confined domains are not allowed to
> look at many device nodes.

So, could we generate a starting list of daemons to be restricted by
PrivateDevices by looking for domains that aren't allowed in the
SELinux policy to look at device nodes?  And use the fixes previously
done in the SELinux policy to notice daemons that actually do need
access to devices without ever publishing a RPM with a too constrained
systemd unit to users?

That's where I was going with this--possibly up to possible full
bidirectional synchronization between SELinux and systemd units.
    Mirek


More information about the devel mailing list