On Fri, 14 Aug 2015 04:18:28 PM Peter Ross wrote:
There are 2 things:
1. To add more functionality in the same tool increases complexity.
Complexity never increases security.
That depends on what you do and how you do it. If you add some complexity to one central place and remove it from many other places that's often an overall benefit.
Do everything once, do not make it more complex as needed, and do it right.
Which is the benefit of replacing /etc/init.d/ script functionality with code in systemd.
2. Linux has cgroups and namespaces but some Linux design decisions are in the way of using them as _secure_ containers.
Greater use of cgroups and namespaces by systemd should be an incentive for development of better kernel support.
FreeBSD jail(8) is in use for many years and can be considered as safe. The pitfalls are known, disabled in the default setup, well documented, and there are no 'hopefully safe"s in it.
I agree that having functionality like jail in the Linux kernel would be a good thing. This is not related to systemd though.
"Which is still a minor issue compared to web browsers, MUAs..'
They do not run on my servers, and they should not be an excuse to run other software which is overly complex because Russell considers it as a "lesser evil";-)
Systemd is optional and as Rick has demonstrated any sysadmin who doesn't want it on Debian can remove it with ease. It's less optional on GNOME and most desktop sysadmins won't even try removing it if they run KDE. So I think that these supposed security risks should be considered in the context of desktop users.
To go to your own stuff, e.g. SELinux:
A jail script can be subject to SELinux policies so jails can be restricted that way. This would apply to all jails, and nothing else.
That's usually not what you want. You probably want to have multiple jails with different security contexts.
If this is part of a larger binary which does all of init: SELinux cannot be applied in a similar way.
Sure it can. The init system could request different contexts for each of the jails (this can be added to systemd unit files if it isn't already there) or the executables to run in the jails could have different contexts. I wrote policy for multiple chroot environments many years ago but it got deleted in the change to the modular "reference" policy. But it would be possible to do that again if there was demand. On Linux Xen performance is really good. The only situation where something like Docker would be a good idea is if you have ZFS storing all the data and don't want to be hobbled by poor NFS performance to the virtual machine. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/