2014-03-27 20:57 GMT+01:00 Daniel J Walsh <dwa...@redhat.com>:
>
> On 03/27/2014 01:49 PM, Miloslav Trmač wrote:
>> 2014-03-26 15:06 GMT+01:00 Jaroslav Reznik <jrez...@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
