[systemd-devel] systemd-nspawn containers

[Michał Zegan]

Thank you for your answers!

What I meant by secure containers is mostly, containers that are or will
be secure enough to use them for things like virtual private server
hosting. Is nspawn intended to be usable for such things in the future,
or maybe it already is, or whatever?
What kernel limitations do you mean when you say about security?
For now I know that in full containers with userns file capabilities do
not work (I think), you have no virtualized /proc/meminfo and friends
(do cgroup namespaces give a chance to change that?), you cannot mknod
devices (no whitelist possible at this level), no fuse support, no
automatic uid shifting kernel level, no possibility to mount physical
filesystems in userns, and no possibility to have selinux/etc per
container. Do you mean such limitations or something else? I am
interested in this topic but it is quite hard for me to track progress
in that area (kernel side) even though I subscribe in some kernel ml's
and know at least about submitted patches, or some of them. What else is
missing that I didn't say about that would be good to have?

Also what about setting cgroup parameters per container? nspawn does not
allow doing that, and you probably do not intent it to be done by
overriding container's scope unit settings, for example?

W dniu 11.11.2016 o 13:52, Lennart Poettering pisze:
> On Wed, 09.11.16 18:24, Michał Zegan (webczat_200 at poczta.onet.pl) wrote:
> 
>> Hello.
>>
>> Does systemd-nspawn intent to be a full secure container technology? or
>> it maybe already is? what is missing?
> 
> I am not sure what "full secure container technology" realls is
> supposed to mean.
> 
> nspawn right now is great for two things:
> 
> a) full OS containers (think VMs, except based on container
>    technology. This means that inside the container you have a proper
>    PID 1 running, and a network configuration daemon and most other
>    things that would run on a normal, physical system, except one
>    thing: no device manager, as the kernel does not virtualize
>    devices)
> 
> b) as a building block for whatever you want it to be. It's a pretty
>    generic tool, you can use as base for anything you like. The "rkt"
>    container manager makes use of this facet.
> 
> There are a number of things nspawn is better at than other container
> managers, for example in conjunction with networkd networking happens
> pretty much entirely automatically out of the box. It also ships
> userns support that is relatively usable without much manual
> intervention. OTOH it clearly doesn't do a lot of stuff that other
> container managers do and we have no intention to ever do: do IP level
> configuration in the manager itself, support for ZFS and other exotic
> (possibly out-of-tree) storage technology, and so on.
> 
> So it really depends what you mean by "full secure container
> technology". We do a lot, we will add more, but there are also things
> I don't see on our list at all.
> 
> (And "secure" is a difficult thing anyway, currently security of
> containers on Linux is pretty limited in general, due to kernel
> limitations.)
> 
> Lennart
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 492 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20161111/4b968083/attachment.sig>