Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More sandboxing using systemd's features #6634

Merged
merged 3 commits into from Jan 22, 2019

Conversation

@rgacogne
Copy link
Member

@rgacogne rgacogne commented May 21, 2018

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:

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
Copy link
Member

@Habbie Habbie commented May 21, 2018

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.

@Habbie Habbie changed the title Mode sandboxing using systemd's features More sandboxing using systemd's features May 21, 2018
@rgacogne
Copy link
Member Author

@rgacogne rgacogne commented May 22, 2018

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.

@rgacogne rgacogne changed the title More sandboxing using systemd's features [WIP] More sandboxing using systemd's features May 22, 2018
@pieterlexis
Copy link
Member

@pieterlexis pieterlexis commented Nov 9, 2018

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

@rgacogne
Copy link
Member Author

@rgacogne rgacogne commented Jan 11, 2019

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 rgacogne changed the title [WIP] More sandboxing using systemd's features More sandboxing using systemd's features Jan 14, 2019
@rgacogne
Copy link
Member Author

@rgacogne rgacogne commented Jan 14, 2019

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

@@ -128,3 +128,66 @@ AC_DEFUN([AX_AVAILABLE_SYSTEMD], [
AX_CHECK_SYSTEMD_DETECT_AND_ENABLE()
AX_CHECK_SYSTEMD()
])

AC_DEFUN([AX_CHECK_SYSTEMD_FEATURES], [
if test x"$systemd" = "xy"; then
Copy link
Member

@pieterlexis pieterlexis Jan 14, 2019

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).

Copy link
Member Author

@rgacogne rgacogne Jan 22, 2019

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
Copy link
Member Author

@rgacogne rgacogne commented Jan 14, 2019

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 rgacogne force-pushed the more-systemd-sandboxing branch from 442fe40 to 75e04c7 Jan 14, 2019
@rgacogne
Copy link
Member Author

@rgacogne rgacogne commented Jan 14, 2019

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

@rgacogne rgacogne force-pushed the more-systemd-sandboxing branch from 75e04c7 to 6db97da Jan 14, 2019
@rgacogne
Copy link
Member Author

@rgacogne rgacogne commented Jan 14, 2019

And a new rebase + commit for the spell checker.

@rgacogne rgacogne added this to the rec-4.2.0-alpha1 milestone Jan 18, 2019
@rgacogne rgacogne merged commit 8f59236 into PowerDNS:master Jan 22, 2019
1 check passed
@rgacogne rgacogne deleted the more-systemd-sandboxing branch Jan 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants