On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosowski@nist.gov) wrote:
On 12/13/2016 02:51 PM, Lennart Poettering wrote:
Yeah, this is really what it boils down to: the goal with the systemd directives is to make things easy to grok and easy to change. I can probably explain to most Linux admins who have administered a current Fedora in 5min what ProtectSystem=strict and ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And
One thing that SELinux does right is auditing---access violations are logged, so that there are no silent mysterious failures (well, mumble, mumble, maybe sometimes, you know what I mean). Also, SELinux allows debugging in the permissive mode that just logs without actually blocking access. What happens after systemd directives result in denials?
There's no auditing hook-up with systemd's sandboxing options.
The precise error your service gets depends on the sandboxing setting: ProtectSystem=strict makes file systems read-only for a service, and hence will result in EROFS if it tries to access something.
The seccomp-based settings by default result in EPERM.
BTW, it's ProtectSystem=true/false/full (not strict), right?
ProtectSystem=strict is a v232 addition (→ rawhide). It's stricter than "full" even...
Lennart