5 ms·

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

by 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.
- titzer 3y ago
  > 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.

by api 3y ago

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