5 ms·

I know this may be controversial, but I think injecting a carefully thought out sandboxing layer between application code and the rest of my system is something

I know this may be controversial, but I think injecting a carefully thought out sandboxing layer between application code and the rest of my system is something desktop operating systems been needing for a long time anyway. Its crazy how vulnerable modern operating systems are in the face of malicious code. Literally any of the hundreds of programs running on my computer could steal credentials out of my browser, or read any of my files and send them out over the internet. Or, worse - encrypt all my stuff and ransom it back to me. Why can my text editor read my browser's complete history and credential store? Why does crappy program from Corsair which maps the buttons on my mouse have access to the internet? Why does my operating system allow wacom's driver bundle to silently read, send and ultimately sell lists of what programs I'm running on my computer? So yeah, I agree that the need for WASI is a bit unfortunate. And it'll be a lot of work to get everything working with wasi. And WASI programs will eventually, necessarily pierce WASM's beautiful hermetic shell. But I'm a big supporter of whatever roads lead us to having more control over what access to the rest of the system my applications have. In the long run I can see WASI being part of a much more secure desktop computing environment. We need that - the current situation is ridiculous.

pjmlp 5y ago
Here is a fun exercise, compile a full C application with a dependency in a Heartbleed tainted version of OpenSSL into WebAssembly and then expose it to the Internet, and watch it burn exactly the same way despite whatever magic properties the sandbox offers. Notice the full application part. The castle walls don't matter if one can make the people inside start a fire on their own.
- josephg 5y ago
  I mean, yeah I totally agree with you. Webassembly and sandboxing in general isn’t a silver bullet that will solve every security problem we face. We still need our other languages and other tools, like static analysis and model checking. I see it as a part of defence in depth. Wasm helps prevent RCE attacks and it helps control the blast radius of bad code. Rust and Go help prevent memory corruption bugs like heartbleed happening in the first place. No individual piece will be perfect - but ideally we want a world where no single bug on its own will give attackers the keys to the kingdom. At least, that’s the hope.
  - pjmlp 5y ago
    Fully agree, and that is what irks me with plenty of WebAssembly related content, overselling sandbox model, lack of retrospective on history of computing, and very few content on how penttesting actually goes around diffusing sandboxes. So we get all these startups hyped into how WebAssembly is the silver bullet that will solve all security problems, which is kind of true until one reads all footnotes that come along with the contract.
    - josephg 5y ago
      Ok I hear that; but it sounds like you're enthusiastically reacting to a position I don't hold. Who, exactly, is overselling the wasm sandbox model? What startups are claiming wasm is a silver bullet that will solve all their problems? And I believe they're out there - but just because some wasm proponents are idiots doesn't make webassembly itself without value or without merit. There's young idealistic "true believers" who latch on to any new technology trend. I've never been smart or lucky enough to stop them. People seem to make bad cults on top of all sorts of dubious technology ideas. And I've met plenty - nodejs devs who wanted to rewrite linux in javascript. React devs who thought functional programming was invented by react, and were convinced it was going to change the world. And oh, blockchain people. So many blockchain people. But godspeed - maybe you'll have more luck in your anti-hucksterism crusade than I.
PaulDavisThe1st 5y ago
> Why ... well, as for the why, that's not hard to explain. Your text editor isn't useful unless it can open files. You're saying there are some files it should not be able to open. Which files? Who decides? When is the decision made? Can a user override the decision? Does the not-openable-by-text-editor property propagate to copies? Etc. etc. The main way to solve these problems at present is to remove the file abstraction entirely, so that you can't actually have "a text editor that opens files" at all. All you (or your apps) have is a persistent store in which a totally semantic approach is taken to defining default access patterns (so for example, your "contacts" are of entirely different status to "that thing you created in the little notes app last week". A more or less isomorphic situation applies to internet access, with the major difference that in general this isn't solved on any platform yet (including browsers). In general, the capabilities in a modern general purpose operating system represent a management problem that most regular computer users don't want to have to address, most technical computer users don't want to exist (most of the time), and operating system implementors have so far been unable to solve in a broadly acceptable way. Whether this is justification enough for "hiding" all of this under a WASI-like abstraction that is capable of saying "there are no files" and "there is no internet" at just the right moments ... I don't know.
- josephg 5y ago
  Yeah; that’s a hard UX problem. Obviously my code editor needs access to my source code files. I as a user should decide which files I’m editing and when. But we have plenty of good precedents for this sort of stuff with mobile apps and browser extensions. “This app wants permission to access X because (developer provided reason). Allow?”. As a user I should be able to authorise whatever I want. The goal is that when some random package inevitably goes rogue, the result shouldn’t be a full and complete compromise of my system. My partner’s work laptop recently was sitting at 100% cpu for no reason sometimes. We traced it back to a dodgy chrome extension which was probably mining cryptocurrency. Because the malicious extension didn’t have filesystem permissions, it couldn’t do much more harm than that. I want wasi to help us do the same thing with desktop apps. To me it which fits in the same bucket as openbsd’s pledge (and the Linux equivalents). Wasi could ideally allow fine grained control at a per library level. Eg, I pull a video encoding library into my project but when I load the library I specify which system APIs the module has access to. In this case, it has filesystem access but no internet access. So even if there’s memory bugs in the library or malicious code, it can’t connect to command & control servers or anything like that. And this is exactly what Firefox is starting to do with some of the libraries they use.

pjmlp 5y ago

Here is a fun exercise, compile a full C application with a dependency in a Heartbleed tainted version of OpenSSL into WebAssembly and then expose it to the Internet, and watch it burn exactly the same way despite whatever magic properties the sandbox offers. Notice the full application part. The castle walls don't matter if one can make the people inside start a fire on their own.

josephg 5y ago
I mean, yeah I totally agree with you. Webassembly and sandboxing in general isn’t a silver bullet that will solve every security problem we face. We still need our other languages and other tools, like static analysis and model checking. I see it as a part of defence in depth. Wasm helps prevent RCE attacks and it helps control the blast radius of bad code. Rust and Go help prevent memory corruption bugs like heartbleed happening in the first place. No individual piece will be perfect - but ideally we want a world where no single bug on its own will give attackers the keys to the kingdom. At least, that’s the hope.
- pjmlp 5y ago
  Fully agree, and that is what irks me with plenty of WebAssembly related content, overselling sandbox model, lack of retrospective on history of computing, and very few content on how penttesting actually goes around diffusing sandboxes. So we get all these startups hyped into how WebAssembly is the silver bullet that will solve all security problems, which is kind of true until one reads all footnotes that come along with the contract.
  - josephg 5y ago
    Ok I hear that; but it sounds like you're enthusiastically reacting to a position I don't hold. Who, exactly, is overselling the wasm sandbox model? What startups are claiming wasm is a silver bullet that will solve all their problems? And I believe they're out there - but just because some wasm proponents are idiots doesn't make webassembly itself without value or without merit. There's young idealistic "true believers" who latch on to any new technology trend. I've never been smart or lucky enough to stop them. People seem to make bad cults on top of all sorts of dubious technology ideas. And I've met plenty - nodejs devs who wanted to rewrite linux in javascript. React devs who thought functional programming was invented by react, and were convinced it was going to change the world. And oh, blockchain people. So many blockchain people. But godspeed - maybe you'll have more luck in your anti-hucksterism crusade than I.

PaulDavisThe1st 5y ago

> Why ... well, as for the why, that's not hard to explain. Your text editor isn't useful unless it can open files. You're saying there are some files it should not be able to open. Which files? Who decides? When is the decision made? Can a user override the decision? Does the not-openable-by-text-editor property propagate to copies? Etc. etc. The main way to solve these problems at present is to remove the file abstraction entirely, so that you can't actually have "a text editor that opens files" at all. All you (or your apps) have is a persistent store in which a totally semantic approach is taken to defining default access patterns (so for example, your "contacts" are of entirely different status to "that thing you created in the little notes app last week". A more or less isomorphic situation applies to internet access, with the major difference that in general this isn't solved on any platform yet (including browsers). In general, the capabilities in a modern general purpose operating system represent a management problem that most regular computer users don't want to have to address, most technical computer users don't want to exist (most of the time), and operating system implementors have so far been unable to solve in a broadly acceptable way. Whether this is justification enough for "hiding" all of this under a WASI-like abstraction that is capable of saying "there are no files" and "there is no internet" at just the right moments ... I don't know.

josephg 5y ago
Yeah; that’s a hard UX problem. Obviously my code editor needs access to my source code files. I as a user should decide which files I’m editing and when. But we have plenty of good precedents for this sort of stuff with mobile apps and browser extensions. “This app wants permission to access X because (developer provided reason). Allow?”. As a user I should be able to authorise whatever I want. The goal is that when some random package inevitably goes rogue, the result shouldn’t be a full and complete compromise of my system. My partner’s work laptop recently was sitting at 100% cpu for no reason sometimes. We traced it back to a dodgy chrome extension which was probably mining cryptocurrency. Because the malicious extension didn’t have filesystem permissions, it couldn’t do much more harm than that. I want wasi to help us do the same thing with desktop apps. To me it which fits in the same bucket as openbsd’s pledge (and the Linux equivalents). Wasi could ideally allow fine grained control at a per library level. Eg, I pull a video encoding library into my project but when I load the library I specify which system APIs the module has access to. In this case, it has filesystem access but no internet access. So even if there’s memory bugs in the library or malicious code, it can’t connect to command & control servers or anything like that. And this is exactly what Firefox is starting to do with some of the libraries they use.