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

71–80 of 86 posts

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

#71

Post by worewood »

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…

With Spectre we discovered that not even VMs are adequate security boundaries.

My opinion: want security? Separate (bare metal) machines. Period.

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

#72

Post by viraptor »

wmf wrote: post #61
richardfey wrote: post #59

Earlier quoted context omitted.

Who was he referring to?

No one in particular. He's saying there are no perfect developers so no hypervisors will ever be perfectly secure.

Which is a silly statement, because for all X, no X will ever be perfectly secure. That's why we have multiple layers available and containers and VMs are just one of them.

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

#73

Post by viraptor »

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…

> They're meant to contain things from going off the rails unintentionally, but an actual threat was another story.

I disagree with that idea. The actual that may be as limited in capabilities as a standard bug. Let's say you have a problem with your webapp where you can read an arbitrary file, but nothing else. Containers are a perfect protection in this case if you want to isolate the app from any other services running on the host (monitoring, provisioning, etc.).

There's no perfection and defence in depth is what we need to use everywhere. Unless you can break through all layers at the same time, imperfect layers are a valid improvement. See how many default protections you have to turn off to even make this bug viable.

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

#74

Post by cshokie »

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…

At least some of the Azure series support nested virtualization. See https://docs.microsoft.com/en-us/azure/virtual-machines/dv4-.... There are a lot of series and I don’t know the breakdown but I would expect dsv4 to be one of the more widely used options because it is for generic CPU workloads.

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

#75

Post by userbinator »

worewood wrote: post #71
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…

With Spectre we discovered that not even VMs are adequate security boundaries. My opinion: want security? Separate (bare metal) machines. Period.

...and in the spirit of the parent comment, Intel didn't intend for protected mode to be a security boundary either. The 286 and 386 programming manuals referred to the protections as a form of reducing the severity of bugs.

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

#76

Post by _8j50 »

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 think Unikernel VMs are the future. Build your app into One blob with no user/kernel space boundary that runs in a guest VM. No boot time or wasted memory/latency (context switch) issues.

That said, even VM are best-effort security boundaries, then apparmor/selinux type restrictions put in place on the host should be the main hard security boundary IMO.

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

#77

Post by dboreham »

_8j50 wrote: post #76
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 think Unikernel VMs are the future. Build your app into One blob with no user/kernel space boundary that runs in a guest VM. No boot time or wasted memory/latency (context switch) issues. That said, even VM are best-effort security boundaries, then apparmor/selinux type restrictions put in place on the host should be the main hard security boundary IMO.

Good luck debugging that.

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

#78

Post by Too »

AaronFriel wrote: post #64
MonaroVXR wrote: post #63

Earlier quoted context omitted.

Fedora literally gives you a notification and you can take action (Me a as novice Linux user)

That's fantastic for Fedora desktop users. I don't expect you'd know, but is there a way to get the same quality of information via a CLI command?

grep denied /var/log/audit/*

On some systems the avc violations also get printed in dmesg.

If violations block your whole system from even running, you can enable permissive mode, this only logs violations without enforcing them.

As others already mentioned, turning violation logs into allow rules can be done with audit2allow. Wouldn’t recommend blindly using that though as the generated rules are always either too narrow or too wide, just use it as a guideline.

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

#80

Post by _8j50 »

dboreham wrote: post #77
_8j50 wrote: post #76

Earlier quoted context omitted.

I think Unikernel VMs are the future. Build your app into One blob with no user/kernel space boundary that runs in a guest VM. No boot time or wasted memory/latency (context switch) issues. That said, even VM are best-effort security boundaries, then apparmor/selinux type restrictions put in place on the host should be the main hard security boundary IMO.

Good luck debugging that.

Shouldn't need luck. It wouldn't use qemu or vmware but a specialized VM manager that will interface with it via network/virtual-hardware and expose a virtual file system to it (e.g.: it will call "read()" but instead of glibc wrapping a syscall, a compiled in wrapper would ask the hypervisor to "read()", except it would just memcpy() around a file opened at virtual boot instead of asking the kernel to read a file and then send the data back while avoiding context switch and just send request, wait for interrupt).

File system, networking and security need to abstracted in a way that is ideal for performance and introspection, specifically for a unikernel built to interface with the abstraction.

Post reply on HN