As far as I can tell, Solaris Zones are no more secure than Linux containers; both use kernel-level isolation mechanisms, while sharing the same kernel between zones/containers. And thus they both have the same security property: secure as long as you can't successfully exploit a syscall, but if you can, you get kernel-level access.
The security property of "secure unless there's an exploit" applies to basically everything (maybe excluding formally verified software), including Xen and KVM, so I don't see how that's a specific knock against Zones. Yes, if there's an exploit that lets you do something you shouldn't be able to do, you can break out of the container/VM. But, like Xen and KVM, Zones are so far fairly successfully used as an isolation mechanism for the public cloud, for some years now. And all three make the claim that you ought to be able to rely on their isolation mechanisms, and any hole in them will be considered a serious bug. Whereas the way Docker is using Linux containers doesn't seem secure enough to make that claim or be used for that purpose, at least not yet.
> The security property of "secure unless there's an exploit" applies to basically everything (maybe excluding formally verified software), including Xen and KVM, so I don't see how that's a specific knock against Zones.
Defense in depth. With KVM, you'd have to exploit the guest kernel, then exploit KVM's hardware emulation to get to host userspace, then escalate to host root/kernel. (And KVM can use seccomp to limit itself, making that last step harder.) With Linux containers or Solaris Zones, you run directly on top of the host kernel, so you just need a single kernel exploit.
In any case, Zones and containers have the same security properties (running directly on top of the kernel), so the original comment about Zones being more secure than containers makes no sense.
> Whereas the way Docker is using Linux containers doesn't seem secure enough...
Which is totally expected, because docker tries to be useful to the largest user-base possible. It would be quite harder to use if didn't support directory mounting (via -v). And it would be a total nightmare for almost every user if you had to specify a list of allowed syscalls for every container.
This reminds me the situation with SELinux a lot. It has improved a lot but I still see "disable SELinux" almost in every tutorial I read on CentOS, Fedora or RHEL.
> This reminds me the situation with SELinux a lot. It has improved a lot but I still see "disable SELinux" almost in every tutorial I read on CentOS, Fedora or RHEL.
Because security is hard.
Just look at the Mac OS X users running as root and disabling Gatekeeper.
Or the developers that stay away from the sandbox model.
One of the nice things of mobile OSes is that there isn't a way around the container model. Although the history with permissions kind of messes it.
Oracle doesn't tend to disclose security vulnerabilities; they just silently fix them; the absence of CVEs is not the absence of vulnerabilities. On top of that, a vulnerability wouldn't need to be Zones-specific; almost any kernel exploit would work, unless it uses a syscall that only works in the "global" zone.
Really? Which ones? I'm pretty sure local privilege exploits that give you root don't magically jump you into JID 0 (prison0), escaping the jail. You'd just have "root" in the jail.
edit: well i guess if your attacker knows you're on FreeBSD they could override to prison0 in the exploit. But it's a good thing we dont have a ton of local priv exploits, eh?
edit2: and that was a pretty ignorant statement of mine about root exploits anyway :)
