Re:Understand filesystem takeover vulnerabilities in NPM Jav...
by tomxor on Wednesday January 08, 2020 @09:44PM
(#21998062)
> anything you put in your PATH needs to be treated exactly with as much care as anything you install in /bin. [...] it's not a security feature.
The parent was highlighting how the article points out you can overwrite root files:
> "bin": { "/usr/bin/date": "./fake-date" }
This is not possible with ~/.local
I wouldn't call this a "security feature", but I would call it prudent to not hand over root access to npm packages.
> Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package.
This is not the problem with npm, the problem is dependencies, and their dependencies and so on. I certainly will never be able to personally vet the 1000 deep nest of dependencies in an npm package I may have to use.
The parent was highlighting how the article points out you can overwrite root files:
> "bin": { "/usr/bin/date": "./fake-date" }
This is not possible with ~/.local
I wouldn't call this a "security feature", but I would call it prudent to not hand over root access to npm packages.
> Also, it's not unreasonable to trust npm packages just like OS packages if you know who released it. NPM names are first-come, first-served, and once allocated, they are permanent. If you know and trust the person who released the package, there's nothing wrong with trusting the package.
This is not the problem with npm, the problem is dependencies, and their dependencies and so on. I certainly will never be able to personally vet the 1000 deep nest of dependencies in an npm package I may have to use.