intrigeri <intrig...@debian.org> writes: > You surely could, but reimplementing exactly the same protections is > probably not the best use of your time.
> Now, each of systemd and AppArmor can do hardening stuff that the > other doesn't support (at all or nicely), so sometimes it's good to do > a little bit of both. > What I would do these days: > 1. Use the simplest of systemd's hardening features (e.g. > Protect{Home,System}=, Private{Devices,Tmp,Network}=, > CapabilityBoundingSet=) to their full extend. > Not many unit files we ship do that yet. Generally these > improvements can be implemented upstream and benefit users of > systemd on other distros :) To this, I would add SystemCallFilters, which is immensely powerful and much easier to use now than it was originally. I think a lot of the benefit of hardening for a lot of network daemons would come from tested use of SystemCallFilters (probably only using the @group syntax). This blocks so many local privilege escalation bugs in random Linux syscalls, making an RCE in a daemon running as a non-root user much less scary. (For those not familiar, this is seccomp filtering, except about as easy to use as seccomp can be. It's not as good as a carefully crafted full seccomp policy, but you can get quite a bit of mileage out of some fairly simple rules.) Note that SystemCallFilters was very difficult to use in jessie since the syscall groups weren't implemented yet. I would not recommend trying to use it if targeting anything older than stretch. > 2. For finer-grained mediation of filesystem access, I will use > AppArmor that I find much nicer to implement, use and debug: Agreed -- AppArmor seems to offer much more granular control over file system access in a way that's quite a bit easier to configure. ProtectSystem is great, but the bits that list specific files or paths are somewhat harder to use and less useful. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/>