![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
https://josephg.com/blog/node-sandbox/ describes a system of capabilities that sounds good https://news.ycombinator.com/item?id=30988034 discusses. I put here (see next section) b/c the first few comments are useful. They are about dynamism allowing hacking such a capability system, and the solution (in terms of freezing classes into immutability within a defined context).
---
lucacasonato 14 hours ago
| next [–] |
Deno core team member and TC39 delegate here.
We have pondered about capability based security for Deno in the past. Our conclusion has always been that this is not possible to do securely in JS without freezing all prototypes and objects by default. The reasoning for this is that you need to make sure the capability token does not ever leak. For example as a malicious user I could override `globalThis.fetch` to exfiltrate the capability token destined for `fetch` and use it myself later.
One could also override `Map.prototype.set` / `Map.prototype.get` to exfiltrate a token every time it is added or removed from a `Map` (people will want to store tokens in a `Map`).
One could also override `Array.prototype[Symbol.iterator]` to exfiltrate tokens stored in arrays if those arrays are destructored, spread, etc.
There are many more cases like this, where one can exfiltrate tokens because of the very dynamic nature of JavaScript?.
It is unlikely that freezing all intrinsic prototypes and objects is even enough. People will find ways to exfiltrate tokens.
reply
bakkoting 10 hours ago
| parent | next [–] |
o/ Luca! Fellow TC39 delegate here.
> It is unlikely that freezing all intrinsic prototypes and objects is even enough. People will find ways to exfiltrate tokens.
This is probably true, but frozen intrinsics would make it a _lot_ harder. Right now it's not reasonable to ask a library to be defensive against capability exfiltration, since it means not using any built-ins, but I think with frozen intrinsics it would be reasonable to treat a library leaking its capabilities as a security bug. There would still absolutely be leaks - most significantly in libraries which export classes and don't freeze the class prototype - but things would no longer be completely insecure by default. It would make malicious code have to work a _lot_ harder.
I think it's worth a shot. Deno removed the __proto__ getter/setter, and that did require a bunch of libraries to update, but it worked out OK.
Node already has --frozen-intrinsics, if anyone feels like experimenting with whether that would break your code.
reply
lucacasonato 10 hours ago
| root | parent | next [–] |
Yeah, I agree it is definitely worth trying! I think all the talk around SES will push JS as a whole further towards something that could support capability based permissions securely in the future.
reply
3np 13 hours ago
| parent | prev | next [–] |
Doesn't SES address that? The only fundamental barrier right now seems to be performance, which could be addressed by runtime support.
https://github.com/tc39/proposal-ses
https://github.com/endojs/endo
reply
lucacasonato 13 hours ago
| root | parent | next [–] |
Yup, SES would address this. But SES also needs to bring with it a paradigm shift for JS:
a) Folks would have to load each bit of code they want separate permissions for in a separate compartment. This won't be easy. b) Runtimes will need to provide an immutable global realm, which is not something that is the case right now.
As I said in a different commeent, I think a lot of this can already be addressed by ShadowRealms?. Deno will likely allow users to specify per ShadowRealm? permissions, which is probably as granular as most people will want to get.
reply
zozbot234 13 hours ago
| parent | prev | next [–] |
These seem like features that could work a bit better in the context of WASM modules and/or components. AIUI, WASM was designed with the expectation that support for capabilities would be required.
reply
lucacasonato 13 hours ago
| root | parent | next [–] |
Yup, for sure. I think capability based ShadowRealms? are also totally doable. I'm sure we'll add those for Deno once we add support for ShadowRealms?.
reply
-- https://news.ycombinator.com/item?id=30988034
https://github.com/tc39/proposal-ses
---
