4 ms·

> Unlike WASI, WALI does not prescribe capability-based security for filesystem and sockets. Instead, the relaxed security model of WALI allows existing APIs (e

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

api 3y ago
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.
- mikewarot 3y ago
  >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.
  - api 3y ago
    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.
    - mikewarot 3y ago
      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.
      - api 3y ago
        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.
Spivak 3y ago
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.
- insanitybit 3y ago
  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.
  - Groxx 3y ago
    >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
nvy 3y ago
>what's the difference between WASM and running native code? Performance, for starters.
striking 3y ago
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?
- sheepscreek 3y ago
  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!!
  - pjmlp 3y ago
    > 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.
  - PH95VuimJjqBqy 3y ago
    I expect OS vendors to start shipping their own WASM infra that allows controlled access to local resources.
    - mikewarot 3y ago
bsder 3y ago
> 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.
- davexunit 3y ago
  Capability security matters at all layers. Our operating systems would be much more secure if they used capabilities instead of ACLs.
  - bsder 3y ago
    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.
    - amluto 3y ago
      > 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.
    - 3y ago
pritambaral 3y ago
This is not a problem on Linux, at least. File system (and network) access can still be restricted using namespaces.
- mikewarot 3y ago
  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.
  - mirashii 3y ago
    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.
- davexunit 3y ago
  Namespaces are a far cry from the capability security model that Wasm uses.
  - pritambaral 3y ago
    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.
titzer 3y ago
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.
- creshal 3y ago
  You're speedrunning repeating every mistake Sun made with JVM sandboxing, congratulations.
  - omnicognate 3y ago
    Can you expand on that? As written it's just a jeer.
  - deleted 3y ago
    [deleted]
  - titzer 3y ago
    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.
- deleted 3y ago

api 3y ago

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.

mikewarot 3y ago
>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.
- api 3y ago
  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.
  - mikewarot 3y ago
    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.
    - api 3y ago
      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.

Spivak 3y ago

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.

insanitybit 3y ago
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.
- Groxx 3y ago
  >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

nvy 3y ago

>what's the difference between WASM and running native code? Performance, for starters.

striking 3y ago

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?

sheepscreek 3y ago
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!!
- pjmlp 3y ago
  > 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.
- PH95VuimJjqBqy 3y ago
  I expect OS vendors to start shipping their own WASM infra that allows controlled access to local resources.
  - mikewarot 3y ago

bsder 3y ago

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

davexunit 3y ago
Capability security matters at all layers. Our operating systems would be much more secure if they used capabilities instead of ACLs.
- bsder 3y ago
  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.
  - amluto 3y ago
    > 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.
  - 3y ago

pritambaral 3y ago

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

mikewarot 3y ago
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.
- mirashii 3y ago
  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.
davexunit 3y ago
Namespaces are a far cry from the capability security model that Wasm uses.
- pritambaral 3y ago
  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.

titzer 3y ago

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.

creshal 3y ago
You're speedrunning repeating every mistake Sun made with JVM sandboxing, congratulations.
- omnicognate 3y ago
  Can you expand on that? As written it's just a jeer.
- deleted 3y ago
  [deleted]
- titzer 3y ago
  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.
deleted 3y ago