Re: [systemd-devel] containers again
On Tue, Sep 08, 2015 at 04:14:58PM +0200, Michał Zegan wrote: > Hello. > > Before you stated that containers are not a security feature right > now. It is required to manually shift uids/gids on images etc. Yes. Also, if you uid-shift the container's root directory, using `--private-users` without specifying a uid-shift works by inspecting the uid-shift of the file-system, assuming that each container is allocated the lower 16-bits of the UID field, and the upper 16-bits being a container ID. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] containers again
Hello. Before you stated that containers are not a security feature right now. It is required to manually shift uids/gids on images etc. What are other known problems with containers that use ALL namespaces? Like if not counting the problem of uid allocation and manual shifting of them. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] containers
On Sun, Sep 6, 2015 at 6:00 PM, Lennart Poettering wrote: > On Sun, 06.09.15 17:49, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > >> Hello. >> >> Is systemd-nspawn intended to eventually become usable for full system >> containers/general use with enough security to run things like vps hosting? >> How much is missing to be able to do that, or maybe it already can? Like you >> have user namespaces support that probably adds more security in addition to >> other namespaces, not sure though. > > Well, Linux containers are currently not a security technology, and > you really shouldn't mistake them for one. > > But yes, we'll close the biggest holes as we can, and the intention is > certainly to make it hard to escape containers. > > nspawn supports user namespaces, but I don't think they are > practically usable, since there's no logic for automatically > allocating user id ranges, and file systems have to be altered to make > them compatible with user namespacing. We'd like to improve the > situation there, but this requires more kernel work. > > The focus with nspawn is indeed on full system containers > (i.e. containers running an init system in them), and explicitly not > so much "micro service" virtualization a la docker. > > To dogfood myself I run my own dedicated server in an nspawn-based > solution, and I am pretty happy with it. Same here with a Fedora 22 server. Lots of web services/web apps runing very fine and quickly. > > Note that nspawn + machined is not supposed to be a complete > deployment solution, it focuses on the execution runtime of the > container locally and it does not and will not do orchestration of > containers across a whole cluster, or update/lifecycle management. Use > rkt (which builds on nspawn) for that. > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] containers
On Sun, 06.09.15 17:49, Michał Zegan (webczat_...@poczta.onet.pl) wrote: > Hello. > > Is systemd-nspawn intended to eventually become usable for full system > containers/general use with enough security to run things like vps hosting? > How much is missing to be able to do that, or maybe it already can? Like you > have user namespaces support that probably adds more security in addition to > other namespaces, not sure though. Well, Linux containers are currently not a security technology, and you really shouldn't mistake them for one. But yes, we'll close the biggest holes as we can, and the intention is certainly to make it hard to escape containers. nspawn supports user namespaces, but I don't think they are practically usable, since there's no logic for automatically allocating user id ranges, and file systems have to be altered to make them compatible with user namespacing. We'd like to improve the situation there, but this requires more kernel work. The focus with nspawn is indeed on full system containers (i.e. containers running an init system in them), and explicitly not so much "micro service" virtualization a la docker. To dogfood myself I run my own dedicated server in an nspawn-based solution, and I am pretty happy with it. Note that nspawn + machined is not supposed to be a complete deployment solution, it focuses on the execution runtime of the container locally and it does not and will not do orchestration of containers across a whole cluster, or update/lifecycle management. Use rkt (which builds on nspawn) for that. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] containers
Hello. Is systemd-nspawn intended to eventually become usable for full system containers/general use with enough security to run things like vps hosting? How much is missing to be able to do that, or maybe it already can? Like you have user namespaces support that probably adds more security in addition to other namespaces, not sure though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
