> 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/