More sandboxing using systemd's features

[rgacogne]

Short description

Recent versions of systemd feature many new sandboxing options, and enabling them would make the exploitation of an issue in one of our daemons harder by reducing the attack surface:

• LockPersonality: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LockPersonality=
• ProtectControlGroups: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectControlGroups=
• ProtectKernelModules: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelModules=
• ProtectKernelTunables: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectKernelTunables=
• RestrictNamespaces: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RestrictNamespaces=
• RestrictRealtime: https://www.freedesktop.org/software/systemd/man/systemd.exec.html#RestrictRealtime=

Possible drawbacks:

• Some users might need to disable them, because they are doing unexpected things with, for example, devices via Lua
• Older versions of systemd will log warning messages stating they have no clue about these options, but will start all the same:

Unknown lvalue 'LockPersonality' in section 'Service'
Unknown lvalue 'ProtectControlGroups' in section 'Service'
Unknown lvalue 'ProtectKernelModules' in section 'Service'
Unknown lvalue 'ProtectKernelTunables' in section 'Service'
Unknown lvalue 'RestrictNamespaces' in section 'Service'
Unknown lvalue 'RestrictRealtime' in section 'Service'

Checklist

I have:

• read the CONTRIBUTING.md document
• compiled this code
• tested this code
• included documentation (including possible behaviour changes)
• documented the code
• added or modified regression test(s)
• added or modified unit test(s)

[Habbie]

Older versions of systemd will log warning messages stating they have no clue about these options, but will start all the same:

I bet we can handle that during packaging.

[rgacogne]

I bet we can handle that during packaging.

Quite likely, yes. I can't find the versions in which systemd introduced each of these features so it might be a bit painful to track them. I'll give it a try later.

[pieterlexis]

We should perhaps check this with the result from systemd/systemd#10701 😃

[rgacogne]

Out of curiosity, results of running systemd-analyze security pdns-recursor on Arch:

• without this PR applied: → Overall exposure level for pdns-recursor.service: 5.7 MEDIUM 😐
• with this PR applied: → Overall exposure level for pdns-recursor.service: 4.2 OK 🙂
• with this PR + the two additional restrictions listed below: → Overall exposure level for pdns-recursor.service: 3.3 OK 🙂 (making it one of the lowest exposure score on my system)

Additional restrictions:

1. SystemCallArchitectures=native
2. SystemCallFilter=~ @clock @debug @module @mount @raw-io @reboot @swap @cpu-emulation @obsolete

[rgacogne]

Pushed a commit detecting the systemd version during configure, and enabling only the available sandboxing features.

[pieterlexis]

perhaps we should AC_MSG_ERR if this macro is called when systemd is not y? This makes it mandatory to call one of the AX_*_SYSTEMD macros beforehand (as we can't use AC_REQUIRE).

[rgacogne]

I'm wondering if we should't move that to a separate m4 file, I have searched a while for something similar, and I believe it might be of use in other projects.

[rgacogne]

Note that I also added a SystemCallFilter and SystemCallArchitectures instructions to blacklist some system calls in that last commit. While this is good from a security PoV, this might have a noticeable performance impact on syscall-heavy loads. Some studies reported a 25% performance hit on one of the worst-case scenario (program looping on getppid(), one of the cheapest syscall). I'm wondering if we are not already paying this cost with existing instructions like RestrictAddressFamilies, though.

[rgacogne]

Rebased on master to make Travis happy (dnspython stuff, AFAICT).

[rgacogne]

And a new rebase + commit for the spell checker.