A security exploit has surfaced that can allow rogue programs to break out of Docker containers and access files on their host OS, but the flaw has been sealed in the latest version of the tech. Unlike virtualization, which launches a separate operating system instance for every virtual machine, Linux containerization sticks …
chroot as a concept
has an interesting history. There are many web pages describing how, basically, you shouldn't treat it as being a proper security measure, like, ever. I know that things have moved on from naively trusting chroot, and Docker totally isn't just chroot in another guise, but still, I'm not at all surprised that there would be bugs like this in it... (mind you, bugs crop up in vm systems too, from time to time...)
It was probably usability that spurred the development of the first chroot systems, and I'm sure that a similar process took place around the development of containers. Let's hope they can focus on security a bit more to squelch bugs like this so that it doesn't just end up as chroot v2.0.
If I get this correctly...
The container security is only doomed if you do have all of the contained systems in the same filesystem. It is relatively common practice to set up a different filesystem (I do it with LVM) for each of them, and AFAICT, you would not be able to link to any inodes outside of it.
I would like to know how this works WRT ZFS/BTRFS filesystem subdivisions. Don't have any hands-on experience... But if I understand the layout correctly, they would be still compromised.
Re: If I get this correctly...
"I would like to know how this works WRT ZFS/BTRFS filesystem subdivisions. Don't have any hands-on experience... But if I understand the layout correctly, they would be still compromised."
They certainly do not on Solaris and ZFS and AFAIR never been. But that's proper design of OS for you, not set of kernel crutches written by god knows who.
Insecure by Design?
Who could possibly gain by this?
Re: Insecure by Design?
You seem to have this confused with Windoze.
Single level of security boundaries is always bad
Best practice for deploying Docker containers is with SELinux (or similar technology), deploying without it is just poor design, period.
Virtual Machines, though now undeniably more secure, are also not as bulletproof isolation as the article purports to suggest, and doubly so when the tech started (bursting out of VM into hypervisor was a fairly common bug considering its impact). On some CPUs the solution was even to buy new ones, as the flaw was in the HW. So even with VMs administrators should harden hypervisors as much as possible.
- Breaking news: Google exec veep in terrifying SKY PLUNGE DRAMA
- Geek's Guide to Britain Kingston's aviation empire: From industry firsts to Airfix heroes
- Analysis Happy 2nd birthday, Windows 8 and Surface: Anatomy of a disaster
- Google CEO Larry Page gives Sundar Pichai keys to the kingdom
- Something for the Weekend, Sir? SKYPE has the HOTS for my NAKED WIFE