Re: [gentoo-user] Re: Gentoo is supporting officially Snap packages?

[Rich Freeman]

On Fri, Jun 17, 2016 at 3:16 AM, Andrew Savchenko <bircoph@g.o> wrote:
> On Thu, 16 Jun 2016 22:35:24 -0400 waltdnes@××××××××.org wrote:
>>   I don't follow this stuff, so this may be a stupid question... how
>> does a "container" or "docker" differ from a chroot or a QEMU VM with a
>> minimal set of applications?
>
> Due to reasons above I prefer container solutions like LXC over VM
> for security: they give approximately the same level of protection
> as VM, but resources cost is much lower. Of course it is still
> possible to break any container through L3 cache or some kernel
> bugs, so for really tight security independent hardware and OS must
> be used.

Containers on Linux aren't nearly as secure as a VM right now.
Certainly the intent is for them to get there, and if you find a way
to break out of a container the kernel team would certainly accept it
as a bug and fix it.  However, I don't think most of the big names in
linux would rate it on the same level as a VM.  As you've pointed out,
VMs aren't perfect, though I'm not aware of any way to actually defeat
any of the popular ones (and if there were, they'd almost certainly
patch it).  I'll certainly acknowledge that there is a larger attack
surface than separate hosts (and it isn't like those are invulnerable
either - who knows what bug exists in an ethernet card somewhere).

Containers are a lot more secure than chroots though.  Non-root in a
container is generally considered to be fairly secure - it is an
additional layer on top of normal user privilege isolation.
Containers are generally a lot more convenient than chroots as well,
simply because there are fewer compatibility issues and constraints
inside.  If you want to run sysvinit/openrc or systemd inside your
container you can, and that isn't really possible inside a chroot.  Of
course, you don't have to, but at least you have the option.

The biggest selling point for a container is the resource
requirements.  The overhead to run a container with systemd inside is
only a few MB.  If you're running a container without a service
manager the overhead is even less.  You could never run a VM with only
a few MB of RAM.  The main constraint on RAM use for a container is
the fact that you're not sharing libraries with the host.  Otherwise
they're just processes with different namespace values in the kernel
(EVERY process runs in a set of namespaces, even if you're not using
containers - by default they just all have the same set of values).
Any solution that bundles the libraries with the package is going to
use a similar amount of RAM.  Also, launching a process in a new
namespace takes the same amount of time as launching a process in the
same namespace, minus the trivial time required to page in libraries
and such.  A VM takes seconds to boot, vs the milliseconds for a
container.  In terms of overhead containers and chroots are almost
identical.

The biggest selling point for not just running everything on the host
is isolation.  I have a container that just runs mariadb.  When I do
an emerge -u world it is like updating any other Gentoo host, but when
I'm done I fire off a bunch of tests to make sure mariadb is working,
and if it works I know I'm done.  When I was running everything on a
single host I'd inevitably do an emerge -u world and occasionally have
something random break.  Short of testing everything every time I do
an update it is hard to avoid that sort of thing.  Of course, I end up
having to run a lot more updates, but I don't have to do them all at
once and I can update the container for each service on an appropriate
schedule.

-- 
Rich