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

Projects
None yet
3 participants
@rgacogne
Copy link
Member

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member

pieterlexis commented Nov 9, 2018

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

@rgacogne

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
Member Author

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

This comment has been minimized.

Copy link
@pieterlexis

pieterlexis Jan 14, 2019

Member

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

This comment has been minimized.

Copy link
@rgacogne

rgacogne Jan 22, 2019

Author Member

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

This comment has been minimized.

Copy link
Member Author

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 rgacogne:more-systemd-sandboxing branch from 442fe40 to 75e04c7 Jan 14, 2019

@rgacogne

This comment has been minimized.

Copy link
Member Author

rgacogne commented Jan 14, 2019

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

rgacogne added some commits May 21, 2018

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

@rgacogne

This comment has been minimized.

Copy link
Member Author

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

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@rgacogne rgacogne deleted the rgacogne: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
You can’t perform that action at this time.