[systemd-devel] [PATCH] Move apparmor code before the namespace setup

[Lennart Poettering]

On Mon, 27.10.14 20:16, Michael Scherer (misc at zarb.org) wrote:

> On Mon, Oct 27, 2014 at 03:38:37PM +0100, Lennart Poettering wrote:
> > On Sat, 11.10.14 21:57, misc at zarb.org (misc at zarb.org) wrote:
> > 
> > > From: Michael Scherer <misc at zarb.org>
> > > 
> > > Since apparmor need to access /proc to communicate with the kernel,
> > > any unit setting / as readonly will be unable to also use the
> > > AppArmorProfile setting, as found on debian bug 760526.
> > 
> > A unit that sets /proc to read-only is broken anyway, I don't think we
> > should work around that. or am I missing something here?
> 
> When a unit set / as readonly, /proc seems to become readonly too.

Yes, it ReadOnlyDirectories= is recursive. People doing that should
use ReadWriteDirectories=/proc to open up /proc again.

Note that ReadOnlyDirectories= and ReadWriteDirectories= are low-level
functionality. If you use it you really should know what you do. This
is different from ProtectSystem= which is a lot more high-level and
doesn't require you to think about all the details.

> And I would count setting /proc as readonly ( or unreadable ) as a hardening 
> measure to reduce the attack surface. 

Well, people can do whatever they want, but write access to /proc is
part of the Linux API, there's ton of functionality that processes
need access to that is only available via writes to /proc. You cannot
really take this away, except for trivial programs. systemd is really
not the place to push for read-only /proc/self/... 

The APIs in /proc are generally useful APIs, you cannot just declare
them unnecessary, take them away and assume things to still work.

Lennart

-- 
Lennart Poettering, Red Hat