5 ms·

This simplistic model breaks as soon as a more privileged package passes a callback into a less privileged callback without fully constraining what that callbac

This simplistic model breaks as soon as a more privileged package passes a callback into a less privileged callback without fully constraining what that callback can do. Which, I suspect, is impossible to achieve in practice.

Groxx 5y ago
Perfection is unachievable, yeah. But "privileged package passes values to less privileged package and may be exploited" is so much smaller of a surface than "anything anywhere can os.Exec(whatever it damn well pleases)". Security is not binary, nor can it be. Air-gapping isn't even enough, as is repeatedly demonstrated. That's not a reason to be yolo.
danenania 5y ago
Perhaps it could be achieved with static analysis? 1. Each package declares what permissions it needs in package.json (if any). 2. I declare in my project's top-level package.json what should be allowed. 3. npm install fails if any dependency's permissions exceed what I've defined in 2, and points me to the offending package(s). Then at runtime just my project's restrictions can be applied across the board.
- Groxx 5y ago
  Yeah, even something this simple would likely be enough to prevent several of these supply-chain attacks - they tend to have to add unsafe abilities to historically-safe (but widely used, in part due to their safety) libraries. And this would be fairly simple to add onto existing languages/libraries... which is part of why I'm stunned it hasn't happened yet in practice, even on frequently-exploited systems like NPM. The same kind of permissions system would also help warn you when you're importing a "does far more than you want" sub-tree. If `pad` imports `leftpad` and tomorrow `leftpad` imports the entire Kubernetes codebase, you might actually notice it and fix that instead of your builds just getting a bit bigger and hoping a reviewer notices the lockfile diff (which is probably hidden by default!). Again, not perfect, but better... and applies pressure to do better, possibly improving the ecosystem as a whole. Future languages/tools/etc could be dramatically more intelligent about these kinds of things, but even the crappy basics don't exist in the extreme majority of cases. You could build it yourself many times, but almost nobody does that. Default behaviors matter.

Groxx 5y ago

Perfection is unachievable, yeah. But "privileged package passes values to less privileged package and may be exploited" is so much smaller of a surface than "anything anywhere can os.Exec(whatever it damn well pleases)". Security is not binary, nor can it be. Air-gapping isn't even enough, as is repeatedly demonstrated. That's not a reason to be yolo.

danenania 5y ago

Perhaps it could be achieved with static analysis? 1. Each package declares what permissions it needs in package.json (if any). 2. I declare in my project's top-level package.json what should be allowed. 3. npm install fails if any dependency's permissions exceed what I've defined in 2, and points me to the offending package(s). Then at runtime just my project's restrictions can be applied across the board.

Groxx 5y ago
Yeah, even something this simple would likely be enough to prevent several of these supply-chain attacks - they tend to have to add unsafe abilities to historically-safe (but widely used, in part due to their safety) libraries. And this would be fairly simple to add onto existing languages/libraries... which is part of why I'm stunned it hasn't happened yet in practice, even on frequently-exploited systems like NPM. The same kind of permissions system would also help warn you when you're importing a "does far more than you want" sub-tree. If `pad` imports `leftpad` and tomorrow `leftpad` imports the entire Kubernetes codebase, you might actually notice it and fix that instead of your builds just getting a bit bigger and hoping a reviewer notices the lockfile diff (which is probably hidden by default!). Again, not perfect, but better... and applies pressure to do better, possibly improving the ecosystem as a whole. Future languages/tools/etc could be dramatically more intelligent about these kinds of things, but even the crappy basics don't exist in the extreme majority of cases. You could build it yourself many times, but almost nobody does that. Default behaviors matter.