4 ms·

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/

by 3np 5y ago

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/tc39/proposal-ses https://github.com/endojs/endo https://github.com/endojs/endo

lucacasonato 5y ago
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.
- naugtur 5y ago
  There's Endo, which does the loading/importing and dependency resolution. It doesn't have a default user experience at this point, but it creates compartments for packages and runs. Getting permissions involved will require mapping them to packages in a policy file and there you go - an environment where you can use packages and they can't surprise you with data exfiltration etc.
- naugtur 5y ago
  Also, what's shadow realms? I tried looking it up and got a video game. And I'm not much of a gamer so it's not a matter if a bubble ;)
  - robotnikman 5y ago
    I think they might be talking about this https://github.com/tc39/proposal-shadowrealm https://github.com/tc39/proposal-shadowrealm ShadowRealm is possibly a reference to the Shadow Realm from the card game Yu-Gi-Oh
- danfinlay 5y ago
  There's LavaMoat, which enables using SES confinement around normal npm packages by creating a policy file for what can be imported/required by that module (and can auto-generate a suggested policy file from what appears used, which fails to greater restriction/security, and can easily be expanded): https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat
danfinlay 5y ago
Hi there, TC-39 delegate and MetaMask co-founder here. SES does address this, and strives to achieve "object capability security", wherein access to a function is equivalent to permission to use it. One difference between an object capability approach and the capability-token approach described in the OP article is that in an ocap approach, you would have no need for passing around a capability token just to pass it to the restricted methods: Instead, you simply disallow importing modules by default, and now pass in any restricted methods to modules that you want to have access to them. I find this approach greatly more ergonomic, and if you ever want to further restrict a function, you don't need a new token, you just write a closure with your own policy defined in it! By the way, we've developed a tool called LavaMoat that allows applying SES security to existing npm modules, no token-passing needed, by restricting the environment of each module per a policy file. https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat While we're at it, I'll plug an audit we did of the SES shim code: https://agoric.com/blog/technology/metamask-agoric-hardened-js-security-review/ https://agoric.com/blog/technology/metamask-agoric-hardened-...

by 3np 5y ago

lucacasonato 5y ago

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.

naugtur 5y ago
There's Endo, which does the loading/importing and dependency resolution. It doesn't have a default user experience at this point, but it creates compartments for packages and runs. Getting permissions involved will require mapping them to packages in a policy file and there you go - an environment where you can use packages and they can't surprise you with data exfiltration etc.
naugtur 5y ago
Also, what's shadow realms? I tried looking it up and got a video game. And I'm not much of a gamer so it's not a matter if a bubble ;)
- robotnikman 5y ago
  I think they might be talking about this https://github.com/tc39/proposal-shadowrealm https://github.com/tc39/proposal-shadowrealm ShadowRealm is possibly a reference to the Shadow Realm from the card game Yu-Gi-Oh
danfinlay 5y ago
There's LavaMoat, which enables using SES confinement around normal npm packages by creating a policy file for what can be imported/required by that module (and can auto-generate a suggested policy file from what appears used, which fails to greater restriction/security, and can easily be expanded): https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat

danfinlay 5y ago

Hi there, TC-39 delegate and MetaMask co-founder here. SES does address this, and strives to achieve "object capability security", wherein access to a function is equivalent to permission to use it. One difference between an object capability approach and the capability-token approach described in the OP article is that in an ocap approach, you would have no need for passing around a capability token just to pass it to the restricted methods: Instead, you simply disallow importing modules by default, and now pass in any restricted methods to modules that you want to have access to them. I find this approach greatly more ergonomic, and if you ever want to further restrict a function, you don't need a new token, you just write a closure with your own policy defined in it! By the way, we've developed a tool called LavaMoat that allows applying SES security to existing npm modules, no token-passing needed, by restricting the environment of each module per a policy file. https://github.com/LavaMoat/LavaMoat https://github.com/LavaMoat/LavaMoat While we're at it, I'll plug an audit we did of the SES shim code: https://agoric.com/blog/technology/metamask-agoric-hardened-js-security-review/ https://agoric.com/blog/technology/metamask-agoric-hardened-...