Hacker News Reader

Comment by asdfsa32 | Hacker News Reader

This is kind of the wrong approach when linux namespaces exist and rootless namespaces are approach full spectrum.

The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)

That is also why I believe the namespace approach, and by extension Docker-like containerization, is a dead end when it comes to isolation. I hope something like gVisor will win.

This is even more important since agents have turned isolation from a datacenter topic into everyone's concern.

> The Linux kernel is a gigantic attack surface with a ton of legacy stuff most modern applications will never need. Namespaces do not really help with this, but userspace kernels can. (Haven't looked into Ginux enough to know if it does.)

This is incorrect. If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic.

Another new kernel might be 1/6000 the size of Linux and therefore have 1/600 times the exploitable bugs—or none, using formal methods. The question is how much a new user-mode kernel can shield Linux from attacks. Usually the new kernel depends on Linux to separate it from the malicious code!

> Another new kernel might be 1/6000 the size of Linux and therefore have 1/600 times the exploitable bugs—or none, using formal methods. The question is how much a new user-mode kernel can shield Linux from attacks. Usually the new kernel depends on Linux to separate it from the malicious code!

Is there any new language close to rust which can help being verified using formal methods or would some other language be more suitable for this job?

Maybe using verus + rust, it seems that atmosphere[0] is an interesting project in this space

[0]: https://mars-research.github.io/projects/atmo/

Of established languages, Rust, OCaml, F#, and Lean seem to be promising for this kind of thing, but people seem to be vibecoding a lot of new languages right now with this use in mind.

You writing that in response to a vibecoded kernel.

No, I writing that in response to "If you can't trust Linux because it is gigantic, you can't trust a whole another new kernel. Userspace is not blackmagic." The nature of Ginux is irrelevant to that proposition, and, as I think I have clearly shown, it is not well thought out.

The context is not another kernel as an abstract idea here, it is specifically a linux userland kernel. You can't take stuff out of context and make pointless general assertions.

Whether your general assertion was pointless or not, it was false, evidently because you didn't think about which facts about the situation at hand were relevant enough to mention. I'm not convinced that you would have made it to a true statement by doing so, and your efforts in the comments above don't seem to be headed in the direction of a correct thesis, but if you bother to explain what you mean in a coherent way, I'll be happy to engage with that instead.

But I'm not going to try to guess what you wanted to say and then discuss that, because I'll probably guess wrong.

Instead of complaining when people point out that what you said was false, you should thank them for taking the time to correct you and take the opportunity to learn from it. Then, be more careful about what you say next time, so that you say things that are true instead of false.

No, your assertion that you can bolt a userspace kernel on top of an insecure and bloated kernel to make it secure is false. A userspace kernel is just a vm like any other, in fact, a less secure vm at best.

So you should carefully read and consider the conversation before you write, least you come across as arrogant and foolish.

I haven't previously made an "assertion that you can bolt a userspace kernel on top of an insecure and bloated kernel to make it secure", but, as it happens, you can; that's how web browsers execute JavaScript, how Cloudflare Workers run Wasm, and how Firecracker runs virtual machines on Linux, for example.

Whether this works or not—or, more defensibly, how great the risk is—depends a great deal on the details.

I'm not really interested in how I appear to you, so I recommend you don't waste your time telling me about it.

But those are not Linux kernels and have very different memory model, hardware access, and so on and so on.

But I don't think this is a technical conversation anymore, you have some other problems to address and it is best you do that.

In that case, wouldn't it make more sense to build the Linux kernel without those features, or to replace them with sufficient mocks?

You might want to expose more to trusted apps and less to more threatened ones. With kernel shim like gVisor you can have this with little effort.

Ah, good point, thanks!

I’m still fascinated by the approach, though. It seems to me that it sits somewhere between cgroups and virtual machines.

I do wonder what problem it solves, as I don’t think that it provides the same security guarantees that micro-VMs like firecracker do?

It’s the same approach as gVisor. Fairly decent isolation if your application can work on it, but your SOL if a scenario comes up that doesn’t work. VMs give you pretty much 100% Linux compatibility at the expense of density, optimal resource allocation and startup time. gVisor gives you excellent startup time, resource allocation and density at the expense of some app compat and performance at the extremes

Edit: at least with gvisor you get close to a decade of work on compat. gVisor can support some rootless containers scenarios and systemd these days.

I’d be very interested in it if it started to approach VM style isolation without needing KVM access (or qemu).

But I’m not sure if that is really possible.

The use case I’m thinking about is a sandbox exec isolation on an HPC cluster without Docker. I know singularity/apptainer exist, but I’m always looking for something that could make that environment more flexible. It is a tight security environment, so we are always limited in what we can do.

It all becomes a religion to some people. hypervisor escapes are a thing. People always point to Vt-x or AMD-V as having stood the test of time, and that might be true, but the software layer on top certainly hasn’t. Yet you will have “security professionals” tell you that you can’t trust anything beyond a hypervisor. Or they might tell you that a user space kernel is just as secure. They might tell you KVM is a no-go because of bad Type1/Type2 hybrid architecture compared to Xen or HyperV Type1. All have had their fair share of vulnerabilities over the years. All less than Linux process isolation, but still.

I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.

OTOH, running a messy environment with rollback support is much easier with a VM than a container.

Containers are fun for packing messy executables into their own environment and run them now and then, though.

I don’t find VMs to be that much easier to manage (in terms of rollback) than containers. The opposite in fact. VMs are these giant blobs that can be stateful or stateless or a mix of both. While containers have clear separation between the state (stored on volumes or in an external store like a db) and the “application” stored in immutable tags or digests.

Rolling back is easy as long as you understand where the state, if any, is which is actually the hard part of any application. At least with containers you have all of them stored in a well defined registry, while with VMs you would be rolling your own VM snapshot storage system. Not super complicated to do in the grand scheme of things, but it’s another thing you need to get right. But VMs/applications that can rollback would be just as easy (if not easier) to rollback with containers.

>I really like Virtualization to keep things separate, but I never thought of it as an impenetrable wall. For example, I'd not trust an AI agent even inside a VM in my own system.

Remember the submission about how Auto Review is safe? Their standard of safe is that it will take a playwright dependency of another project in your home directory and add playwright based tests to your current project that hasn't declared playwright as a dependency. Amazing.

The issue literally isn't even about a hypothetical security argument anymore. Your sandbox is now a policy that tells the agent what it is allowed to do or not.

> All less than Linux process isolation, but still.

.... Right. Exactly. Everything has some vulnerabilities, but if an attacker has to use a relatively rare VM escape, that's a huge win.

I wonder if this can grow into a capability-based security tool.

Rootless namespaces are getting better, but they don't eliminate the host kernel attack surface

Isn't this also adding a capability sort of like OpenBSD's pledge?

You can combine hypervisors, user space kernels and linux namespaces all into one solution. The attacker will have to escape all of them.

If it has to go through another layer , hopefully without ring0 privs, which more than likely may filter out a number of exploit vectors, how is this the wrong approach ?

Breaking this layer doesn;t automatically give ring0 privs across the hardware.

> Telling someone's research and exploration is wrong...

Never change, HN, never change :D

The project says:

> That research phase is complete.

So not sure what part of it now constitutes "research and exploration".

Reply on news.ycombinator.com