Stop Hiding the Sharp Knives: The WebAssembly Linux Interface | Hacker News Reader

Stop Hiding the Sharp Knives: The WebAssembly Linux Interface

arxiv.org

98 pointsyurivish57 comments

> Unlike WASI, WALI does not prescribe capability-based security for filesystem and sockets. Instead, the relaxed security model of WALI allows existing APIs (e.g. WASI) to be implemented over it (Fig. 6).

Oh no.... I was worried someone was going to do this. You might as well skip WASM altogether if you start down that road.

If you give away file system access by default, what's the difference between WASM and running native code? The key advantage of WASM is the capability based security model. This throws that away.

Nothing which I think is the point for people that wanna run WASM on their servers and reap the benefits like it was Python/Ruby/Java.

What benefits? If you're doing backend work and you want "Wasm but without the sandbox" you can just compile a native binary, which will be faster anyways.

>What benefits?

WASM can improve the security of running untrusted code[citation to a doc from 2022]. This review cycle, [user] released bugfixes and improvements to move all code execution to WASM, improving security.

> Reviewer notes:

  [X] approved for promotion
  [Y] heckin massive win, #promofrfr
  [Z] low cyclomatic score on diffs, -1
  [Q] all diffs contain less than 12 bytes of changes, easy to review. 0x10 engineer #doublepromotion

>what's the difference between WASM and running native code?

Performance, for starters.

It means you can port existing native apps to WASM more easily. You could use the WALI layer to narrow down your syscalls and what they're allowed to do in a gradual way, without having to write your own WASM engine from scratch. The way they phrase it is, they're "decoupling feature completeness from the security model and pushing API implementations outside the trusted computing base (TCB) of the engine", and I think that's a reasonable approach given that there are other reasons to port to WASM (independence from processor architecture, lightweight in-memory sandboxing esp. of potentially untrusted code, restrictions on the way control flow can be manipulated, etc.)

WASI is what provides the capability-based security model, WASM is just a binary format. Nothing wrong with having a different way of interpreting WASM, is there?

I am starting to think of WASM as an ambitious language agnostic VM and ecosystem.

It is like the JVM standard - but for any language. And as the runtimes exist for most platforms, anything compiled to WASM is automatically cross-platform.

Also, it is designed for better security (to run inside a browser sandbox). No GC by default but that may change with WasmGC. You can use it with Docker using the WASM backend.

Who knows, maybe one day all operating systems will have native WASN support. Then it will truly become the ubiquitous/universal binary format!!

> It is like the JVM standard - but for any language.

Just like CLR in 2001, or TIMI in 1988, among several others, then again learning about history of computing isn't a strong concern in our field.

I expect OS vendors to start shipping their own WASM infra that allows controlled access to local resources.

At which point, WASM becomes worthless as a secure environment in which to run portable code downloaded at random from the internet.

oh yeah, hey gais, if you could use the native gui tookit suddenly it being in a sandbox is worthless!

stop with the hyperbole.

> The key advantage of WASM is the capability based security model.

Which is also the key irritant of any useful application of WASM.

All the "wrapper" bullshit exists because "security" prevents you from accessing the DOM, JS objects, sockets, the file system, etc. Accessing this kind of stuff has been inevitable but the people who propound WASM have been dragging their feet on this forever.

If you're not doing web, you don't give one iota of damn about WASM "security". For example, if I'm bootstrapping my compiler, everything already has complete access and your "security" is both useless and in the way.

Capability security matters at all layers. Our operating systems would be much more secure if they used capabilities instead of ACLs.

Sadly, nobody cares.

Capability-based OSs wind up being significantly slower and very irritating to use.

For example, look at all the pissing and moaning about SELinux.

We shall see if Fuschia and/or WASM can buck the trend.

> Capability-based OSs wind up being significantly slower and very irritating to use.

> For example, look at all the pissing and moaning about SELinux.

SELinux is not a “Capability-based OS.” It’s giant step in a direction that is pretty much opposite to capabilities.

Seriously, try basically anything on Linux that tries to delegate one’s authority to something less privileged (e.g. basically any container runtime). Bind-mount something in, and then watch the kernel grumble about SELinux failures originating inside the container, where the runtime would have appropriate permission but the container processes are labeled differently and don’t.

This happens because SELinux is not capabilities; it’s a very complicated and difficult to configure MAC system, which is pretty much at the opposite end of the spectrum.

Podman and friends have IMO horrible workarounds built in.

SELinux isn't Capability Based Security

The closest you've likely ever been to capabilities is cash in a wallet. Each banknote is a capability, and you chose from those capabilities, in a secure and transparent manner at the time of transaction.

SELinux, by analogy, requires your BANKER to decide what bills you're allowed to use in advance.

SELinux sucks, and was likely a diversion to keep people away from capability based security. (As are the permission flags on your smartphone, etc)

Capability security is great, but it isn't native to the Linux kernel. It must be implemented on top. WALI allows that capability security model to be implemented in a Wasm module, rather than built into the Wasm engine. Thus a bug in the implementation of that isn't an engine-level exploit, but is sandboxed as any other Wasm module would be.

Then I think you are completely missing the point of why WASI was created.

This is not a problem on Linux, at least. File system (and network) access can still be restricted using namespaces.

That's only true if there are no bugs in the kernel or anything that implements the namespaces. You're needlessly adding a huge attack surface.

Devil's advocate, using WASI assume there are no bugs in the new specifications or anything that implements those specifications. We already have a variety of tools to sandbox processes, by implementing and adopting WASI, you're needlessly adding a huge attack surface.

Namespaces are a far cry from the capability security model that Wasm uses.

Yes, and Wasm's capability based security model makes sense for adding plugins to your app. But TFA is intended for running entire apps, so I think letting the user of the app control fs and network access via the already widely supported and proven method of CGroups and namespaces is a much better option than whatever method each individual app comes up with.

This is the most common misconception of our work. Please read the paper. WALI doesn't have to be exposed directly to programs, but can be used to implement a more restrictive sandbox as a Wasm module a layer above. For example, WASI can be implemented as a Wasm module and then other Wasm modules can only use the WASI module. Then any bugs or vulnerabilities in the WASI implementation are not engine-level exploits, but are sandboxed as any other Wasm module.

This is a layering and security win across the board and does nothing to reduce the possibilities for more restrictive environments and APIs built on top.

We're fans of WASI and see it as a the future of portable APIs. But it's a distant future, and WALI actually helps get us there and get more adoption for WASI by making it possible to implement WASI independent of the engine.

You're speedrunning repeating every mistake Sun made with JVM sandboxing, congratulations.

Can you expand on that? As written it's just a jeer.

This is a super unhelpful comment, but I'll respond. I worked on several JVM projects going back almost 20 years. No, we aren't. One principal sin the JVM made is that the JDK initially had no modular structure, and everything it needed to do natively was done in the JVM with native methods, because it had to be; the JVM was the only system with the privileges to do syscalls. As a result, the JDK was only really complete on about 2 VMs. With WALI, syscalls and all logic to implement higher-level APIs moves up, out of the engine. Engines can be complete and run an entire stack with no special support.

If you could resist the urge for snarky, dismissive comments we could have a more productive discussion.

>Please read the paper.

I quoted your paper.

I'll take you at your word. I'd be quite happy to have a native Linux WASM / WASI host that's easy to configure and verify the configuration of.

It should be as easy as picking a $5 bill from a wallet, to use in a transaction. You can see what you're doing... and examine it after it's out of your wallet, to double check. If you can see exactly what the command line you give it will hand out to the WASM code, and verify it for someone else's command line (before you actually run it)... that would be awesome.

  WALI xxx - to actually run it
  WALI --showcaps  xxx - to get an output of the files, folders, network addresses, etc. it would allow access to, as a text list

If WALI gets exposed directly to the WASM code, then the benefits of WASM are lost, in my opinion.

Capability based security would be nice, but nobody is going to use it because it requires all software to be at least partly rewritten.

If we could introduce these kinds of fundamental improvements at the base layer of OSes we would not need containers, orchestrators, or virtual machines. We could just fix the OS to have all the necessary controls, fault tolerance, and other abstractions and “do it right.”

There was a serious effort to do this in the 90s with things like Plan 9, the JVM, and Mosix among other things. Its all dead.

Containers, VMs, overlays, orchestrators, etc are all hacks because we are permanently stuck with 1970s OS paradigms due to sunk cost.

Edit: forgot to mention async programming and/or green threads like goroutines. Those are a massively complex and costly hack to get around the fact that both OS concurrency APIs and OS I/O APIs are 1970s relics. You should just be able to spawn threads and you should have native zero copy event driven I/O, but again we can’t fix the foundation.

>Capability based security would be nice, but nobody is going to use it because it requires all software to be at least partly rewritten.

I can just imagine someone in 1910 saying "Circuit Breakers in Houses would be nice, but nobody is going to use them because they require all houses to be at least partly rewired".

Capability based security is the main feature of WASM. Going around it is like putting pennies in a fuse box, or wiring around circuit breakers. The circuit breaker prevents a load from consuming all available electrical resources (burning down the house as a side effect). Capability based security does the same thing for ensuring code doesn't have unlimited side effects.

If you need to run native code, just do so. Don't sabotage the only decent chance at finally fixing computer security since Multics to do so. Almost every consumer installable electrical load out there can plug into an outlet. The big heavy loads require an electrician to install them. If your code is the equivalent of an industrial load, you shouldn't be trying to cram it into WASM, the equivalent of a 15 amp 110 GFI circuit.

If rewiring houses cost millions or billions of dollars, we still wouldn't have circuit breakers.

The problem is that we have what probably amounts to tens of trillions of dollars of sunk cost in software systems built on 1970s paradigm OSes, and updating all that software for a different paradigm isn't feasible.

We also have probably tens of billions of dollars worth of sunk cost in developer education teaching developers to write software for current systems.

I hate to be such a cynical bastard, but one thing I have learned after 20+ years in this profession is that it will not be fixed. The OS paradigms of the 70s are etched in solid stone. We will put it in a box (VM) inside a box inside a box inside a box inside a box instead.

I don't like it either. You're hearing frustration. But I think it's true. Once a system is widely deployed and a lot of other things are built on it, it is eternal.

I do hold out a small amount of hope that a few more generations of coding AI development might yield AIs good enough to rewrite software. Give it a code base and tell it to rewrite it in language X running on OS API Y without sacrificing any functionality.

That might be a way out since the trap comes from the fact that software written manually by humans is expensive. Geometrically reducing the cost of that kind of refactoring could change the economics.

Mea culpa

I read the first part of your comment, and was too quick to reply. I share your frustrations. For Windows GUI applications, there really shouldn't be much work replacing file selection dialogs with calls to a powerbox that returns a capability. I'm not sure how hard it is to do the same thing in Linux GUI land.

It's the command line programs that are the most grief. Since we don't have any notion of standard parameters for filenames, paths, etc... it'll be most of the work reworking those away from files and ambient authority.

The thing that makes me cynical about any notion of fixing the foundation is just how much software there is. The long tail is long.

It’s actually hard for a person to wrap their heads around the true size of all these ecosystems that ride on top of every OS and platform.

All that software assumes a rather hacky coarse grained 70s security model and it assumes that all those syscalls and libraries work.

The best analogy I can think of isn’t repairing the foundation of a house, or even moving a house to a new foundation. It’s more like repairing the structural elements of an aircraft in flight, except there isn’t even a concept of landing. The plane is in the air for eternity and is constantly mid air refueled.

It’s like that. Everything must work, everything is always behind schedule, nothing can ever stop.

> If you need to run native code, just do so.

Please read the paper; WALI already improves on running native code by being portable and having CFI built in.

> Don't sabotage the only decent chance at finally fixing computer security since Multics to do so.

Wasm has never been about fighting holy wars; I don't think it's productive to ruminate on obliterating all software that doesn't fit one's personal conception of how things should work, no matter how justified it may seem from the inside.

Core Wasm has always been a portable abstraction over hardware; a low-level, but sandboxable bytecode ISA as a compilation target. It's so useful because it's completely separate from the APIs you give Wasm code. It can be embedded into almost any environment by offering an API.

> Capability based security is the main feature of WASM.

The APIs that are exposed to a Wasm can be capability-based or not. It is not inherent to Wasm. The Web APIs are generally not--there are too many ways to circumvent any possible user-level access restrictions in JavaScript. Effectively, the entire JS API surface is available to a Wasm module. That's a property of the Web.

But it's never "game over" for a Wasm module to suddenly get access to the whole world.

What makes Wasm great is that the embedding environment gets to decide how to bind a module's requested bindings to actual bindings, even in an embedding with "dangerous" capabilities. The embedder can decide to interpose, emulate, or otherwise attenuate a module's requested imports, by deciding how to bind to actual implementations. In the case of WALI, because imports are statically named by the module, and bindings are supplied based on those names (rather than by dynamic syscall number), we can statically inspect modules and reject ones that request blacklisted syscalls (or make them nops or whatever you like). You're pretending like a module using one WALI syscall immediately means game over. That's just binary thinking.

Incidentally, there is nothing inherent about WASI that says that the file system has to be sandboxed and capability-based; it's only a convention, which of course can be circumvented by pre-opening the root directory, the proc filesystem, etc--i.e. it's always subject to operator error the embedder level. The embedder decides to do with API bindings; always has, always will.

Besides, this is a first step, a proof of concept.

Of course you wouldn't expose raw, unfiltered WALI calls to untrusted code. (Of course you wouldn't expose WALI to the Web, requiring all Web browsers to emulate Linux.) If you have untrusted code, you still only supply WALI functionality consistent with the capabilities you want it to have, sandboxing any module by limiting, interposing, or blacklisting WALI calls, or building a separate API like WASI on top of WALI and only exposing that. And you can further sandbox the engine itself using techniques for sandboxing processes.

This completely kills all of my excitement for WASM, because it is clear that WALI, or something conceptually close to it, will definitely prevail over the capability-based alternatives, simply because people love compiling their existing programs for new platforms so much, throwing out the advantages brought about by their differences in exchange for sweet, sweet convenience. It doesn't matter that entire layers of indirection, accumulated over literal decades, could be torn away and consigned to the grave, as long as Joe Sixpack can compile ffmpeg on WASM without lifting a finger. I'm not buying that WALI is just going to be a stepping stone for a more restrictive platform. The mere existence of an anything-goes-screw-safety runtime environment will precipitate a worse-is-better avalanche of ported software, completely drowning out any interest in an improved development target, and there's simply nothing anyone could fathomably do about it.

I would really love being able to take any POSIX command line tool, compile that to WASI, and run it on (at least) Linux, Windows and macOS like a regular executable without having to install a separate WASI runtime or any scare-popups showing up like on macOS.

I'm a 'WASI convert' since I was able to take an ancient 8-bit assembler written in C89 in the mid-90's (http://xi6.com/projects/asmx/), compile that as-is with the WASI SDK (https://github.com/WebAssembly/wasi-sdk), and then integrate it into a VSCode extension (https://marketplace.visualstudio.com/items?itemName=floooh.v...).

A similar problem I'd like to solve better is a shader cross-compiler (https://github.com/floooh/sokol-tools) which needs to run on Linux, macOS and Windows and takes too long to build locally, thus I currently need to distribute that as pre-built binaries. Compiling this to WASI works, but the filesystem access restrictions built into current WASM runtimes are a bit of a hassle to manage, and a WASM runtime needs to be installed, which is also an additional step which shouldn't be needed.

Everything feels like it's going the way of modern USB. One universal standard that you're never sure is going to be compatible with anything you try and use it with or for.

I love seeing this.

The more work we do on top of WASI the more I realize their design flaws when trying to run already existing programs on top of it. WASIX aims to fix many of these flaws, but the underlying problems from WASI always arises (such as mandatory relative paths).

I welcome WALI with open hands and excitement. If anyone wants to add support for it in Wasmer I’d be more than happy to integrate it there!

For those interested, as is not trivial to find it, the source code of WALI is here: https://github.com/arjunr2/WALI

It’s not clear to me how this is especially novel. Why is it a paper and not just like a GitHub repo or something?

Papers are for resumes and funding. Novelty is something the journal or investor could define and require, if they wanted it.

I really think we should have means of spawning wasm components from wasm components. How the runtime runs them should be up to the runtime - it could be directly backed by kernel primitives but it could also be in a browser. Leaking posix things into wasm… is something I'd rather never want to see. Let's come up with something better as wasm did aim for from the start.

Websites are at least supposedly are sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse though as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing, while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser.

But this isn't for the browser though. The idea here is to use WASM kinda like Java. You can run the same binary on different systems.

Ahh, thanks for explaining this. At first I was like "what, WASM is already portable, why have a Linux specific thing" and then you answered my question.

Right, we weren't envisioning that browsers would be required to implement WALI or expose it. That would probably be a bad idea. :)

Essentially no new sandbox capabilities are being added for wasm in the browser compared to JavaScript and that's not changing anytime soon.

This shiny new stuff is about wasm for security reasons on desktop, embedded/IOT, Cloud server stuff instead of native binaries.

One nice thing about WebAssembly is that it can run in a browser. How would you implement things like fork() in that context, given the inability to manipulate the stack?

Web workers? [0]

[0] https://emscripten.org/docs/api_reference/wasm_workers.html

In WASIX we fully solved that, so is definitely doable to run fork on the browser.

Although I'm extremely curious the WALI fork strategy would work in the browser. Maybe the creators can chime in here?

Could you elaborate on how you solved the issue? A link to the relevant code would be nice.

Sure thing: https://github.com/wasix-org/wasix-libc/blob/main/libc-top-h...

The C function you linked calls _Fork, which calls __wasi_proc_fork, which calls __imported_wasix_32v1_proc_fork, which is the 'proc_fork' import in the 'wasix_32v1' module. The question is, what JavaScript function is provided for this proc_fork import when instantiating a WebAssembly module using WASIX? From what I understand about the WebAssembly JavaScript API, such a function is impossible to implement, which is why I'm curious how it was done here.

fork in the browser is functionally impossible unless you mean some sort of 'damaged fork' where only the native wasm heap is mirrored and not everything else, which would be effectively useless.

I feel like we’re having our xkcd competing standards moment for WebAssembly outside the browser.

There is WASI (preview1 and preview2 with components), WASIX, and now WALI proposed here.

I sort of wish that these could be new additions to proposals/extensions to WASI instead of separate standards

There's a paragraph with the heading "The Need for a Complete Wasm OS Interface" in the introduction that breaks down the differences.

This is not a competing standard, it's a complementary, lower-level interface that can be used to implement (and sandbox) the WASI implementation. It's defense-in-depth and layering: WASI moves up a layer, and not every engine needs to implement it independently, as it can be a Wasm module that runs on any engine.

Reply on news.ycombinator.com