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

21–30 of 86 posts

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

#21

Post by tptacek »

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…

I'm not sure a year has gone by without a vulnerability that breaks shared-kernel isolation in reasonable configurations. Nobody was going to DAC or MAC out `waitid`, but `waitid` for a time take a kernel address for its siginfo_t parameter.

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

#22

Post by 2OEH8eoCRo0 »

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.

Why is the Linux community full of horrible advice?

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

#23

Post by stormbrew »

tptacek wrote: post #21
stormbrew wrote: post #16

Earlier quoted context omitted.

> 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…

I'm not sure a year has gone by without a vulnerability that breaks shared-kernel isolation in reasonable configurations. Nobody was going to DAC or MAC out `waitid`, but `waitid` for a time take a kernel address for its siginfo_t parameter.

I didn't mean to imply that there'd never been any kind of "container escape" vuln before userns creation was opened, just the "create userns, escape with magic privs" kind was new and largely because of that change.

(I do think the change will be a net good in the long run, because rootless docker is probably a net improvement, but I think maybe it would have also been a good opportunity to reconsider how they inherit these global capabilities)

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

#24

Post by [deleted] »

frabbit wrote: post #19
AaronFriel wrote: post #13

Earlier quoted context omitted.

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 default…

[deleted]

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

#25

Post by silisili »

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.

I'd argue the vast majority of Linux desktop users (already a small group) don't use SELinux. So naturally when trying to help someone using something we don't have experience with and don't find necessary, that advice becomes more prevalent.

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

#26

Post by AaronFriel »

frabbit wrote: post #19
AaronFriel wrote: post #13

Earlier quoted context omitted.

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 default…

> The advice to disable SELinux... time to lay that myth to bed.

I think we agree, and Fedora / Red Hat have done great work setting up great defaults.

But when a user encounters an issue with SELinux, the lack of feedback mechanisms to help them onto a better path results in them finding that advice.

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

#28

Post by jsiepkes »

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?

It might have looked like FreeBSD jails or Illumos / Solaris Zones. Both of which are containers designed as a security boundary from the start.

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

#29

Post by not2b »

2OEH8eoCRo0 wrote: post #22
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.

Why is the Linux community full of horrible advice?

Often the issue is that what was decent advice five years ago can become horrible advice later, but the formerly decent advice is already moderated to the top on Stack Overflow and Reddit and is the first hit on a Google search, while the approach that people should be using now just isn't found.

You'll often find horribly complex multi-step instructions for How to Do X ranked more highly than simple instructions about how to use a new interface to do everything in one step, because there was a window of time when the complex instructions were required, everyone was so grateful for them and upvoted them.

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

#30

Post by paulfurtado »

tptacek wrote: post #20
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…

Slightly pedantic: ec2 doesn't actually support nested virtualization on any instance type I know of, but does have baremetal instance types that support virtualization.

The reason I mention this is because, sadly, baremetal instance types are only ever the largest size of a given family which is cost prohibitive for most users. And even if cost isn't an issue, they take much much longer to start (like 10-20+ minutes) and they actually fail to start far too frequently. It's really a shame that all instance types other than baremetal have virtualization extensions disabled, otherwise we'd be operating far more workloads in firecracker or kata. We operate huge kubernetes clusters so the cost is roughly the same whether it's fewer big instances or more smaller instances, but those startup times and reliability are terrible for autoscaling.

Please, AWS, bring nested virtualization to all nitro instance types!

Post reply on HN