Even when I can’t always agree with systemd (such a very diplomatic statement for “fsck lennart”), these sandboxing features are one of a very few unique arguments speaking for systemd. If you try to do that with runit or bsd init, you’ll more or less invent the systemd on your own (something something every advanced C program is a tangled Lisp processor).
Or, you’ll fall into kernelspace MAC like SELinux. Good luck writing rules for it - trust me, many brave souls tried that path :)
Or, you’ll fall into kernelspace MAC like SELinux. Good luck writing rules for it - trust me, many brave souls tried that path :)
This comment just made me really miss Grsecurity’s MAC/RBAC system and it’s learning mode, it was very easy to just let a service run for a few days while triggering some corner cases on purpose and then just flick a switch from learning to a generated model. After messing with SELinux for so long and also with some of these other jailing systems I really do think the kernelspace MAC is an okay place for it, it’s just a matter of atrocious UX that is clearly written for a military usecase.
That being said I’m glad this exists and it really is a positive for systemd.
What annoys me most is that grsec isn’t dead and it didn’t vanished instantly. It’s still here, but we can’t use it unless we sign some agreement and pay serious dollars for it. And that violates GPL in some way I think, as it’s just the patchset for mainline kernel.
And yes, I really loved R(S)BAC for its simplicity and “getting things done”. And if someone gets it back I’ll kill all SELinuxes in my managed hosts with ultimate pleasure.
And do note that the exposure rating systemd-analyze security is a bit strange. For example PrivateNetwork= is rated as 0.5 points but NetworkManager relies on network to be available.
But there is certainly a lot to improve and some upstreams happily merge system hardening patches!
They are really underrated. I often configure them for services packaged for Debian. Most upstream developers are unaware of those or even unaware of sandboxing in general.
There are a lot more than the ones mentioned in the article. It’s meant as an introduction to make more people aware that these exist. Check the systemd.exec man page for more directives.
Wow, I didn’t know about systemd-analyze. That’s super useful!
For my custom apps, I’ve been using the ‘strict’ profile from portablectl as a reference. The downside of portablectl itself, I think, is you get the same duplication of dependencies as Docker containers. I’m more comfortable without chroot / RootImage / RootDirectory (which is not in that profile, but portablectl adds), so I can rely on unattended upgrades. It looks like all my services setup this way get a 1.3 exposure score from systemd-analyze; pretty good!
With the way the security settings work, I guess systemd is striking middle ground somewhere to support existing Unixy services, but I wish it was the other way around: start from zero, then open up the sandbox as needed. Figuring out all the different settings and how they affect your app can be a lot of work.
Having a generic way to restrict permissions to arbitrary programs is good ! Some sort of “drop ability to do X upon execution”. That is a nice taste of security as opposed to virtual machines, that does not help with security by adding more attack surface (through more complexity, yet can have an use case).
A numeric indicator, eww please no!
The exposure score is entirely based on a service’s utilization of security features provided by systemd.
It is showing a single indicator with “UNSAFE, EXPOSED, MEDIUM, OK” written on the side.
How safe is a service that run no code as root and use none of these very-linux-specific features and another one that build a string and pass it to system(3) as root and make use of most systemd sandboxing features?
Instead, show a table of all kind of restrictions (as column names) for all process (as row names).
Exaggerating to make it obvious: “My company is at 4.2/5 considering network lattency and bandwidth, security, economical wealthiness, employment diversity, disk throughput, security, CPU load average”.
P.S.: thanks to the blogger for showing these to us.
Even when I can’t always agree with systemd (such a very diplomatic statement for “fsck lennart”), these sandboxing features are one of a very few unique arguments speaking for systemd. If you try to do that with runit or bsd init, you’ll more or less invent the systemd on your own (something something every advanced C program is a tangled Lisp processor).
Or, you’ll fall into kernelspace MAC like SELinux. Good luck writing rules for it - trust me, many brave souls tried that path :)
This comment just made me really miss Grsecurity’s MAC/RBAC system and it’s learning mode, it was very easy to just let a service run for a few days while triggering some corner cases on purpose and then just flick a switch from learning to a generated model. After messing with SELinux for so long and also with some of these other jailing systems I really do think the kernelspace MAC is an okay place for it, it’s just a matter of atrocious UX that is clearly written for a military usecase.
That being said I’m glad this exists and it really is a positive for systemd.
What annoys me most is that grsec isn’t dead and it didn’t vanished instantly. It’s still here, but we can’t use it unless we sign some agreement and pay serious dollars for it. And that violates GPL in some way I think, as it’s just the patchset for mainline kernel.
And yes, I really loved R(S)BAC for its simplicity and “getting things done”. And if someone gets it back I’ll kill all SELinuxes in my managed hosts with ultimate pleasure.
For the systemd units we ship ourself or use in production for Arch Linux, I’ve made this WIP page describing a more variety of hardening measures.
https://wiki.archlinux.org/index.php/Security_package_guidelines#Systemd_services
I wish more arch packages would use these.
Most of them come from upstream it seems although a valid one is the shadow service https://git.archlinux.org/svntogit/packages.git/tree/trunk/shadow.service?h=packages/shadow
And do note that the exposure rating systemd-analyze security is a bit strange. For example PrivateNetwork= is rated as 0.5 points but NetworkManager relies on network to be available.
But there is certainly a lot to improve and some upstreams happily merge system hardening patches!
Thanks for sharing. I had no idea these directives existed.
They are really underrated. I often configure them for services packaged for Debian. Most upstream developers are unaware of those or even unaware of sandboxing in general.
There are a lot more than the ones mentioned in the article. It’s meant as an introduction to make more people aware that these exist. Check the systemd.exec man page for more directives.
Many thanks!
Wow, I didn’t know about systemd-analyze. That’s super useful!
For my custom apps, I’ve been using the ‘strict’ profile from portablectl as a reference. The downside of portablectl itself, I think, is you get the same duplication of dependencies as Docker containers. I’m more comfortable without chroot / RootImage / RootDirectory (which is not in that profile, but portablectl adds), so I can rely on unattended upgrades. It looks like all my services setup this way get a 1.3 exposure score from systemd-analyze; pretty good!
With the way the security settings work, I guess systemd is striking middle ground somewhere to support existing Unixy services, but I wish it was the other way around: start from zero, then open up the sandbox as needed. Figuring out all the different settings and how they affect your app can be a lot of work.
Having a generic way to restrict permissions to arbitrary programs is good ! Some sort of “drop ability to do X upon execution”. That is a nice taste of security as opposed to virtual machines, that does not help with security by adding more attack surface (through more complexity, yet can have an use case).
A numeric indicator, eww please no!How safe is a service that run no code as root and use none of these very-linux-specific features and another one that build a string and pass it to system(3) as root and make use of most systemd sandboxing features?
Instead, show a table of all kind of restrictions (as column names) for all process (as row names).
Exaggerating to make it obvious: “My company is at 4.2/5 considering network lattency and bandwidth, security, economical wealthiness, employment diversity, disk throughput, security, CPU load average”.
P.S.: thanks to the blogger for showing these to us.