New Linux vulnerability affecting cgroups: can containers escape?

Post by staticassertion » Fri, Mar 04, 2022, 9:29 PM UTC

tptacek wrote: post #50

staticassertion wrote: post #32

Earlier quoted context omitted.

It's not a binary thing. I would say something is a boundary if it requires an additional vulnerability to bypass. Containers these days fit that model. The nuance is how strong of a boundary it is. Containers rely on the Linux kernel. The Linux kernel is shit, in terms of security, for a number of reasons. So all one requires is to own the kernel, and there are a lot of ways to do that. Containers block some system…

gvisor doesn't require nested virtualization, right? If you're willing to take a tenable user-mode-Linux performance hit, you should be able to run it on anything?

Post by lenkite » Fri, Mar 04, 2022, 10:00 PM UTC

stormbrew wrote: post #16

xxpor wrote: post #6

Back in the day, people insisted that containers were not security boundaries and should not be treated as such. They're meant to contain things from going off the rails unintentionally, but an actual threat was another story. However, realistically, given the env that a container gives you, it certainly looks and feels like a security boundary. So are we just going to be stuck in this retroactive security cleanup mo…

> My point is that if it were designed from the ground up with the hard security boundary in mind, would we have ended up with containers in the first place? If not, is there any realistic way to go from where we are to where we should be? Yes, because systems that are designed with these kinds of security boundaries in mind already look like containers -- they're a natural match to actual capability-based systems li…

Post by [deleted] » Fri, Mar 04, 2022, 11:00 PM UTC

jsiepkes wrote: post #43

tptacek wrote: post #37

Earlier quoted context omitted.

And Joyent had problems doing that: https://news.ycombinator.com/item?id=27078349 There's nothing you can do to "certify" zones to mitigate this. The problem is that zone cotenants share a kernel. You have to trust that the kernel attack surface is free of LPEs, and no reasonable person can trust that.

I don't see how bugs of zone escapes and such are necessarily proof of the concept not working. Chrome also has had its fair share of sandbox escapes and zero-click remote code execution exploits. Does that mean you can't have a browser? I mean by those standards if even Google can't get it right us "mere mortal developers" might as well quit all together. > The problem is that zone cotenants share a kernel. Even wit…

Post by chunkyks » Fri, Mar 04, 2022, 11:46 PM UTC

chucky_z wrote: post #18

chunkyks wrote: post #14

Earlier quoted context omitted.

Things may have changed, but the last few times I looked, it was breathtakingly hard to a) identify if /when selinux is what's screwing you, then b) get selinux to stop it. I really wanted an audit mode that could also say "this command will unlock the specific thing I just blocked". That was a few years ago. Since then, I've turned off selinux whenever I'm getting screwed by some opaque process, stuff starts working…

Is audit2allow the thing you want?

Post by richardfey » Fri, Mar 04, 2022, 11:50 PM UTC

throwawayboise wrote: post #54

xxpor wrote: post #6

Back in the day, people insisted that containers were not security boundaries and should not be treated as such. They're meant to contain things from going off the rails unintentionally, but an actual threat was another story. However, realistically, given the env that a container gives you, it certainly looks and feels like a security boundary. So are we just going to be stuck in this retroactive security cleanup mo…

I'll quote Theo deRaadt here, he was talking about virtualization but I would guess the same could be said of containers: You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't write operating systems or applications without security holes, can then turn around and suddenly write virtualization layers without security holes