On Mon, Oct 27, 2014 at 03:38:37PM +0100, Lennart Poettering wrote: > On Sat, 11.10.14 21:57, m...@zarb.org (m...@zarb.org) wrote: > > > From: Michael Scherer <m...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
