On Thu, Mar 8, 2018 at 4:00 PM, R0b0t1 <r03...@gmail.com> wrote: > On Thu, Mar 8, 2018 at 11:50 AM, Rich Freeman <ri...@gentoo.org> wrote: >> If you have util-linux installed then try running (as any user - you >> don't have to be root): >> unshare -i -m -n -p -u -C -f --mount-proc -U -r /bin/bash >> > > Interesting. I hadn't found a good interface to containers and > clone(2) besides Docker. Of course, I didn't look very hard. I half > expect a "new" process model to develop around the kernel namespaces, > as people realize GID separation only is too coarse.
Well, the original userspace tools are in app-emulation/lxc (I can see how it ended up in this category, but obviously it doesn't fit). Docker is the most popular one. My personal favorite is systemd-nspawn. That basically has almost nothing to do with systemd per-se, but I have no idea if it can work standalone. It is a bit more minimal while still being fairly functional. unshare/nsenter are the util-linux commands that give relatively direct access to the system calls themselves. I used unshare to illustrate that these really are just system calls and how you use them is up to you. > > I still see some odd claims about container security, though: claiming > containers are more secure than user accounts still seems odd to me, > as if you don't trust the kernel to enforce user accounts, why trust > it to enforce namespace separation? > I'm not sure I'd say that containers are more than user accounts per-se, though with UID mapping it could be easier to avoid sharing user/group IDs across different services that might otherwise share them. I'd say that the security of a container is a bit like the security of running something in a chroot jail. It is one additional level of isolation that something needs to break out of. Processes running as root inside a container (and I mean the real root, not root in a user namespace like in my example - unless you ran the command I gave while logged in as root) are not secure today as far as I'm aware. Sure, the isolation is such that a process isn't going to accidentally escape from the container, so that is a form of security. However, a malicious process running as root inside a container (or a chroot) is generally going to be able to escape if it wants to. Maybe some kernel hardening approaches would help with that. Also, a process running in a container has less info on the host, especially if in a chroot (which is typically the case). If you run a shell as nobody you could probably glean quite a bit about what is going on with the host, even if you can't directly touch most of it. If you could run a process as nobody on many hosts maybe you could identify which hosts you want to prioritize for further attacks. If they're doing the same thing on processes trapped in a container+chroot then they're basically not going to know about any other services on the host other than the one they've already hacked into. Stuff running as non-root inside a container should be very well contained, barring kernel bugs. As we saw a few months ago with meltdown even running in a VM isn't a perfect guarantee of isolation. But, I would agree that stuff running under a different UID is also reasonably secure other than information leaks. The main benefit of containers is isolation, IMO. Stuff inside a container just doesn't see anything outside, which means fewer incompatibilities. I run a bunch of nspawn containers mostly running Gentoo (some with other distros inside), and the nice thing about it is that when I update a container I know it only provides one service, so I only have one service I need to test, vs doing a glibc update and having to test everything. On the other hand it is that many more updates to do, and there is a bit more memory cost since libraries aren't shared across them the way they would be if they all ran on the host. -- Rich
