eyberg

So first off - NVD has been sliding for a long time now. This has nothing to do with mythos. The amount of money that goes into this program for the output is straight up criminal.

For a very long time the security world has basically given up on defense and relies on prioritizing cves. This is wrong on so many different levels.

a) You can't scan for things you don't know that exist.

b) Malware, like all the supply chain issues in the past few months don't have cves to begin with but they are still massive security issues. That is to say the cves themselves don't really address everything. So you end up with IOCs but those are also totally worthless if it's the first time you are seeing something. You have to have proactive defense if you actually care.

c) There are quite a few cwes that you can outright prevent through various defensive means but for whatever reason organizations won't. This is an organizational issue - not a technical one. This might be one of the main benefits of the cve program in that it starts to penalize organizations through insurance and other means by tracking it and this is exactly how a lot of the security world operates.

I'm cautiously optimistic that the world is going to start looking at stronger proactive defensive measures rather than relying on this reactive scanning approach.

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.

Except this is very clearly running linux.

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".

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

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.

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

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.

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.

A shell by design is explicitly made to run other programs. You type in 'ls', 'cd', 'cat', etc. but those are all different programs. A "webshell" can work to a degree as you could potentially upload files, cat files, write to files, etc. but you aren't running other programs under these conditions - that'd be code you're executing - scripting languages make this vastly easier than compiled ones. It's a lot more than just slapping a heavy-handed seccomp profile on your app.

Also merging the address space is not a necessity. In fact - 64-bit (which is essentially all modern cloud software) mandates virtual memory to begin with and many unikernel projects support elf loading.

We don't enable that exec-protect feature on by default explicitly for this reason. You are right - jit needs it.

Let's see last month (November 2025) we had CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881 alone. Container breakouts happen almost monthly.

I can't speak for all the various projects but imo these aren't made for bare metal - if you want true bare metal (metal you can physically touch) use linux.

One of the things that might not be so apparent is that when you deploy these to something like AWS all the users/process mgmt/etc. gets shifted up and out of the instance you control and put into the cloud layer - I feel that would be hard to do with physical boxen cause it becomes a slippery slope of having certain operations (such as updates) needing auth for instance.

To be clear there are still numerous attacks one might lob at you. For instance you if you are running a node app and the attacker uploads a new js file that they can have the interpreter execute that's still an issue. However, you won't be able to start running random programs like curling down some cryptominer or something - it'd all need to be contained within that code.

What becomes harder is if you have a binary that forces you to rewrite the program in memory as you suggest. That's where classic page protections come into play such as not exec'ing rodata, not writing to txt, not exec'ing heap/stack, etc. Just to note that not all unikernel projects have this and even if they do it might be trivial to turn them off. The kernel I'm involved with (Nanos) has other features such as 'exec protection' which prevents that app from exec-mapping anything not already explicitly mapped exec.

Running arbitrary programs, which is what a lot of exploit payloads try to achieve, is pretty different than having to stuff whatever they want to run inside the payload itself. For example if you look at most malware it's not just one program that gets ran - it's like 30. Droppers exist solely to load third party programs on compromised systems.

Containers got popular at at time when there were an increasingly number of people that were finding it hard to install software on their system locally - especially if you were, for instance, having to juggle multiple versions of ruby or multiple versions of python and those linked to various major versions of c libraries.

Unfortunately containers have always had an absolutely horrendous security story and they degrade performance by quite a lot.

The hypervisor is not going away anytime soon - it is what the entire public cloud is built on.

While you are correct that containers do add more layers - unikernels go the opposite direction and actively remove those layers. Also, imo the "attack surface" is by far the smallest security benefit - other architectural concepts such as the complete lack of an interactive userland is far more beneficial when you consider what an attacker actually wants to do after landing on your box. (eg: run their software)

When you deploy to AWS you have two layers of linux - one that AWS runs and one that you run - but you don't really need that second layer and you can have much faster/safer software without it.

a) containers don't contain

b) if you want to limit your hosting environment to only the language/program you expect to run you should provision with unikernels which enforce it

It's confusing but CVE-2025-55184 was released today (not the ones last week). CVE-2025-67779 is an update to that one.

No it is not.

The same podman that had three new CVE breakouts not even two weeks ago?

Containers do not contain.

Prisma is actually not running that kernel and many of these other workloads are also not running that kernel.

Trivial to spin up a prisma postgres instance and see everything from busybox to a full blown proc including very specific linux flags.

They should clarify which workloads are actually using their kernel vs linux. I suspect most are the latter.

We (NanoVMs) can run (both unikernel and normal linux) virtualized workloads on plain old ec2 instances (eg: t2.small).

There are a few ways to approach this. If you don't mind owning the orchestration layer this is precisely what firecracker does.

If you don't even want to pay for that though scheduling unikernels on something like ec2 gets you your full vm, is cheaper, has more resources than lambda and doesn't have the various limitations such as no gpu or timeouts or anything like that.

I would kinda disagree with this. The whole 'better than nothing' is what gave a huge chunk of people a false sense of security wrt containers to begin with. The reality is that there is no singular create_container(2). Much of the 'security' is left up to the runtime of choice and the various flags they choose or don't choose to enable. Others in this thread have already mentioned both bubblewrap and podman. The fact that the underlying functionality is exposed very differently through different 'runtimes' with numerous optional flags and such is what leads to all sorts of issues because there simply was no thought to designing these things with security in mind. (We just saw CVE-2025-9074 last week). This is very different than something like the v8 sandbox or gvisor which was designed with certain properties.

Bubblewrap has refused to fix known security issues in its codebase and shouldn't be used.

Containers should not be used as a security mechanism.

This is kind of a stupid "benchmark" but if we're going to walk down this road:

linux: elapsed: 0.019895s

nanos (running on said linux): elapsed: 0.000886s

Packages exist: https://repo.ops.city

Mounts also exist - in fact you can hotplug volumes on the fly on all the major clouds. People really like this cause they can do things like rotate ssl certs every few hours.

The file system exists - at the very least you need to load a program that sits on the filesystem but people are running webservers that write to temp files and load static assets and also databases.

I'm not sure what your comment means? What infrastructure? I just broke apart each of those into examples of how people use them today.

Access Control: There is none internally. We don't have the notion of users.

Logging: Keep using whatever you want be it elasticsearch, syslog, cloudwatch, etc. No opinions here.

Debugging: GDB works fine and in many cases since you can simply export the vm in it's entirety and then attach to it locally this becomes even easier to debug than the same application running on linux.

Profiling: We support things like ftrace and of course things like prometheus you can export.

Monitoring: Kinda in the same boat as logging - keep using whatever you are using today - datadog, victoria metrics, etc.

Throttling: This is traditionally an app-level concern that someone would implement at perhaps a load balancing layer - keep using whatever you are using.

Backup/Recovery: Running unikernels make it trivial to backup as you can clone running vms. In fact most cloud deploys involve making a snapshot that is already stored as a 'backup' and makes things like rollback much easier to do.

You can also run the full JVM and in fact I'd imagine that's how most of our JVM users actually use it today.