Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> anyone still thinks that they can draw a security boundary anywhere with a shared kernel

Containers are everywhere.



They don't work as reliable security boundaries; they're developer/ops tools.


Thomas, what are your thoughts on micro-vms such as kata containers? You can use them as a backend for docker in place of runc.

I'm sure you're well aware, but for the readers, they are isolated with a CPU's VT instructions which are built to isolate VMS. I still think "containers don't contain" in a very Dan Walsh boston accent, but this seems like a respectable start.

https://katacontainers.io


I have no strong opinion other than that untrusting cotenants shouldn't directly share a kernel.


They're slow and so unsuitable for dev work. They might be somewhat better for prod, but it depends on a wide selection of unproven hypervisors.


Which "unproven" hypervisors are those? Kata works with Firecracker.


QEMU is more well-known and tested than Firecracker; i.e., a hacked version is used in Xen used everywhere in the past decade while Firecracker is primarily an Amazon-only thing. Cloud Hypervisor, Dragonball, and StratoVirt aren't well-known or battle-tested IMO. The problem is none of these possess true manageability and isolation features of any solid type 1 hypervisor which makes Kata equivalent to a user-space application rather than a reliable platform with harder resource isolation guarantees.

https://github.com/kata-containers/kata-containers/blob/main...


Firecracker is probably the 2nd or 3rd most widely deployed hypervisor in production deployments. I think "Amazon-only" isn't doing the rhetorical lifting you mean it to do. The idea that it's "equivalent to a user-space application" makes very little sense.


I think they mean in regards to cross kernel attacks. vms didn't protect across speculative execution attacks.

I believe there are even more course grained timing attacks with dma and memory that are waiting to be abused.


No, that's true, VMs don't protect against microarchitectural attacks. But neither does shared-kernel isolation; in fact, shared-kernel is even worse at it. So if that's the concern, it doesn't make much sense in the threat model.


Isolation guarantees: Separate metal > type 1 hypervisors > type 2 hypervisors > containers > processes > OS threads > cooperative threads ;)


Accurate and agree.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: