On Mon, 02.03.15 10:03, Mauricio Tavares (raubvogel@xxxxxxxxx) wrote: > On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > >> We are continuing to work on making running systemd within a container > >> better. > >> I am trying to get a /run on tmpfs patch to be acceptable upstream. But > >> we still > >> have a problem with systemd requiring /sys/fs/cgroup to be mounted > >> inside the container > >> to run. Which allows for an information leak. > > > > You'd have to get the kernel changed for that "information leak" to be > > fixed. > > > > That said, containers on Linux are not really about security, the > > whole thing has more holes than a swiss cheese. Maybe one day the > > security holes can be fixed, but as of now, it's simply not > > secure. And this "information leak" is certainly the least of your > > problems... > > > What would then be the recommended solution if containers are insecure? Well, use containers, but don't have any illusions about them adding much security. You get the usual security guarantess that Unix gives you. not more and not less. But the containers are really not isolated from the host as much as people think. For example, if you use the same user ID in two containers (and that's what Docker more often than not ends up doing), they share the same "struct user" in the kernel, and hence things like RLIMIT_NPROC (which are per-user) will affect not only the originating container, but the host and all other containers on the host too. (This specific issue is easily triggerable btw: just run avahi inside a container and on the host, and you'll have fun. Avahi sets RLIMIT_NPROC to 2, to prohibit forking should it be exploited, but since it requires two processes, and RLIMIT_NPROC is shared between all containers and the host you can hence runonly a single avahi per machine...) And there are many many other issues like this... (the per-user keyring is shared for example, yuck!) Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
