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

[Daniel P. Berrange]

On Mon, Jul 22, 2013 at 06:37:01PM +0200, Miloslav Trmač wrote:
> On Mon, Jul 22, 2013 at 6:22 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> > On Mon, Jul 22, 2013 at 04:53:36PM +0200, Miloslav Trmač wrote:
> >> On Mon, Jul 22, 2013 at 12:02 AM, Reindl Harald <h.reindl at thelounge.net> wrote:
> >> > has anybody considered to put the following as default in systemd-units of
> >> > network services? cross-posting to  users-list intented because i think it
> >> > is a good idea to bring it to a broader userbase!
> >> >
> >> > ReadOnlyDirectories=/etc
> >> > ReadOnlyDirectories=/usr
> >>
> >> I think it's generally known by now that I don't like namespaces as a
> >> security mechanism.  At best, this is duplicating SELinux policy with
> >> less transparency and worse tools.
> >
> > Namespaces really aren't duplicating SELinux policy, they are working
> > in a complementary fashion. There is clear value in having multiple
> > layers of security defence because things do fail for any number of
> > reasons.
> 
> The returns to additional layers enforcing the same policy are rapidly
> diminishing, though.  We already have DAC permissions, and MAC policy,
> and a third layer is being proposed.  Why not have four or ten?  We
> have to stop somewhere.

Counting layers of protection is not a helpful way to make decisions
on usage of security. As I said in my previous mail you should evaluate
the benefits of any proposed technology, and not rule it out simply
because we already have other options.

> >> (The network services shouldn't be running as root in the first place.)
> >
> > No argument there, but even if something is running as non-root there is
> > the potential for privilege escalation through security flaws in some
> > thing that they use. In such a scenario having a separate filesystem
> > namespace which has made certain areas read-only may well stop the
> > exploit.
> 
> If I am able to escalate to root privileges, I can just switch back to
> the system namespace using setns(2), so the protection doesn't
> actually exist.  So we're talking about limited circumstances where
> the attacker can modify files and not execute code, or where the
> attacker is root but not CAP_SYS_ADMIN (or whatever it is).

Using setns() requires opening a FD to /proc/$PID/ns/mount for a $PID in
the target namespace. If putting the service in a separate mount namespace,
it is easy to also set CLONE_PID, at which point the /proc/$PID/ns files
for any other process are no longer accessible.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|