zlacker

[return to "Microsandbox: Virtual Machines that feel and perform like containers"]
1. zackmo+EL[view] [source] 2025-05-30 18:48:29
>>makebo+(OP)
This is great!

I'd like to see a formal container security grade that works like:

  1) Curate a list of all known (container) exploits
  2) Run each exploit in environments of increasing security like permissions-based, jail, Docker and emulator
  3) The percentage of prevented exploits would be the score from 0-100%
Under this scheme, I'd expect naive attempts at containerization with permissions and jails to score around 0%, while Docker might be above 50% and Microsandbox could potentially reach 100%.

This might satisfy some of our intuition around questions like "why not just use a jail?". Also the containers could run on a site on the open web as honeypots with cash or crypto prizes for pwning them to "prove" which containers achieve 100%.

We might also need to redefine what "secure" means, since exploits like Rowhammer and Spectre may make nearly all conventional and cloud computing insecure. Or maybe it's a moving target, like how 64 bit encryption might have once been considered secure but now we need 128 bit or higher.

Edit: the motivation behind this would be to find a container that's 100% secure without emulation, for performance and cost-savings benefits, as well as gaining insights into how to secure operating systems by containerizing their various services.

◧◩
2. tptace+JR[view] [source] 2025-05-30 19:38:31
>>zackmo+EL
The issue, at least with multitenant workloads, isn't "container vulnerabilities" as such; it's that standard containers are premised on sharing a kernel, which makes every kernel LPE a potential container escape --- there's a long history of those bugs, and they're only rarely flagged as "container escapes"; it's just sort of understood that a kernel LPE is going to break containers.
◧◩◪
3. delusi+iR1[view] [source] 2025-05-31 09:41:56
>>tptace+JR
> it's just sort of understood that a kernel LPE is going to break containers.

I think it's generally understood that any sort of kernel LPE can potentially (and therefore is generally considered to) lead to breaking all security boundaries on the local machine, since the kernel contains no internal security boundaries. That includes both containers, but also everything else such a user separation, hardware virtualization controlled by the local kernel, and kernel private secrets.

◧◩◪◨
4. zrm+Ms2[view] [source] 2025-05-31 16:46:10
>>delusi+iR1
A large proportion of LPE vulnerabilities are in the nature of "perform a syscall to pass specially crafted data to the kernel and trigger a kernel bug". For containers, the kernel is the host kernel and now the host is compromised. For VMs, the kernel is the guest kernel and now the guest is compromised, but not the host. That's a much narrower compromise and in security models where root on the guest is already expected to be attacker-controlled, isn't even a vulnerability.
◧◩◪◨⬒
5. tptace+cw2[view] [source] 2025-05-31 17:15:32
>>zrm+Ms2
Yes, what they just said here. ^^ ^^
[go to top]