On Sunday, 30 August 2020 11:13:55 PM AEST Craig Sanders via luv-main wrote:
What I like are the better security features. One example is terminal control. If you have an init script that launches a daemon under a different UID then if that daemon isn't started by runuser or something similar then the daemon can push characters into the keyboard buffer of the shell.
and if you're running a daemon or something that does that, then you've got greater problems to worry about - anything that could install a compromised daemon already has root access and doesn't need access to your keyboard buffer.
If you have a daemon that is written and maintained by honourable people who have made a mistake in their coding (which happens to all programmers) then a compromised instance of the daemon could spawn a child process that waits for the sysadmin to restart the daemon and then escalates that to root compromise.
i'm not saying that this kind of separation is worthless, just that it's not enough by itself.
It's often not enough to be worth worrying about for one daemon when your whole system is like that. But having it work correctly for the entire system is nice.
To start with, don't install packages from untrusted repositories and NEVER use brawndo-installer, which is a favourite of idiot devs (usually python or ruby or nodejs devs, but not exclusively) and looks something like this:
curl URL | sudo bash
If you trust someone who's written the daemon then trusting their install script is no more risk.
Now you can modify all scripts to use runuser, but that's going to be a pain. systemd does all this for you.
which is nice if you never need to do anything in a way that the systemd devs didn't think or use themselves. or deliberately disallow. in that situation, you're fucked.
Which situations are you thinking of? The "kill processes in user session when they logout" was a good feature for some use cases and it was annoying that last time I checked the Debian systemd maintainers had disabled it instead of leaving it as a configuration option.
Also systemd allows blocking daemons from accessing /home and other security features.
no, the kernel does that. systemd just makes use of kernel namespace features. it's not alone in being able to do that - containerd and docker and firejail and many other programs make use of namespaces.
Yes, but systemd has a configuration option for it.
When it does those sorts of things they are in a standard format so you can grep service files to make sure that all daemons meet the security goals that you have instead of having to read lots of shell scripts written by different people for such things.
I really don't get why systemd fans are so terrified of shell scripts.
Because I've worked on so many shell scripts written by other people.
especially when systemd is so poorly documented. it's not as if systemd unit files are paragons of clarity, or that there's any easy way to get an overview of the dependency relationship between units.
"systemd-analyze critical-chain" is very handy. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/