3 ms·

> Deno adds permissions per dependency Another project heading in that direction is also an anagram of Node: "The foundation of Endo is SES, a tamper-proof Ja

> Deno adds permissions per dependency Another project heading in that direction is also an anagram of Node: "The foundation of Endo is SES, a tamper-proof JavaScript environment that allows safe execution of arbitrary programs in Compartments. ... Endo uses LavaMoat to automatically generate reviewable policies that determine what capabilities will be distributed to third party dependencies. https://github.com/endojs/endo https://github.com/endojs/endo

freeqaz 5y ago
Edit: Lol, I was looking at my previous submissions to HN and I noticed that I'd submitted[3] LavaMoat just a few weeks ago! Maybe with this recent Protestware stuff going on, that project can get a few more contributors wanting to help out. ------ Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea. It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions. But, it's also something that could maybe be attached similarly to how TypeScript types are "retroactively" added for existing vanilla JS NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`). It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt. vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies. As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal. I'm optimistic for the future but we still have a long way to go before we get to it! 0: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped 1: https://www.npmjs.com/package/vm2 https://www.npmjs.com/package/vm2 2: https://github.com/advisories/GHSA-6pw2-5hjv-9pf7 https://github.com/advisories/GHSA-6pw2-5hjv-9pf7 3: https://news.ycombinator.com/item?id=30280642 https://news.ycombinator.com/item?id=30280642
- dane-pgp 5y ago
  > it would require somebody to define a "security policy" for every module to whitelist permissions. That doesn't seem particularly onerous. The writers of a piece of software should know if it requires network or filesystem or shell or eval access, and adding those permission requests to a package should require just a couple of keywords added to a config file. If the permissions are too strict, then someone running the code in an enforcing runtime will get errors and presumably add an override, then submit a one-line patch upstream. On the other hand, if the permissions aren't strict enough, people should think "Hey, why does this arithmetic library need filesystem access?" and submit one-line patches to remove that permission request. The hardest part will be encouraging writers of popular packages to split them along permission lines, so that people can install just the subset of functionality that solves their use case without granting unnecessary permissions.

freeqaz 5y ago

Edit: Lol, I was looking at my previous submissions to HN and I noticed that I'd submitted[3] LavaMoat just a few weeks ago! Maybe with this recent Protestware stuff going on, that project can get a few more contributors wanting to help out. ------ Nice! Thanks for sharing that link. I've done a bit of digging into that project before and it's definitely a very promising idea. It has a lot of the same pitfalls as Dyno, imo, in that it would require somebody to define a "security policy" for every module to whitelist permissions. But, it's also something that could maybe be attached similarly to how TypeScript types are "retroactively" added for existing vanilla JS NPM packages. Ie, packages that have never added their own type declarations (like `express`) can have their types added to DefinitelyTyped[0] and published as a separate NPM package (`@types/express`). It works fairly well and something like `@endo-policies/express` wouldn't be crazy to add in later. Obviously it's going to be super painful, but fixing tech debt is always going to hurt. vm2[1] is another Node project with some semi-similar goals that's worth mentioning. It's not designed to be "applied" in the same way as Endo, but it does give you a way to "sandbox" dependencies. As a security person, I am weary to trust something like vm2 because it is much harder to "get right" than a "sandboxed-by-default" approach like Endo or Dyno. Look at this[2] CVE on vm2 from a few months ago for some evidence about _why_ this approach isn't ideal. I'm optimistic for the future but we still have a long way to go before we get to it! 0: https://github.com/DefinitelyTyped/DefinitelyTyped https://github.com/DefinitelyTyped/DefinitelyTyped 1: https://www.npmjs.com/package/vm2 https://www.npmjs.com/package/vm2 2: https://github.com/advisories/GHSA-6pw2-5hjv-9pf7 https://github.com/advisories/GHSA-6pw2-5hjv-9pf7 3: https://news.ycombinator.com/item?id=30280642 https://news.ycombinator.com/item?id=30280642

dane-pgp 5y ago
> it would require somebody to define a "security policy" for every module to whitelist permissions. That doesn't seem particularly onerous. The writers of a piece of software should know if it requires network or filesystem or shell or eval access, and adding those permission requests to a package should require just a couple of keywords added to a config file. If the permissions are too strict, then someone running the code in an enforcing runtime will get errors and presumably add an override, then submit a one-line patch upstream. On the other hand, if the permissions aren't strict enough, people should think "Hey, why does this arithmetic library need filesystem access?" and submit one-line patches to remove that permission request. The hardest part will be encouraging writers of popular packages to split them along permission lines, so that people can install just the subset of functionality that solves their use case without granting unnecessary permissions.