Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Linux vulnerability affecting cgroups: can containers escape?

unit42.paloaltonetworks.com

Post reply on HN
Print view View original

11–20 of 86 posts

Re: New Linux vulnerability affecting cgroups: can containers escape?

#11

Post by jeffbee »

jackpirate wrote: post #10
jeffbee wrote: post #9

This style of writing sucks, and the abuse of the meaningless term "container" does nothing to clear it up. To reduce this CVE to one sentence: a process running in the top level control group, which has the ability to create user namespace, can take over the machine, because the kernel fails to check for CAP_SYS_ADMIN. See how easy that was?

Isn't the whole purpose of this style of writing to define terms like "top level control group" and "CAP_SYS_ADMIN" for those people who don't already understand what they mean?

The article doesn't do that. It throws around jargon without defining it, or defining it vaguely or inaccurately.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#12

Post by frabbit »

AaronFriel wrote: post #8
concerned_user wrote: post #4

Earlier quoted context omitted.

Sadly, many answers to questions related to selinux issues, or howto's start with: Disable selinux.

I strongly believe that software that works for users is better than software that doesn't, and it's clear that for most lay folks, SELinux is software that doesn't work. SELinux remains inscrutable and unusuable to the lay person. Microsoft had the same problem with Windows XP and especially after its service pack 2 when the Windows Firewall was introduced, that it was difficult to debug and applications didn't prom…

> it's clear that for most lay folks, SELinux is software that doesn't work.

I have always used selinux enabled systems. For the first few years it was a bit confusing and frustrating at times, but for the last (decade?) I have never had to butt heads with it. The default policies shipped by e.g. Fedora (a userland closest to the development of this work and therefore probably better maintained than some others) work out of the box without hassle.

This very article refutes your assertion: here we see SELinux working for ordinary users without any additional fiddling. You, on the other hand, are probably exposed to this privilege escalation.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#13

Post by AaronFriel »

frabbit wrote: post #12
AaronFriel wrote: post #8

Earlier quoted context omitted.

I strongly believe that software that works for users is better than software that doesn't, and it's clear that for most lay folks, SELinux is software that doesn't work. SELinux remains inscrutable and unusuable to the lay person. Microsoft had the same problem with Windows XP and especially after its service pack 2 when the Windows Firewall was introduced, that it was difficult to debug and applications didn't prom…

> it's clear that for most lay folks, SELinux is software that doesn't work. I have always used selinux enabled systems. For the first few years it was a bit confusing and frustrating at times, but for the last (decade?) I have never had to butt heads with it. The default policies shipped by e.g. Fedora (a userland closest to the development of this work and therefore probably better maintained than some others) work…

That's not my assertion, my assertion is that SELinux doesn't work for a lot of people even if it works for you or I; and that's why you see the advice to disable it in forum posts.

To be clear: SELinux is an important mitigation - just like the Windows Firewall - and one should not disable either.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#14

Post by chunkyks »

concerned_user wrote: post #4
frabbit wrote: post #2

Important note on this: "Fortunately, the default security hardenings in most container environments are enough to prevent container escape. Containers running with AppArmor or SELinux are protected. " So, all that hard work on SELinux continues to pay off.

Sadly, many answers to questions related to selinux issues, or howto's start with: Disable selinux.

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, and closing it back down while leaving what I need open remains impossible black magic.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#15

Post by yjftsjthsd-h »

suifbwish wrote: post #3

Couldn’t you prevent against this sort of thing by using disposable VMs to host the containers? Sure it would be an extra layer of resources but it would double the complexity of the attack required to breach the physical node.

Correct on both counts; you can, and it hurts performance / resource use. There's also intermediate options like gvisor. In practice, the performance issues mean that most people don't bother.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#16

Post by stormbrew »

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 like, for example, plan9's.

The problem here stems entirely from trying to keep these globally-overriding capabilities like CAP_SYS_ADMIN and CAP_DAC_OVERRIDE while also allowing users to create their own namespaces. All these CVEs weren't things as long as only root could create new userns', and now that normal users can all these areas where things weren't checked are coming out of the woodwork.

But a ground up capability-based system avoids this kind of problem by simply making it impossible to elevate to a privilege level like 'root' on POSIX systems, and so namespacing within those systems is incredibly natural to the point that it didn't really get a name (containers) until one was needed for linux' cognitive dissonance around the idea.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#17

Post by stormbrew »

jeffbee wrote: post #9

This style of writing sucks, and the abuse of the meaningless term "container" does nothing to clear it up. To reduce this CVE to one sentence: a process running in the top level control group, which has the ability to create user namespace, can take over the machine, because the kernel fails to check for CAP_SYS_ADMIN. See how easy that was?

You kind of missed the key to the whole thing here, though, which is that users are able to create userns' now by default. This is really important to understanding this and the last few container escape CVEs.

The article doesn't do much better on that front, but it is in there at least.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#18

Post by chucky_z »

chunkyks wrote: post #14
concerned_user wrote: post #4

Earlier quoted context omitted.

Sadly, many answers to questions related to selinux issues, or howto's start with: Disable selinux.

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?

Re: New Linux vulnerability affecting cgroups: can containers escape?

#19

Post by frabbit »

AaronFriel wrote: post #13
frabbit wrote: post #12

Earlier quoted context omitted.

> it's clear that for most lay folks, SELinux is software that doesn't work. I have always used selinux enabled systems. For the first few years it was a bit confusing and frustrating at times, but for the last (decade?) I have never had to butt heads with it. The default policies shipped by e.g. Fedora (a userland closest to the development of this work and therefore probably better maintained than some others) work…

That's not my assertion, my assertion is that SELinux doesn't work for a lot of people even if it works for you or I; and that's why you see the advice to disable it in forum posts. To be clear: SELinux is an important mitigation - just like the Windows Firewall - and one should not disable either.

I disagree. The advice to disable SELinux, like your assertion that it's too complicated for ordinary users, belongs to an older time. It's time to lay that myth to bed.

Sure, if you're messing around with k8s and doing fun eBPF stuff you are going to need to be careful. But for just installing an OS, running it to do some web-browsing, gaming, image editing, wordprocessing? I would be highly surprised if the defaults do not work.

Re: New Linux vulnerability affecting cgroups: can containers escape?

#20

Post by tptacek »

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 don't think the industry is moving towards deepening dependence on container/jail interfaces for multitenant workloads --- virtualization has gotten incredibly cheap. So these issues are mostly problems for internal data center segregation and blast radius reduction. It's not nothing, they're important security problems, but unless you're doing something dubious, they shouldn't be existentially important.

There are AWS and GCP instance types with nested virtualization that'll let you run Firecracker. Digital Ocean apparently supports it everywhere.

Post reply on HN