Home / server / Questions / 847156
Accepted
Jonathan S. Fisher
Asked: 2017-04-29 06:05:00 +0800 CST

Is there a way to control filesystem access with systemd?

  • 772

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!

systemd

1 Answers

  1. Best Answer

    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.

    • 6