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

CVE-2019-5736: runc container breakout

seclists.org

Post reply on HN
Print view View original

71–80 of 102 posts

Re: CVE-2019-5736: runc container breakout

#71

Post by dfc »

CaliforniaKarl wrote: post #8

Debian’s security tracker, showing the affected versions, and (when available) the fixed versions: https://security-tracker.debian.org/tracker/CVE-2019-5736 And Ubuntu’s: https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2... Personally, I like these vs. RHEL, since all the info is on page.

In addition to the information all being on one page you can also:

    git clone https://salsa.debian.org/security-tracker-team/security-tracker.git 
    git clone https://git.launchpad.net/ubuntu-cve-tracker
There is a lot of interesting things you can do with the data.

Re: CVE-2019-5736: runc container breakout

#72

Post by [deleted] »

geofft wrote: post #64
wicket wrote: post #58

> However, it is blocked through correct use of user namespaces (where the host root is not mapped into the container's user namespace). In other words, this won't affect anyone who understands the implications of running a process as root. Unfortunately, the sad truth is that most people I've come across who have "lots of experience" with implementing Docker containers, do not even understand the basics of how they…

I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to no…

[deleted]

Re: CVE-2019-5736: runc container breakout

#73

Post by numbsafari »

sethvargo wrote: post #36
sethvargo wrote: post #35

Hey all - Seth from Google here. Please let us know if you have any questions regarding GKE or questions about the upgrade process. I'm also happy to escalate any feedback to our internal product and engineering teams. Here's link to our security posting with more information and upgrade procedures: https://cloud.google.com/kubernetes-engine/docs/security-bul...

One thing I want to emphasize: you are only affected if you're using Ubuntu base images for your node pools. If you're using COS, you are unaffected.

It would be great if folks could run COS and leverage tools like Falco. I realize there is a trade-off between having a totally locked down OS and being able to flexibly use such tools.

However, Google and Sysdig announced a partnership around Falco and GCSCC integration. It would make sense that such a tool would be able to be run on COS.

Perhaps I'm guilty wanting to have my cake and eat it, too. But this seems like an area where GKE and COS are somewhat limited.

Re: CVE-2019-5736: runc container breakout

#74

Post by random_copy »

numbsafari wrote: post #73
sethvargo wrote: post #36

Earlier quoted context omitted.

One thing I want to emphasize: you are only affected if you're using Ubuntu base images for your node pools. If you're using COS, you are unaffected.

It would be great if folks could run COS and leverage tools like Falco. I realize there is a trade-off between having a totally locked down OS and being able to flexibly use such tools. However, Google and Sysdig announced a partnership around Falco and GCSCC integration. It would make sense that such a tool would be able to be run on COS. Perhaps I'm guilty wanting to have my cake and eat it, too. But this seems lik…

Falco can read events via an ebpf program (instead of the falco-probe kernel module).

https://github.com/draios/sysdig/wiki/eBPF

So, falco will work on GKE and COS

Re: CVE-2019-5736: runc container breakout

#75

Post by markstemm »

numbsafari wrote: post #73
sethvargo wrote: post #36

Earlier quoted context omitted.

One thing I want to emphasize: you are only affected if you're using Ubuntu base images for your node pools. If you're using COS, you are unaffected.

It would be great if folks could run COS and leverage tools like Falco. I realize there is a trade-off between having a totally locked down OS and being able to flexibly use such tools. However, Google and Sysdig announced a partnership around Falco and GCSCC integration. It would make sense that such a tool would be able to be run on COS. Perhaps I'm guilty wanting to have my cake and eat it, too. But this seems lik…

Hi, Falco developer here. We do have support for running falco with an ebpf program taking the place of the kernel module. You can learn more about ebpf support at https://github.com/draios/sysdig/wiki/eBPF, and you should be able to run falco with ebpf by setting an environment variable SYSDIG_EBPF_PROBE="".

Re: CVE-2019-5736: runc container breakout

#77

Post by numbsafari »

markstemm wrote: post #75
numbsafari wrote: post #73

Earlier quoted context omitted.

It would be great if folks could run COS and leverage tools like Falco. I realize there is a trade-off between having a totally locked down OS and being able to flexibly use such tools. However, Google and Sysdig announced a partnership around Falco and GCSCC integration. It would make sense that such a tool would be able to be run on COS. Perhaps I'm guilty wanting to have my cake and eat it, too. But this seems lik…

Hi, Falco developer here. We do have support for running falco with an ebpf program taking the place of the kernel module. You can learn more about ebpf support at https://github.com/draios/sysdig/wiki/eBPF , and you should be able to run falco with ebpf by setting an environment variable SYSDIG_EBPF_PROBE="".

This is awesome news! I see it’s still beta, which is probably why the Falco docs still say GKE users must run Ubuntu images. Adding this to my tracking list. Thanks.

Re: CVE-2019-5736: runc container breakout

#79

Post by nicoburns »

wicket wrote: post #69
geofft wrote: post #64

Earlier quoted context omitted.

I think it's subtler than that. It is mostly safe to run a contained process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to no…

> I think it's subtler than that. It is mostly safe to run a process as "root" because in theory the ways that root access can be exercised is highly sandbox by the use of various namespaces, as well as things like capability restrictions (you generally don't have CAP_SYS_ADMIN or a few others), limited syscall attack surface (you generally have a syscall allowlist via seccomp-bpf), etc. Yes, it's wrong to not unders…

I believe there was work on non-root container host processes going on at some point? Did that ever get to a usable state?

Re: CVE-2019-5736: runc container breakout

#80

Post by int_19h »

ajross wrote: post #23
justanother- wrote: post #17

Earlier quoted context omitted.

Alternative idea: throw away docker and katacontainers and move to freebsd, where jails were introduced on 14 Mar 2000 (no, seriously, superior technology exists for 19 years - stable, time proven, working). Some more info: https://www.freebsd.org/doc/handbook/jails.html And for quick start: https://github.com/iocage/iocage

Jails are virtually identical technology to Linux containers from a security point of view. They've had holes before and they likely will again, and a breakout like this (seems like the root cause here is a writable file descriptor to the host binary) can absolutely compromise the host system. The upthread recommendation was using hardware VM technology, which is a fundamentally different isolation model from what so…

My understanding is that jails were designed as a security boundary from the get go, unlike containers. Wouldn't that result in code that's less likely to be exploitable?
Post reply on HN