Comments URL: https://news.ycombinator.com/item?id=49267550

Points: 13

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49252849

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49201059

Points: 4

# Comments: 0

As for orchestration - a lot of folks think you need a completely new orchestration system for dealing with vms but we just simply re-use the existing infrastructure that already exists - the public clouds. Those companies have tens of thousands of engineers that are much better than the average engineer at this stuff, custom hardware, custom protocols and close to several decades of existing deployment.

I can build and ship a vm from my laptop/ci to prod on AWS/GCP in ~tens of second. Granted I come from the camp that thinks deploying full blown general purpose operating systems to prod is an increasingly incredibly risky practice.

Comments URL: https://news.ycombinator.com/item?id=48720684

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48186370

Points: 22

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=47699396

Points: 20

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=46859291

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46769301

Points: 2

# Comments: 0

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.

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.

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.

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.