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

[Michael Scherer]

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.

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

CVE-2012-0056 local root exploit, requires to open /proc/$PARENT/mem to work 
 http://git.zx2c4.com/CVE-2012-0056/tree/mempodipper.c

CVE-2011-2495 /proc/ information leak
 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-2495

CVE-2011-1593 local root exploit, requires to read /proc to be exploited
 http://xorl.wordpress.com/2011/04/25/cve-2011-1593-linux-kernel-proc-next_pidmap-invalid-memory-access/ )

CVE-2011-1020 race condition on /proc permitting DOS
 https://access.redhat.com/security/cve/CVE-2011-1020

I also wonder how it would be broken, since /proc access is very restricted 
inside openshift due to selinux and most if not all softwares work fine here.
 
> If you apply the apparmor profile before setting up the namespace
> stuff you need to whitelist all the namespace operations in the
> apparmor profile. That might be quite a lot, hence: is this really
> desirable?

Apparmor profile is applied on next exec with aa_change_onexec, so we are
not restricted until we switch to the daemon, no need to whitelist anything.
( unless we start to use system/fork/exec in the exec_child function but I think
we want to avoid that ).

-- 
Michael Scherer