Is there a way to control filesystem access with systemd?
So I'm diving into the intricacies of systemd and it's ability to meter resources with cgroups like cpu, io, and memory.
Is there also a way to control the directories a process has access to with systemd? For instance, /usr/bin
is generally marked o+rX
, and I'd like a webserver process to be locked out of that directory. There have been quite a few software exploits where you can read arbitrary files from disk, this would enhance a layered approach to security.
I'm sure this could be done with some really fancy filesystem permissions, but was wondering if there was a better way. Thank server fault!
You have a number of options actually, which you can define in the unit file(s) for your services. They all work on the same principle, by using bind mounts within the namespace systemd sets up for the service. Certain parts of the file-system are either mounted read-only, or rendered completely invisible/inaccessible by mounting an empty directory.
PrivateTmp
is arguably the most common.
Enabling PrivateTmp
sets up a new file system namespace for the executed processes and mounts private /tmp
and /var/tmp
directories inside it that is not shared by processes outside of the namespace.
ProtectSystem
If true
, mounts the /usr
and /boot
directories read-only for processes invoked by this unit.
If set to full
, the /etc
directory is mounted read-only, too. If set to "strict" the entire file system hierarchy is mounted read-only, except for the API file system subtrees /dev, /proc and /sys
ProtectHome
Takes a boolean argument or "read-only". If true
, the directories /home
, /root
and /run/user
are made inaccessible and empty for processes invoked by this unit. If set to "read-only
", the three directories are made read-only instead
ProtectKernelTunables
If true, kernel variables accessible through /proc/sys
, /sys
, /proc/sysrq-trigger
, /proc/latency_stats
, /proc/acpi
, /proc/timer_stats
, /proc/fs
and /proc/irq
will be made read-only.
ReadOnlyPaths
Paths listed in ReadOnlyPaths=
are accessible for reading only, writing will be refused even if the usual file access controls would permit this.
InaccessiblePaths
Paths listed in InaccessiblePaths=
will be made inaccessible for processes inside the namespace (along with everything below them in the file system hierarchy).
There might be more options though.
A more layered access policy would probably require SELinux, and a very thorough understanding of it as well as you probably need to adept the Multi Level Security policies.