On Linux Xen performance is really good.
I am used to setup and configure jails from the host system while I can seamlessly write to the ZFS because it is under /zpool/jails/<myjail>/<timestamp> So an upgrade is simply a stop of the jail with the old <timestamp> directory and start the new one. A /var/db/mysql gets "transferred" by changing the mountpoint. The filesystem is shared, no voodoo to increase a disk image needed. (I can use quota if there is a need) The same goes for the memory, no pre-allocation and slicing needed (resource management via rctl possible if needed). I safe diskspace because the jail filesystems are simply cloned from a template (only deltas of the filesystems per jail are written) An exact copy of the jail can be mirrored quickly on another box via zfs snapshot, zfs send | ssh zfs receive. To bring it up is a oneliner (more automagic with CARP or VRRP and heartbeats if you want) The kernel cannot be patched dynamically, that's true. But with 2 or 3 kernel security issues per year it is a bit less of a worry for many environments. 30 minutes downtime per year isn't too bad, and it's realistic without high-availability added yet. It's more than 99.99% availability. I am using VMware ESXi and CentOS7 now. It's a huge step backwards. Regards Peter On Fri, Aug 14, 2015 at 8:16 PM, Russell Coker <russell@coker.com.au> wrote:
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/