5 ms·
Note that these are docker containers and not "containers" as a general purpose concept. Jails still contain fine....
by duaneb 12y ago
Note that these are docker containers and not "containers" as a general purpose concept. Jails still contain fine....
- justincormack 12y agoNo, these are Linux namespaces. These break up the things jail does into smaller pieces of functionality, and that is more difficult. But this bug is to do with the fact that Linux just has a lot more complex kernel functionality than the BSDs do. You can break out of a jail if there is a local exploit that gives kernel code execution as non root.
- lifeisstillgood 12y agoBut are there examples of that under BSD ?
- justincormack 12y agoSure. Here [1] is one for FreeBSD I found in a couple of minutes searching. I am sure you can find a more recent one. That is complete arbitrary kernel code execution for any user. I can easily find some for the other BSDs (I am a NetBSD developer), of course there was the famous remote code execution for OpenBSD [2]. Security is hard, all code has bugs. Never be complacent. Use layers of security, reduce risks, audit,... [1] https://www.freebsd.org/security/advisories/FreeBSD-SA-08:07.amd64.asc https://www.freebsd.org/security/advisories/FreeBSD-SA-08:07... [2] http://www.coresecurity.com/content/open-bsd-advisorie http://www.coresecurity.com/content/open-bsd-advisorie
- duaneb 12y ago> You can break out of a jail if there is a local exploit that gives kernel code execution as non root. Well, this has always been true of any sandbox or virtual machine. > But this bug is to do with the fact that Linux just has a lot more complex kernel functionality than the BSDs do. Also probably true. The linux kernel was not built to be namespaced, unfortunately, so bolting no namespacing will have edge cases that are not covered. I would not recommend anyone use linux containerization for production environments for some years.
- nl 12y ago> You can break out of a jail if there is a local exploit that gives kernel code execution as non root. Well, this has always been true of any sandbox or virtual machine. That's not true for Virtual Machines. I would not recommend anyone use linux containerization for production environments for some years. Too bad people have been doing it for years - successfully - already. For example, most PAAS products use linux containers for isolation and as a security layer. OpenVZ (ie, early version of Linux containers) has been used in production hosting environments to give people root shell access for just as long.
- krakensden 12y ago> > You can break out of a jail if there is a local exploit that gives kernel code execution as non root. > That's not true for Virtual Machines. That's certainly an opinion: http://www.ubuntu.com/usn/usn-2342-1/ http://www.ubuntu.com/usn/usn-2342-1/ > It was discovered that QEMU incorrectly handled certain PCIe bus hotplug operations. A malicious guest could use this issue to crash the QEMU host, resulting in a denial of service Most virtualization servers are great big chunks of C and C++ running as root with a bunch of crazy optimizations for benchmarks. They get some help from the ISA, but... stuff happens.
- duaneb 12y agoAre you kidding? Virtual machines have been exploitable for as long as they've existed. A quick google turns up this: http://www.eweek.com/c/a/Security/VUPEN-Exploit-Enables-Virtual-Machine-Escape-107884/ http://www.eweek.com/c/a/Security/VUPEN-Exploit-Enables-Virt... I'm not arguing that people haven't successfully run in production, but doing so and assuming you won't be hit with a zero-day exploit is just naive.