4 ms·

It's a way of running WASM code, which can be anything from anywhere, safely. It only gets access to the folders you let it access as a capability. It gets no a

It's a way of running WASM code, which can be anything from anywhere, safely. It only gets access to the folders you let it access as a capability. It gets no access to anything else. So, no matter how evil, or confused, the program is, you aren't risking your entire system. It's the best part of capability based security.

VyseofArcadia 4y ago
A bit like OpenBSD's pledge[0]. Seems a bit of a waste to need a whole runtime for something the OS could provide. [0] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2
- mtkhaos 4y ago
  Missing interoperability between web/server. It's moving away from the OS model into something more pure
- VWWHFSfQ 4y ago
  Operating systems on are becoming increasingly irrelevant.
  - pstuart 4y ago
    It'll be serverless all the way down...
    - paulryanrogers 4y ago
      Until you get to the atoms
      - jabl 4y ago
        And then turtles. After that it's turtles all the way down.
  - encryptluks2 4y ago
    Lol.. sure, and you must run your computer on a unikernel then I take it?
pjmlp 4y ago
Basically Java Security Manager for App Servers rebranded for a new generation.
- hinkley 4y ago
  Java Security Manager has a rich history of leaking capabilities to code that should not have them. As has practically every capability-based system ever. Capabilities are no Silver Bullet. They work exceptionally well with small teams, but like memory leaks, reachability decisions tend not to scale to very large teams, and people start exposing information for a feature without being able to trace the consequences of having done so. I could potentially see someone recasting this story as a parable against shared state, but I'm not convinced it's the sole cause or that you could have one without the other. I think it is true that they share a problem space, but that's neither a particularly brave nor illuminating statement.
  - anderspitman 4y ago
    Do you have a favorite alternative to the capability model that you feel is superior? I somewhat casually follow these discussions and I'm always looking for new ideas (or old ones that actually work better in some cases).
    - hinkley 4y ago
      The weird thing about the security APIs in Java is that it contained both capabilities and an ACL model with a sort of hierarchy to it, both of inheritance and being able to run a function in a scope. I got to use it for real on a project and if you overlooked the extreme clunkiness of trying to capture a set of rights as configuration, it wasn't that bad. So I could say, do that again but with a better way to define rules programatically instead of a priori. Multi-tenant, multiple roles, or a Cartesian product of the two sort of demand a little bit of bespoke rules engine work.
- amelius 4y ago
  Except Java has support for shared memory between threads, whereas WASM is single-threaded with message passing. Don't expect e.g. to implement a high-performance multi-threaded database in WASM anytime soon.
imhoguy 4y ago
"Write once run anywere" heard that many times. No sandbox is going to give you safety. Spectre and Meltdown are great examples of that. It is the matter of time and popularity. Cryptojacking and malware is already the problem[0]. [0] https://software-lab.org/publications/sp2022.pdf https://software-lab.org/publications/sp2022.pdf
xeonmc 4y ago
Could this potentially be integrated as an extensible platform for moddable gamelogic, like Quake did with their .qvm bytecode Quake-Virtual-Machines?
- sethaurus 4y ago
  Embeddable plugin systems are absolutely a goal! See this part of the blog post: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready#3rd-party-plugin-systems https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...
saagarjha 4y ago
This is an advertisement, not an answer. Wasmtime is a way of running WASM bytecode, which is a little virtual machine (of the Java, rather than QEMU, type). You can run your WASM code on it and because it runs in the runtime you can, at least in theory, sandbox it by controlling what it has access to. If your runtime and the computer it is running on is perfect (which happens to be an unsolved problem, sadly) then you can run anything inside of the runtime and it can only do what you give it access to. In practice the runtime is not perfect and bugs will let very malicious code escape, but overall the security of running things in such a runtime is usually much better than doing so directly, at the cost of some performance.

VyseofArcadia 4y ago

A bit like OpenBSD's pledge[0]. Seems a bit of a waste to need a whole runtime for something the OS could provide. [0] https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2

mtkhaos 4y ago
Missing interoperability between web/server. It's moving away from the OS model into something more pure
VWWHFSfQ 4y ago
Operating systems on are becoming increasingly irrelevant.
- pstuart 4y ago
  It'll be serverless all the way down...
  - paulryanrogers 4y ago
    Until you get to the atoms
    - jabl 4y ago
      And then turtles. After that it's turtles all the way down.
- encryptluks2 4y ago
  Lol.. sure, and you must run your computer on a unikernel then I take it?

pjmlp 4y ago

Basically Java Security Manager for App Servers rebranded for a new generation.

hinkley 4y ago
Java Security Manager has a rich history of leaking capabilities to code that should not have them. As has practically every capability-based system ever. Capabilities are no Silver Bullet. They work exceptionally well with small teams, but like memory leaks, reachability decisions tend not to scale to very large teams, and people start exposing information for a feature without being able to trace the consequences of having done so. I could potentially see someone recasting this story as a parable against shared state, but I'm not convinced it's the sole cause or that you could have one without the other. I think it is true that they share a problem space, but that's neither a particularly brave nor illuminating statement.
- anderspitman 4y ago
  Do you have a favorite alternative to the capability model that you feel is superior? I somewhat casually follow these discussions and I'm always looking for new ideas (or old ones that actually work better in some cases).
  - hinkley 4y ago
    The weird thing about the security APIs in Java is that it contained both capabilities and an ACL model with a sort of hierarchy to it, both of inheritance and being able to run a function in a scope. I got to use it for real on a project and if you overlooked the extreme clunkiness of trying to capture a set of rights as configuration, it wasn't that bad. So I could say, do that again but with a better way to define rules programatically instead of a priori. Multi-tenant, multiple roles, or a Cartesian product of the two sort of demand a little bit of bespoke rules engine work.
amelius 4y ago
Except Java has support for shared memory between threads, whereas WASM is single-threaded with message passing. Don't expect e.g. to implement a high-performance multi-threaded database in WASM anytime soon.

imhoguy 4y ago

"Write once run anywere" heard that many times. No sandbox is going to give you safety. Spectre and Meltdown are great examples of that. It is the matter of time and popularity. Cryptojacking and malware is already the problem[0]. [0] https://software-lab.org/publications/sp2022.pdf https://software-lab.org/publications/sp2022.pdf

xeonmc 4y ago

Could this potentially be integrated as an extensible platform for moddable gamelogic, like Quake did with their .qvm bytecode Quake-Virtual-Machines?

sethaurus 4y ago
Embeddable plugin systems are absolutely a goal! See this part of the blog post: https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready#3rd-party-plugin-systems https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe...

saagarjha 4y ago

This is an advertisement, not an answer. Wasmtime is a way of running WASM bytecode, which is a little virtual machine (of the Java, rather than QEMU, type). You can run your WASM code on it and because it runs in the runtime you can, at least in theory, sandbox it by controlling what it has access to. If your runtime and the computer it is running on is perfect (which happens to be an unsolved problem, sadly) then you can run anything inside of the runtime and it can only do what you give it access to. In practice the runtime is not perfect and bugs will let very malicious code escape, but overall the security of running things in such a runtime is usually much better than doing so directly, at the cost of some performance.