Am 27.10.2014 um 23:20 schrieb Lennart Poettering:
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
in fact you can even set InaccessibleDirectories=/proc InaccessibleDirectories=/sysand httpd, trafficserver, dovecot, postfix, spamassassin, clamd and what not else just works without any single issue
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
