3 ms·
All great points, thanks. It would definitely reduce the surface area for attacks. In practice, it may just change which kinds of packages are targeted (package
by danenania 5y ago
All great points, thanks. It would definitely reduce the surface area for attacks. In practice, it may just change which kinds of packages are targeted (packages in the build-time dependency tree instead of runtime), but it would still be a win.
Ultimately, I still think we need real sandboxing built in to the runtime to really solve this problem. Is there something inherent to node's architecture that would make this impossible or is it just a ton of work? Could Chrome's sandbox and CSP implementation be piggy-backed on perhaps? Deno takes some steps in this direction but they stopped well short of what's really needed.
- pxc 5y ago> Deno takes some steps in this direction but they stopped well short of what's really needed. Could you say a little more about what's lacking in Deno here? I know it exists and I know it's taken some new security measures, but not much else.
- danenania 5y agoI’m not a Deno user but my understanding is that permissions for the file system or network are all-or-nothing for a whole project. There’s no ability to specify directories or domains, or for dependencies to declare permissions they need. It’s better than nothing, but only makes a difference for projects that don’t need the file system and/or network at all. It wouldn’t have helped with any node project I’ve ever seen in the wild. That said, perhaps it’s just a starting point and will be expanded into something more useful in time. It would be a killer feature imo if done right so I hope they go in that direction.