Hacker News Reader

Comment by freedomben | Hacker News Reader

> You should not assume any significant security benefits to containers, regardless of what anyone claims (even a kernel developer - maybe especially them....) because it all depends on Linux kernel security, which is pretty crap.

Completely disagree. How much experience/exposure do you have to kernel security that you say is crap?

> It uses Micro VMs rather than just kernel-level restrictions, so even a Linux kernel security bug shouldn't be able to jump out to the host or other containers/Firecrackers.

You realize that firecracker uses KVM, which is part of the "crap" kernel that you don't trust? A "Linux kernel security bug" could absolutely allow a Firecracker VM to jump to the host or other containers/Firecrackers.

View on HN

The attack surface of a micro VM is tiny compared with that of a full Linux kernel. That's the issue.

I don't disagree with you, but that's a very different thing than what GP said. Comparing attack surface is a very different thing than saying that containers don't give you any practical security over a non-containerized process (my paraphrase of OP, subject to misinterpretation). The former (comparing attack surface) is a useful exercise in a high-security environment. The latter is simply a ridiculous thing to say.

Trying to secure a container via non-VM means is a painful slog. You can pretend containers give you security, and then one of the hundreds of different attack vectors provides a breakout. It's been demonstrated time and again, largely because Linux security is just shit and always has been.

I did it this morning and it wasn't a painful slog, because I don't have to start from scratch with just docker every time. I can reuse work done by others, and there are numerous tools that assist (OpenShift, selinux, seccomp for example). Your example of firecracker is the same thing. It is a tool wrapped around a lower-level implementation (KVM) that covers the primitives so they are easier/faster to use.

If your complaint is that container implementations leave the hardening scope to other tools, then sure, but I would argue that's just philosophy difference between the unix approach of do one thing and do it well, and chain tools together to solve problems, and the approach of one program to rule them all.

It's not a philosophical difference, it's just complexity. More complex systems are more prone to failure. If the security system is more complex to set up, it's more likely to fail. More code means more bugs, and more domain-specific knowledge leads to more potential for user error. So if you have 'one program to secure it all', it's almost guaranteed to be better than having to use many programs all in the right way. And it isn't even a defense-in-depth issue because all those layers added to container security are really just to avoid the much larger attack surface; getting rid of attack surfaces reduces what you need to defend.

I don't think there's ever been a year without a half dozen privesc holes in the Linux kernel. Linus is also belligerently anti-security because he thinks it always results in worse user outcomes. And containers were never created with security as a top priority, they're just an amalgamation of resource abstractions, so of course it works as well as anything else not designed with security in mind.

The hypervisor isolates guest kernel bugs from the host by nature of strictly controlling resource use from the lowest level. There are of course hypervisor bugs that allow breakouts, but they are a couple orders of magnitude rarer than the typical Linux privesc bug.

Reply on news.ycombinator.com