On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosowski(a)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
--
Lennart Poettering, Red Hat