Proposal: ReadOnlyDirectories /etc and /usr for network-services

[Bill Nottingham]

Reindl Harald (h.reindl at thelounge.net) said: 
> a httpd running with SElinux disabled or in permissive mode with
> the 4 lines below even after escalate to root privileges will
> hardly have a chance to overwrite /usr/sbin/sshd as example
> 
> CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID
> NoNewPrivileges=yes
> ReadOnlyDirectories=/etc
> ReadOnlyDirectories=/usr

So I do see some issues with something like this, and I'll admit, they may
not be easily solved.

1) This is 4 separate independent configuration directives (and leaves out
things like SecureBits), not to mention it iterates over a list of
capabilities.  Setting all of them requires the admin/packager to understand
the intersection of all of them, which may not be simple to apply correctly.
(And you want to be careful with security controls in the hands of those not
used to applying them correctly.)

2) It's also mixing specific implementation details (CapabilityBoundingSet)
with more abstract concepts mapped to implementation details (NoNewPrivileges).
That can leave the behavior confusing.

3) ReadOnlyDirectories also needs to be applied across submounts, which
introduces complication to the system units depending on the filesystem
layout on the administrator-configured machine - having security mechanisms
be affected by this is not ideal.

On the one hand, it's best to be explicit about what it's trying to do to
secure the service, hence the many options to be set.  On the other hand, it
makes it much easier for the packager and admin to apply these sorts of
service configurations correctly by mapping all options you'd need into more
logical options that are easily explained.

(Think of it as the same thing as exposing cgroupfs, vs exposing slices.)

Bill