One of the incredible & fantastic superpowers of systemd. There so much isolation it can give you, rescind so many powers!
Alas this article doesn't include even the most rudimentary of examples.
Let's look at recent gnome gdm session picker changes. They now use dynamic users, rather than statically allocated ones, helping make sure the picker never gets access to things it shouldn't have (since there's no static user id that an attacker might grant access to). A nice feature from systemd in 2017. So easy to add! DynamicUser=yes and you're good! https://0pointer.net/blog/dynamic-users-with-systemd.html
This also gives you a bunch of other security options by default.
This is just the tiniest cut of what systemd can do to make your system more secure, how it can help you make use of the kernel to limit your process. There's so so many ways to limit programs. Limit maximum tasks, set Nice= CPUWeight=, IOWeight=, limit CapabilityBoundingSet=, TasksMax=, limit network interfaces, tie a program to certain nftables, just so many. This huge page is but a start: https://www.freedesktop.org/software/systemd/man/latest/syst... !!
Systemd makes excellent excellent use of the kernels namespacing feature to radically boost isolation of programs, to reduce their ability to impact the world in unexpected ways. Even better, you can manage multiple competing realms of apps very very effectively with a hierarchy of scopes, limiting not just program by program but putting programming into nested scopes & limiting scopes, which can insure that system critical services can remain running and adequately provisioned, even while other bulk processes might otherwise demolish the system.
It's been possible to write amazing smart daemons that do all this stuff. But shifting this up to systemd, making it a system responsibility rather than service by service reimplementing has radically enhanced the accessibility of these amazing security & provisioning capabilities built in to the kernel, and given us a shared practice & understanding. Would love to see more articles on this topic! Especially ones that cover what settings folks reach for, which this article alas failed to do at all.
Sorry that this blog post fell short... I never expected anyone would post it here anyways. I will keep this feedback in mind going forward. I tend to blog for myself.
Edit: also, unsure why the OP used a `us.` subdomain instead of `blog.` where my blog is actually hosted. I am surprised `us.` even works.
4 comments
[ 2.0 ms ] story [ 24.3 ms ] threadI know the post linked to systemd docs, but I’d enjoy seeing some snippets of directives people are using to achieve this kind of hardening.
Alas this article doesn't include even the most rudimentary of examples.
Let's look at recent gnome gdm session picker changes. They now use dynamic users, rather than statically allocated ones, helping make sure the picker never gets access to things it shouldn't have (since there's no static user id that an attacker might grant access to). A nice feature from systemd in 2017. So easy to add! DynamicUser=yes and you're good! https://0pointer.net/blog/dynamic-users-with-systemd.html
This also gives you a bunch of other security options by default.
PrviateTmp=yes. ProtectHome=readonly. ProtectSystem=strict.
This is just the tiniest cut of what systemd can do to make your system more secure, how it can help you make use of the kernel to limit your process. There's so so many ways to limit programs. Limit maximum tasks, set Nice= CPUWeight=, IOWeight=, limit CapabilityBoundingSet=, TasksMax=, limit network interfaces, tie a program to certain nftables, just so many. This huge page is but a start: https://www.freedesktop.org/software/systemd/man/latest/syst... !!
Systemd makes excellent excellent use of the kernels namespacing feature to radically boost isolation of programs, to reduce their ability to impact the world in unexpected ways. Even better, you can manage multiple competing realms of apps very very effectively with a hierarchy of scopes, limiting not just program by program but putting programming into nested scopes & limiting scopes, which can insure that system critical services can remain running and adequately provisioned, even while other bulk processes might otherwise demolish the system.
It's been possible to write amazing smart daemons that do all this stuff. But shifting this up to systemd, making it a system responsibility rather than service by service reimplementing has radically enhanced the accessibility of these amazing security & provisioning capabilities built in to the kernel, and given us a shared practice & understanding. Would love to see more articles on this topic! Especially ones that cover what settings folks reach for, which this article alas failed to do at all.
Edit: also, unsure why the OP used a `us.` subdomain instead of `blog.` where my blog is actually hosted. I am surprised `us.` even works.