Hacker News Reader

Comment by viraptor | Hacker News Reader

No. No, no, no. Virtual machines - yes, to an extent. Containers - no.

Containers still use the same kernel, have access to the same filesystems (in practice), same devices, same ioctls, etc. There can be a lot more separation done in the future, but right now, you definitely gain a lot by isolating your containers using selinux.

Even with virtual machines, you want any breakout / external write vulnerability to be contained. That's why libvirt/kvm relies on selinux (or apparmor) for system protection and for cross-vm protection (https://libvirt.org/drvqemu.html#securityselinux)

View on HN

I felt the same way about Docker containers. Now I work for a company that uses Docker containers in production.

The fact that the process, by default, runs as root and PID 1 within the docker container still has be going "You gotta be fucking kidding me?!"

I realize Docker has come a long way since the days of it being LXC based. Cgroups and several other safeguards have done a lot of docker security, and containers are much more lightweight than full VMs, but I'm still a little on edge about the security aspect.

Perhaps I'm misunderstanding the second line of your post, so I apologize if that's the case, but the whole idea of the PID namespace is so that the container's init can run as pid 1 in the container without access to the rest of the host's processes. Likewise for root and user namespaces. (Though I understand that one is really tricky to get right)

Since Docker 1.10, you can specify --userns-remap=default on the daemon and root inside the container will not be root outside: https://docs.docker.com/engine/reference/commandline/daemon/...

I have the impression that regrettably many docker users expect things to be the other way around: that the actual default docker behaviour resides behind a --ridiculously-insecure, not that you need to specify --i-actually-want-my-container-to-try-to-contain to get that expected behaviour.

Hopefully more people are becoming aware of the actual default behaviour.

I realize the system is not perfect, but it's so much better than nothing, and significantly easier to use than virtualmachines/selinux.

It's naive to dismiss something because it doesn't meet the goal of "100%" secure. In practice it gets you very close and takes almost no effort, no maintenance, no headache. Historically that kind of thing will win in the long run.

I'm not arguing that VMs are not an improvement in many areas. They are a MASSIVE improvement and I'd love the unikernel apps to become more popular and push it even further. QubesOS also shows the power of safe virtualisation.

But it doesn't mean "SELinux is not worth saving". Some kind of LSM (selinux/apparmor) is still a great safety net and protects us from an issue that VMs actually introduce. Once you break out of your VM, you have access not to a single host, but to a number of them in a way that no in-VM protection can stop or even detect. That's the reason we really need LSM protection. Not necessarily selinux, but something needs to be there.

Reply on news.ycombinator.com