Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsandbox: Virtual Machines that feel and perform like containers

github.com

Post reply on HN
Print view View original

91–100 of 195 posts

Re: Microsandbox: Virtual Machines that feel and perform like containers

#91

Post by bjackman »

zackmorris wrote: post #81

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…

You cannot build a secure container runtime (against malicious containers) because underlying it is the Linux kernel.

The only way to make Linux containers a meaningful sandbox is to drastically restrict the syscall API surface available to the sandboxee, which quickly reduces its value. It's no longer a "generic platform that you can throw any workload onto" but instead a bespoke thing that needs to be tuned and reconfigured for every usecase.

This is why you need virtualization. Until we have a properly hardened and memory safe OS, it's the only way. And if we do build such an OS it's unclear to me whether it will be faster than running MicroVMs on a Linux host.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#92

Post by tptacek »

zackmorris wrote: post #81

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…

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.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#93

Post by westurner »

appcypher wrote: post #39
westurner wrote: post #29

Earlier quoted context omitted.

> I would consider Docker for VMs instead. Native Containers would probably solve here, too. From https://news.ycombinator.com/item?id=43553198 : >>> ostree native containers are bootable host images that can also be built and signed with a SLSA provenance attestation; https://coreos.github.io/rpm-ostree/container/ And also from that thread: > How should a microkernel run (WASI) WASM runtimes? What is the most minima…

> What is the most minimal microvm for WASM / WASI, By setting up an image with wasmtime for example. > and what are the advantages to running WASM workloads with firecracker or microsandbox? I can think of stronger isolation or when you have legacy stuff you need to run alongside.

From https://e2b.dev/blog/firecracker-vs-qemu

> AWS built [Firecracker (which is built on KVM)] to power Lambda and Fargate [2], where they need to quickly spin up isolated environments for running customer code. Companies like E2B use Firecracker to run AI generated code securily in the cloud, while Fly.io uses it to run lightweight container-like VMs at the edge [4, 5].

"We replaced Firecracker with QEMU" (2023) https://news.ycombinator.com/item?id=36666782

"Firecracker's Kernel Support Policy" describes compatible kernel configurations; https://github.com/firecracker-microvm/firecracker/blob/main...

/? wasi microvm kernel [github] https://www.google.com/search?q=wasi+microvm+kernel+GitHub :

- "Mewz: Lightweight Execution Environment for WebAssembly with High Isolation and Portability using Unikernels" (2024) https://arxiv.org/abs/2411.01129 similar: https://scholar.google.com/scholar?q=related:b3657VNcyJ0J:sc...

Re: Microsandbox: Virtual Machines that feel and perform like containers

#94

Post by Etheryte »

zackmorris wrote: post #81

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…

In a way, containers already run as honeypots with cash or crypto prizes, it's called production code and plenty of people are looking for holes day and night. While this setup sounds like a nice idea conceptually, the monetary incentives it could offer would surely be miniscule compared to real targets.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#95

Post by Veserv »

bjackman wrote: post #91
zackmorris wrote: post #81

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…

You cannot build a secure container runtime (against malicious containers) because underlying it is the Linux kernel. The only way to make Linux containers a meaningful sandbox is to drastically restrict the syscall API surface available to the sandboxee, which quickly reduces its value. It's no longer a "generic platform that you can throw any workload onto" but instead a bespoke thing that needs to be tuned and rec…

You cannot build a secure virtualization runtime because underlying it is the VMM. Until you have a secure VMM you are subject to precisely the same class of problems plaguing container runtimes.

The only meaningful difference is that Linux containers target partitioning Linux kernel services which is a shared-by-default/default-allow environment that was never designed for and has never achieved meaningful security. The number of vulnerabilities resulting from, "whoopsie, we forgot to partition shared service 123" would be hilarious if it were not a complete lapse of security engineering in a product people are convinced is adequate for security-critical applications.

Present a vulnerability assessment demonstrating a team of 10 with 3 years time (~10-30 M$, comparable to many commercially-motivated single-victim attacks these days) can find no vulnerabilities in your deployment or a formal proof of security and correctness otherwise we should stick with the default assumption that software if easily hacked instead of the extraordinary claim that demands extraordinary evidence.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#96

Post by simonw »

appcypher wrote: post #3

Thanks for sharing! I'm the creator of microsandbox. If there is anything you need to know about the project, let me know. This project is meant to make creating microvms from your machine as easy as using Docker containers. Ask me anything.

I'm trying this out now and it's very promising. One problem I'm running into with the Python library is that I'd like to keep that sandbox running for several minutes while I do things like set variables in one call and then use them for stuff several calls later. I keep seeing this error intermittently:

    Error: Sandbox is not started. Call start() first
Is there a suggested way of keeping a sandbox around for longer?

The documented code pattern is this:

    async def main():
        async with PythonSandbox.create(name="my-sandbox") as sb:
            exec = await sb.run("print('Hello, World!')")
            print(await exec.output())
Due to the way my code works I want to instantiate the sandbox once for a specific class and then have multiple calls to it by class methods, which isn't a clean fit for that "async with" pattern.

Any recommendations?

Re: Microsandbox: Virtual Machines that feel and perform like containers

#97

Post by akdev1l »

bjackman wrote: post #91
zackmorris wrote: post #81

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…

You cannot build a secure container runtime (against malicious containers) because underlying it is the Linux kernel. The only way to make Linux containers a meaningful sandbox is to drastically restrict the syscall API surface available to the sandboxee, which quickly reduces its value. It's no longer a "generic platform that you can throw any workload onto" but instead a bespoke thing that needs to be tuned and rec…

One can definitely build a container runtime that uses virtualization to protect the host

For example there is Kata containers

https://katacontainers.io/

This can be used with regular `podman` by just changing the container runtime so there’s no even need for any extra tooling

In theory you could shove the container runtime into something like k8s

Re: Microsandbox: Virtual Machines that feel and perform like containers

#98

Post by akdev1l »

dataflow wrote: post #11

Tangential question: why does it normally take so long to start traditional VMs in the first place? At least on Windows, if you start a traditional VM, it takes several seconds for it to start running anything . Edit: when I say anything , I'm not talking user programs. I mean as in, before even the first instruction of the firmware -- before even the virtual disk file is zeroed out, in cases where it needs to be. Yo…

The answer is that it doesn’t have to be like that.

In practice virtual machines are trying to emulate a lot of stuff that isn’t really needed but they’re doing it for compatibility.

If one builds a hypervisor which is optimized for startup speed and doesn’t need to support generalized legacy software then you can:

> Unlike traditional VMs that might take several seconds to start, Firecracker VMs can boot up in as little as 125ms.

Re: Microsandbox: Virtual Machines that feel and perform like containers

#99

Post by godelski »

zackmorris wrote: post #81

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…

Importantly I'd like to see the configurations of the machines. There's a lot you can do to docker or systemd spawns that greatly vary the security levels. This would really help show what needs to be done and what configurations lead to what risks.

Basically I'd love to see a giant ablation

Re: Microsandbox: Virtual Machines that feel and perform like containers

#100

Post by rbitar »

appcypher wrote: post #88
rbitar wrote: post #84

Looks great and excited to try this out. We’ve also had success using CodeSandbox SDK and E2B, can you share some thoughts on how you compare or future direction? Do you also use Firecracker under the hood?

> can you share some thoughts on how you compare or future direction? Microsandbox does not offer a cloud solution. It is self-hosted, designed to do what E2B does, to make it easier working with microVM-based sandboxes on your local machine whether that is Linux, macOS or Windows (planned) and to seamlessly transition to prod. > Do you also use Firecracker under the hood? It uses libkrun.

Self-hosting is definitely something we are keen to explore as most of the cloud solutions have resource constrains (ie, total active MicroVMs and/or specs per VM) and managing billing gets complicated even with hibernation features. Great project and we'll definitely take it for a spin
Post reply on HN