On Mon, 27.10.14 20:16, Michael Scherer (m...@zarb.org) wrote: > 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.
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
