eyberg (u/eyberg) - Readit News

eyberg commented on Don't trust AI agents nanoclaw.dev/blog/nanocla... · Posted by u/gronky_

benatkin · 15 days ago

No, but Podman is. The recent escapes at the actual container level have been pretty edge case. It's been some years since a general container escape has been found. Docker's CVE-2025-9074 was totally unnecessary and due to Docker being Docker.

eyberg · 15 days ago

No they have not been. There were at least 16 container escapes last year - at least 8 of them were at the runtime layer.

I personally spent way too much time looking at this in the past month:

https://nanovms.com/blog/last-year-in-container-security

runc: https://www.cve.org/CVERecord?id=CVE-2025-31133

nvidia: https://www.cve.org/CVERecord?id=CVE-2025-23266

runc: https://www.cve.org/CVERecord?id=CVE-2025-52565

youki: https://www.cve.org/CVERecord?id=CVE-2025-54867

Also, last time I checked podman uses runc by default.

eyberg commented on Building secure, scalable agent sandbox infrastructure browser-use.com/posts/two... · Posted by u/gregpr07

Bnjoroge · 15 days ago

maybe the usecase that makes unikernels alot more mainstream. Always found them intriguing

eyberg · 15 days ago

Except this is very clearly running linux.

eyberg commented on Hands-On Introduction to Unikernels labs.iximiuz.com/tutorial... · Posted by u/valyala

gucci-on-fleek · 2 months ago

I think that part of it is that relatively few people use bare-metal servers these days, and nested virtualisation isn't universally supported. I also found this technical critique [0] compelling, but I have no idea if any of it is accurate or not.

[0]: https://www.tritondatacenter.com/blog/unikernels-are-unfit-f...

eyberg · 2 months ago

The majority of nanos users don't do either of these methods. They simply create the image (in the case of aws that's an ami) and boot it. This is part of what makes them vastly more simple than using normal linux vms or containers as you don't have to manage the "orchestration".

eyberg commented on Bubblewrap: A nimble way to prevent agents from accessing your .env files patrickmccanna.net/a-bett... · Posted by u/0o_MrPatrick_o0

eyberg · 2 months ago

https://github.com/containers/bubblewrap/issues/142

eyberg commented on FUSE is All You Need – Giving agents access to anything via filesystems jakobemmerling.de/posts/f... · Posted by u/jakobem

Imustaskforhelp · 2 months ago

I recently had a question about what AI sandboxes use and I think Modal uses gvisor under the hood and I think others use firecracker/generally favour it as well

Firecracker kind of ends up being in the VM categories and I would place gvisor in a similar category too under the VM

So in my opinion, VM's are sandboxes.

Of course there is also libriscv https://github.com/libriscv/libriscv which is a sandbox (The fastest RISC-V sandbox)

There is also https://github.com/Zouuup/landrun Run any Linux process in a secure, unprivileged sandbox using Landlock. Think firejail, but lightweight, user-friendly, and baked into the kernel.

Your mileage may vary but I consider firecracker to be the AI sandbox usually. Othertimes it can be that they abstract on a cloud provider and open up servers in that or similar (I feel E2B does this on top of gcp)

eyberg · 2 months ago

A lot of these "ai sandbox" conversations target code that is already running in a public cloud. Running firecracker doesn't give you magical isolation properties vs running an application in ec2 - it's the same boundary. If you're trying to compare to running multi-tenant workloads in containers on the same vm vs different tenants on different vms - sure that's an improvement but no one said you had to run containers to begin with.

Furthermore, running lots of random 3rd party programs in the same instance, be it a container, or an ec2 vm, or a firecracker vm all have the same issues - it is inherently totally unsafe. If you want to "sandbox" something you need to detail what exactly you are wanting to isolate.

A lot of people might suggest not being able to write to the filesystem, read env vars, or talk over the network but these are table stakes for a lot of the workloads that people want to "isolate" to begin with.

So not only is there this incorrect view that you are isolating anything at all, but I'm not convinced that the most important things, like being able to run arbitrary 3rd party programs, is even being considered.

eyberg commented on FUSE is All You Need – Giving agents access to anything via filesystems jakobemmerling.de/posts/f... · Posted by u/jakobem

akerl_ · 2 months ago

You may just be using a personalized definition of that word, that differs from what it means.

https://en.wikipedia.org/wiki/Sandbox_(computer_security)

Notably, a sandbox exists to separate one thing from other things. Limiting/filtering/monitoring what the sandboxes thing can do are often components of that, but the underlying premise is about separation.

Containers, VMs, etc. are 100% examples of sandboxing based on the actual industry definition of the term.

eyberg · 2 months ago

No they are not. The "industry" totally disagrees with this statement as well.

eyberg commented on Sandboxing Untrusted Python gist.github.com/mavdol/2c... · Posted by u/mavdol04

coppsilgold · 2 months ago

Escaping a properly set up container is a kernel 0day. Due to how large the kernel attack surface is, such 0days are generally believed to exist. Unless you are a high value target, a container sandbox will likely be sufficient for your needs. If cloud service providers discounted this possibility then a 0day could be burned to attack them at scale.

Also, you can use the runsc (gvisor) runtime for docker, if you are careful not to expose vulnerable protocols to the container there will be nothing escaping it with that runtime.

eyberg · 2 months ago

> Escaping a properly set up container is a kernel 0day.

Not it is not. In fact many of the container escapes we see are because of bugs in the container runtimes themselves which can be quite different in their various implementations. CVE-2025-31133 was published 2? months ago and had nothing at all do with the kernel - just like many container escapes don't.

eyberg commented on Toro: Deploy Applications as Unikernels github.com/torokernel/tor... · Posted by u/ignoramous

eikenberry · 2 months ago

I think they were talking more about the degraded performance.

In terms of the security aspects though, how does security holes in a layer that restricts things more than without it degrade security? Seems like saying that CVEs on browser's javascript sandboxing degrade the browser security more than just not having sandboxes.

eyberg · 2 months ago

Duplicating a networking and storage layer on top of existing storage/networking layers that containers, and the orchestrators such as k8s provide, absolutely degrade performance - full stop. No one runs containers raw (w/out an underlying vm) in the cloud - they always exist on top of vms.

The problem with "container" security is that even in this thread many people seem to think that it is a security barrier of some kind when it was never designed to be one. The v8 sandbox was specifically created to deal with sandboxing. It still has issues but at least it was thought about and a lot of engineering went into it. Container runtimes are not exported via the kernel. Unshare is not named 'create_container'. A lot of the container issues we see are runtime issues. There are over a half-dozen different namespaces that are used in different manners that expose hard to understand gotchas. The various container runtimes decide themselves how to deal with these and they have to deal with all the issues in their code when using them. A very common bug that these runtimes get hit by are TOCTOU (time of check to time of use) vulns that get exposed in these runtimes.

Right now there is a conversation about the upcoming change to systemd that runs sshd on vsock by default (you literally have to disable it via kernel cli flag - systemd.ssh_auto=no) - guess what one of the concerns is? Vsock isn't bound to a network namespace. This is not itself a vulnerability but it most definitely is going to get taken advantage in the future.