6 ms·

Speaking of trusting trust, I think I'd love for Node¹ to support something like OpenBSD pledge (2) and unveil (2) for imports, where once you enter into a part

Speaking of trusting trust, I think I'd love for Node¹ to support something like OpenBSD pledge (2) and unveil (2) for imports, where once you enter into a particular package certain capabilities are disabled. I would like to be able to assert that when I import some package, it and all of the packages it recursively includes do not perform network requests, do not use the filesystem outside of some folder, and so on. A fine grained capability system for packages would dramatically improve the safety profile, and if this were built into package.json and the lockfile we could do the following: 1. Packages advertise what their default capabilities should be limited to 2. Changes in those capabilities are encoded in the package lock file, and can't be changed without the user explicitly affirming them ¹ and other langs with extensive use of package managers and micro-packages

pier25 6y ago
> A fine grained capability system for packages would dramatically improve the safety profile I think Deno does that (the new project by Node's original creator): https://blog.logrocket.com/what-is-deno/ https://blog.logrocket.com/what-is-deno/
- mthoms 6y ago
  Woohoo! I just noticed Deno is at release candidate stage for v1.0.
- jakear 6y ago
  Deno gives all packages the same permissions of the main app. So if your app can make network requests, so can every dependency you use. It’s not a great situation. I’ve brought this up to them and their response is that per-package permissions would be too difficult to implement.
  - vijaybritto 6y ago
    Yes, checking everyone at the main door is indeed easier than checking everyone at every single point of contact. It needs a vast architectural change compared to current implementation as you need to enforce those rules at runtime!
    - jakear 6y ago
      Well yeah, but I thought the whole point of deno was to make vast architectural changes to allow for increased security. Seems odd to stop half way.
  - Already__Taken 6y ago
    The app design is going to have to change around per-process permissions. build.ts doesn't need the same as main.ts but at that point what are you getting where you couldn't just use docker and abstract that pattern to literally all software and dependencies that aren't in deno. Maybe it's a start of better tooling? Kicking out a graph of package/permission call stack might be useful to audit
gecko 6y ago
Deno (a modern JS runtime from the same original author as Node) is heading this direction, albeit it’s currently more a traditional opt-in than OpenBSD-style opt-out.
eyelidlessness 6y ago
This is a much more productive answer to the node dependency tree question than I'm used to encountering, and it's much more in line with most large modern systems are tending to address security from >1th party sources. Wall it off, require explicit permission, worry more about the security of the sandbox and less about the security of the dependencies. It doesn't address everything (and it becomes a lot riskier when you do give permission), but it's a far better proposal than shouting about how many dependencies are common in the JS ecosystem without any additional steps.
ahupp 6y ago
This is a really cool idea.
philsnow 6y ago
I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have). Maybe it could be solved by type checking during dependency resolution time: instead of just checking version numbers, also check capabilities that transitive dependencies declare. Maybe you could slowly boil the ocean by assuming that everything that doesn't declare required capabilities implicitly requires the "ALL" capability, and triage+prioritize a growing core of packages that have explicit capability requirements. In my mind it's kind of like purifying functions in a library: you start at the lowest level / leaves of the call graph and make sure they don't do any I/O, and then the things that call them can be made pure and so on up the chain.
- ori_b 6y ago
  > I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have). That sounds like it would be working. If you declare that your package doesn't need network, and it fails because it used the network, that sounds like a bug was caught.
vnorilo 6y ago
My first reaction was that if we need protection from pieces of software we ship because nobody knows what we ship, something must be deeply wrong. But npm-snark aside, maybe some lack of trust must come from a highly modular open source ecosystem. If a library I ship could abstain from unneeded platform capabilities, that would certainly reduce catastrophic bug/attack surface, and I'd sleep better.
tmerse 6y ago
This describes what I am currently missing the most in the node ecosystem. Deno is a good approach but it will take some time to see how adoption goes. I would prefer some fine grained capability-based solution. Approaches similar to this have often been articulated [1]. Many of my concerns are best described here [2]. There even was an article from someone who would have been able to overtake many high profile npm accounts with very little effort some time ago (cannot find it anymore). With tighter snyk integration into npm and the acquisition of npm through ms one could argue that security bar may have risen/will rise but I (speaking as a js/ts dev) am still sceptical. I haven't really looked to deep into stuff like selinux/apparmor/firejail [3] maybe someone can give an opinion on this. I'd wish for something that would be codeified on package level to make review easier and give me some peace of mind. For now my plan is to dockerize most of my projects and it's dependencies. It should give a little more protection against malicious postinstall scripts. Unfortunately, I depend more and more on npm modules outside of projects (coc-vim comes to mind/for others it may be vscode etc.). [1] https://medium.com/hackernoon/npm-package-permissions-an-idea-441a02902d9b https://medium.com/hackernoon/npm-package-permissions-an-ide... (2018) [2] https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://medium.com/hackernoon/im-harvesting-credit-card-numb... (2018) [3] https://github.com/netblue30/firejail/blob/master/README.md https://github.com/netblue30/firejail/blob/master/README.md
mycall 6y ago
This capabilities based OS library reminds me of genode some.

pier25 6y ago

> A fine grained capability system for packages would dramatically improve the safety profile I think Deno does that (the new project by Node's original creator): https://blog.logrocket.com/what-is-deno/ https://blog.logrocket.com/what-is-deno/

mthoms 6y ago
Woohoo! I just noticed Deno is at release candidate stage for v1.0.
jakear 6y ago
Deno gives all packages the same permissions of the main app. So if your app can make network requests, so can every dependency you use. It’s not a great situation. I’ve brought this up to them and their response is that per-package permissions would be too difficult to implement.
- vijaybritto 6y ago
  Yes, checking everyone at the main door is indeed easier than checking everyone at every single point of contact. It needs a vast architectural change compared to current implementation as you need to enforce those rules at runtime!
  - jakear 6y ago
    Well yeah, but I thought the whole point of deno was to make vast architectural changes to allow for increased security. Seems odd to stop half way.
- Already__Taken 6y ago
  The app design is going to have to change around per-process permissions. build.ts doesn't need the same as main.ts but at that point what are you getting where you couldn't just use docker and abstract that pattern to literally all software and dependencies that aren't in deno. Maybe it's a start of better tooling? Kicking out a graph of package/permission call stack might be useful to audit

gecko 6y ago

Deno (a modern JS runtime from the same original author as Node) is heading this direction, albeit it’s currently more a traditional opt-in than OpenBSD-style opt-out.

eyelidlessness 6y ago

This is a much more productive answer to the node dependency tree question than I'm used to encountering, and it's much more in line with most large modern systems are tending to address security from >1th party sources. Wall it off, require explicit permission, worry more about the security of the sandbox and less about the security of the dependencies. It doesn't address everything (and it becomes a lot riskier when you do give permission), but it's a far better proposal than shouting about how many dependencies are common in the JS ecosystem without any additional steps.

ahupp 6y ago

This is a really cool idea.

philsnow 6y ago

I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have). Maybe it could be solved by type checking during dependency resolution time: instead of just checking version numbers, also check capabilities that transitive dependencies declare. Maybe you could slowly boil the ocean by assuming that everything that doesn't declare required capabilities implicitly requires the "ALL" capability, and triage+prioritize a growing core of packages that have explicit capability requirements. In my mind it's kind of like purifying functions in a library: you start at the lowest level / leaves of the call graph and make sure they don't do any I/O, and then the things that call them can be made pure and so on up the chain.

ori_b 6y ago
> I like the sound of it, but it seems like it might descend into something like checked exception hell where a given package D works fine as a dependency of package A but not of package B (because package B drops some privileges that D expects to have). That sounds like it would be working. If you declare that your package doesn't need network, and it fails because it used the network, that sounds like a bug was caught.

vnorilo 6y ago

My first reaction was that if we need protection from pieces of software we ship because nobody knows what we ship, something must be deeply wrong. But npm-snark aside, maybe some lack of trust must come from a highly modular open source ecosystem. If a library I ship could abstain from unneeded platform capabilities, that would certainly reduce catastrophic bug/attack surface, and I'd sleep better.

tmerse 6y ago

This describes what I am currently missing the most in the node ecosystem. Deno is a good approach but it will take some time to see how adoption goes. I would prefer some fine grained capability-based solution. Approaches similar to this have often been articulated [1]. Many of my concerns are best described here [2]. There even was an article from someone who would have been able to overtake many high profile npm accounts with very little effort some time ago (cannot find it anymore). With tighter snyk integration into npm and the acquisition of npm through ms one could argue that security bar may have risen/will rise but I (speaking as a js/ts dev) am still sceptical. I haven't really looked to deep into stuff like selinux/apparmor/firejail [3] maybe someone can give an opinion on this. I'd wish for something that would be codeified on package level to make review easier and give me some peace of mind. For now my plan is to dockerize most of my projects and it's dependencies. It should give a little more protection against malicious postinstall scripts. Unfortunately, I depend more and more on npm modules outside of projects (coc-vim comes to mind/for others it may be vscode etc.). [1] https://medium.com/hackernoon/npm-package-permissions-an-idea-441a02902d9b https://medium.com/hackernoon/npm-package-permissions-an-ide... (2018) [2] https://medium.com/hackernoon/im-harvesting-credit-card-numbers-and-passwords-from-your-site-here-s-how-9a8cb347c5b5 https://medium.com/hackernoon/im-harvesting-credit-card-numb... (2018) [3] https://github.com/netblue30/firejail/blob/master/README.md https://github.com/netblue30/firejail/blob/master/README.md

mycall 6y ago

This capabilities based OS library reminds me of genode some.