6 ms·

Your input is appreciated. But to anyone not using JS on a daily basis, the above reads as a blur of detail, rather than a clear, actionable message about to d

Your input is appreciated. But to anyone not using JS on a daily basis, the above reads as a blur of detail, rather than a clear, actionable message about to do about the overall situation. So I'd be curious to know if you have a holistic response to primary claim made by the post, which is: The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer.

yonixw 5y ago
Based on your use-case, it may already been solved. Microservices, for example, are put in a container, which allow you to give read-only\full access to selected files. They also usually have some kind of Mesh side container that limits connectivity between whitelisted containers or public DNS. And since containers can limit memory and throttle CPU, you are more or less at the best you can get using untrusted 3rd party code.
armchairhacker 5y ago
Dynamic languages such as JS allow you to override almost anything. It’s essentially impossible to sandbox “part” of JS code, you must either sandbox the entire runtime (e.g. in browsers) or allow everything (e.g. in node.js). Individual packages want to run arbitrary JS code to do “safe” things during installation. But it’s very hard to allow them to do anything meaningful like file access, even if it’s “safe”, without potentially allowing exploits.
- throwawayboise 5y ago
  Run in a chroot/jail or container?
lucacasonato 5y ago
> The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer. Let me try to answer more concisely at a higher level: Due to JS being a very dynamic language, it is at this time not possible to give different packages inside of the same JS runtime a different set of permissions or capabilities securely. Because of this, the best we can do for sandboxing right now is permissions / capabilities that are set per JS runtime, rather than per dependency / module. This is what Deno does. It allows you to set capabilites for the set of your code and all of it's dependencies at once. If you want to run a certain module with lesser permissions, you need to move it into a seperate JS runtime, either by running it on a seperate thread with a web worker, or in a seperate Deno process. Both web workers and subprocesses can have different (lesser) permissions to their parent.
- paulmd 5y ago
  it's been fascinating watching the JS people reinvent the concept of an OS from scratch. Today it's the security model, yesterday it's the task scheduling, etc. Interesting little bit of outsider art, "what if front-end people designed an OS" and all, and it's going about as well as you'd expect with that. I mostly wouldn't mind, but there's certain thresholds that I think are noxious or dangerous as a user. WebGL strikes me as much more dangerous than most people anticipate, GPU drivers are not really hardened against hostile shaders very well, it's quite likely that various escapes and data-leaks exist imo. Someone I know who worked on implementing that and said that out of all the graphics vendors, none of them liked it but the blue one's engineers had genuine fear in their eyes when the functionality was laid out to them. I am also not really looking forward to when javascript realizes the need for persistent services... but thankfully I think web architecture mostly means that's somebody else's computer.
  - ratww 5y ago
    This comment displays a lot of ignorance and prejudice. "JS people" have not been reinventing much at all. Operating Systems aren't even close to offering what "JS people" needs at the granularity they would benefit from. By that measure, the same complaint can be made about the Java or .NET virtual machine, for example. If anything, what the "JS people" of today is trying is to fix are all those "dangerous parts" that were added there with abandon by browser makers and OS people and will probably never be fixed in our lifetime. > I am also not really looking forward to when javascript realizes the need for persistent services It might surprise you, but Node.js works in the backend from day zero, and Service Workers have been working in the frontend for several years now. You're more than a decade behind the times.
joshAg 5y ago
Not the OP, but the approach sounds roughly similar to SE linux, but for node. A major problem with a half-secure security solution is that it's not actually secure. You might do everything right, and still get owned. For the threat model the solution needs to be complete (or able to be complete, but turned down to less than complete by the user*). Part of the way this manifests with SElinux is that to have a fully locked down box with SElinux you have to consider access controls for _everything_ on the box on top of regular unix permissions. And to actually be a full solution, you have to install kernel headers because anything user-space isn't good enough to guarantee full security. For node to make a similar guarantee locking down everything means turning off a lot of the features that allow javascript to be so dynamic or making major changes to the run-time implementation to support being able to use those features without making the security swiss-cheese. And then, even though the system is securable, there's the issue of turning it on for all the modules you use. And not just the module's you use, but the modules your modules use and on and on. You could delegate the module-module to the module you import but that means either granting overly broad permissions to the module and hoping they don't screw something up (and that any module they delegate to does the same) or not delegating anything and personally granting explicit permissions to every module, no matter how deep in your hierarchy of requirements. If that sounds exhausting, it kind of is. In SElinux's case what that leads to instead usually is rearchitecting things such that you can use virtualization to sandbox things and limiting access across the sandboxes (ohai, it's the deno solution). There's still places where a VM or other sandbox isn't appropriate though and if you want to be on linux you have to use SElinux (or a competitor, but i've only touched selinux), and it's not uncommon to have an entire team whose only job is to configure SElinux and support other teams that interact with it (eg, coaching them on how SElinux interacts with their codebase and what they need to tune, auditing teams' SElinux configs, and keeping SElinux working for the base system as that gets upgraded). And if you screw up or get lazy with auditing permissions, you've just limited the effectiveness of SElinux, possibly rendering it useless. A large part of the reason SElinux is so hard to use and use right (and that directly translates to js and node) is that it's attempting to bolt-on security to an existing system that wasn't designed with (that kind of) security in mind. That's a monumentally hard thing to do in a way that doesn't require rewriting everything that uses it. And not having to rewrite everything is a hard requirement, because if you're going to rewrite everything that uses it, it's usually cheaper and easier to just make something new from scratch (in SElinux's case a new OS, in js's case a new language). So holistic options: 1) remove all the dynamism that makes javascript javascript. this (potentially) breaks all existing code. Call it rustscript and get that to ship in all the browsers, and get all the websites to use that instead of javascript, and then make a serverside environment for rustscript. Now you can do fine-grained module permissioning. 1.5) remove only the dynamism that breaks this sort of security access control as part of a new ECMAScript spec and add support for the security access control at the same time. This breaks existing code, but the old code can still run in a runtime for the earlier spec. New code can take advantage of the new spec features. Old code can be modified to work with the new features. Broken code can be rewritten to the new spec. This makes rustscript ESNext. It will be up to various runtime to support this new runtime, so nodeNext will have support for it but it won't get backported. Browsers will require transpilation from ESNext to an earlier ES version as they do now, but eventually even they would drop support for the older js versions. 2) accept that module permissioning systems are easy enough to get around in JS that anything attempting to implement them is at best security theater. The deno solution isn't security theater, but that's because it makes much less stringent guarantees (ie only runtime granularity and not module granularity). * why allow the user to make themselves insecure? In some cases, the user will choose to be less secure for some external reason or will be using the security solution as a part of a more holistic security solution, so some other part guarantees the security that is given up.
asiachick 5y ago
That is special about JS here? AFAICT the same is true for every python package, every rust crate, every linux package, every ruby gem, etc.... Maybe all of those need the same scrutiny but AFAIK they fundamentally have the same issue.
- ryukafalz 5y ago
  That is correct, these all fundamentally have the same issue and all need the same scrutiny.
- Sohcahtoa82 5y ago
  Python developers are slightly better behaved. I can't possibly come up with a reason WHY (Maybe Python's standard library is that much better than Node?), but Python dependency trees just tend to be so much simpler. If I "pip install $PACKAGE", it's usually only a couple additional dependencies that get included unless it's one of the huge ones like numpy. If I "npm install $PACKAGE", I can expect 50+ additional dependencies to get added. For some reason, Node engineers are much more likely to "npm install leftpad" than write the 2 lines of code it takes to implement string padding.
  - verelo 5y ago
    The JS standard library is very slim. I think this is both its greatest strength and weakness, and to your point, makes it likely that people just install some random package v's solve the problem themselves. I'm not sure which is better philosophically, but personally having done a lot of PHP dev in the last decade I find the JS code i'm writing to be easier to read but much harder to understand and run from a package management perspective. I think the developers working on solutions in JS would probably behave very different if they were given more built in tools to work with.
    - paulmd 5y ago
      the same is true of java - less so in newer versions, but older versions the stdlib was pretty slim and low-level and there was a massive amount of library code written to wrap around it. it still doesn't devolve to the javascript phenomenon of one-file (or one-function) libraries and so on. Dozens of libraries, sure, hundreds, maybe, but nobody actually has thousands of dependencies like you do on node. Apparently "number of repos maintained" is a KPI so there's some gamesmanship there. Maybe it's also being used as a caching thing, smaller files might be more cacheable if you don't minify? More generally though this may be the result of that "enterprise culture" that is sometimes looked down on in other situations, that at least stuff is getting bundled into appropriate packages for distribution vs just chucking every single file into a node package.
hackerfromthefu 5y ago
I think what he is saying is that Javascript is a broken language. Fundamentally un-securable when third party code is used.
- bastawhiz 5y ago
  That's a pretty extreme way to say it. Python is in essentially the same boat, as is bash, Ruby, PHP, dart... Calling languages "broken" is to say that one hard problem makes them unsuitable for use, which is hardly true.
  - akhmatova 5y ago
    I think the main concern here is that it isn't that the language is too permissive -- but that the primary installer (and what many people cite as one of the greatest strengths of JS, largely responsible for ushering in its Golden Age) -- is structurally (and perhaps irreparably) insecure. Whether this is really so (and in a significant way compared to its other competitors, out in dynamic programming land) -- is what people seem to be trying to suss out in this thread.
    - johnny22 5y ago
      how is it any less problematic than python or ruby in this regard?
    - bastawhiz 5y ago
      The top comment mentions Deno, which doesn't have NPM or even use a package manager. So I'm not sure how the "installer" is the relevant problem
  - krapp 5y ago
    Javascript was designed and intended to be used within the context of a browser to manipulate the DOM and script webpages. It is unsuitable for any other use.
    - 5y ago

yonixw 5y ago

Based on your use-case, it may already been solved. Microservices, for example, are put in a container, which allow you to give read-only\full access to selected files. They also usually have some kind of Mesh side container that limits connectivity between whitelisted containers or public DNS. And since containers can limit memory and throttle CPU, you are more or less at the best you can get using untrusted 3rd party code.

armchairhacker 5y ago

Dynamic languages such as JS allow you to override almost anything. It’s essentially impossible to sandbox “part” of JS code, you must either sandbox the entire runtime (e.g. in browsers) or allow everything (e.g. in node.js). Individual packages want to run arbitrary JS code to do “safe” things during installation. But it’s very hard to allow them to do anything meaningful like file access, even if it’s “safe”, without potentially allowing exploits.

throwawayboise 5y ago
Run in a chroot/jail or container?

lucacasonato 5y ago

> The fundamental problem with npm is that any package you install has full access to do whatever it wants on your computer. Let me try to answer more concisely at a higher level: Due to JS being a very dynamic language, it is at this time not possible to give different packages inside of the same JS runtime a different set of permissions or capabilities securely. Because of this, the best we can do for sandboxing right now is permissions / capabilities that are set per JS runtime, rather than per dependency / module. This is what Deno does. It allows you to set capabilites for the set of your code and all of it's dependencies at once. If you want to run a certain module with lesser permissions, you need to move it into a seperate JS runtime, either by running it on a seperate thread with a web worker, or in a seperate Deno process. Both web workers and subprocesses can have different (lesser) permissions to their parent.

paulmd 5y ago
it's been fascinating watching the JS people reinvent the concept of an OS from scratch. Today it's the security model, yesterday it's the task scheduling, etc. Interesting little bit of outsider art, "what if front-end people designed an OS" and all, and it's going about as well as you'd expect with that. I mostly wouldn't mind, but there's certain thresholds that I think are noxious or dangerous as a user. WebGL strikes me as much more dangerous than most people anticipate, GPU drivers are not really hardened against hostile shaders very well, it's quite likely that various escapes and data-leaks exist imo. Someone I know who worked on implementing that and said that out of all the graphics vendors, none of them liked it but the blue one's engineers had genuine fear in their eyes when the functionality was laid out to them. I am also not really looking forward to when javascript realizes the need for persistent services... but thankfully I think web architecture mostly means that's somebody else's computer.
- ratww 5y ago
  This comment displays a lot of ignorance and prejudice. "JS people" have not been reinventing much at all. Operating Systems aren't even close to offering what "JS people" needs at the granularity they would benefit from. By that measure, the same complaint can be made about the Java or .NET virtual machine, for example. If anything, what the "JS people" of today is trying is to fix are all those "dangerous parts" that were added there with abandon by browser makers and OS people and will probably never be fixed in our lifetime. > I am also not really looking forward to when javascript realizes the need for persistent services It might surprise you, but Node.js works in the backend from day zero, and Service Workers have been working in the frontend for several years now. You're more than a decade behind the times.

joshAg 5y ago

Not the OP, but the approach sounds roughly similar to SE linux, but for node. A major problem with a half-secure security solution is that it's not actually secure. You might do everything right, and still get owned. For the threat model the solution needs to be complete (or able to be complete, but turned down to less than complete by the user*). Part of the way this manifests with SElinux is that to have a fully locked down box with SElinux you have to consider access controls for _everything_ on the box on top of regular unix permissions. And to actually be a full solution, you have to install kernel headers because anything user-space isn't good enough to guarantee full security. For node to make a similar guarantee locking down everything means turning off a lot of the features that allow javascript to be so dynamic or making major changes to the run-time implementation to support being able to use those features without making the security swiss-cheese. And then, even though the system is securable, there's the issue of turning it on for all the modules you use. And not just the module's you use, but the modules your modules use and on and on. You could delegate the module-module to the module you import but that means either granting overly broad permissions to the module and hoping they don't screw something up (and that any module they delegate to does the same) or not delegating anything and personally granting explicit permissions to every module, no matter how deep in your hierarchy of requirements. If that sounds exhausting, it kind of is. In SElinux's case what that leads to instead usually is rearchitecting things such that you can use virtualization to sandbox things and limiting access across the sandboxes (ohai, it's the deno solution). There's still places where a VM or other sandbox isn't appropriate though and if you want to be on linux you have to use SElinux (or a competitor, but i've only touched selinux), and it's not uncommon to have an entire team whose only job is to configure SElinux and support other teams that interact with it (eg, coaching them on how SElinux interacts with their codebase and what they need to tune, auditing teams' SElinux configs, and keeping SElinux working for the base system as that gets upgraded). And if you screw up or get lazy with auditing permissions, you've just limited the effectiveness of SElinux, possibly rendering it useless. A large part of the reason SElinux is so hard to use and use right (and that directly translates to js and node) is that it's attempting to bolt-on security to an existing system that wasn't designed with (that kind of) security in mind. That's a monumentally hard thing to do in a way that doesn't require rewriting everything that uses it. And not having to rewrite everything is a hard requirement, because if you're going to rewrite everything that uses it, it's usually cheaper and easier to just make something new from scratch (in SElinux's case a new OS, in js's case a new language). So holistic options: 1) remove all the dynamism that makes javascript javascript. this (potentially) breaks all existing code. Call it rustscript and get that to ship in all the browsers, and get all the websites to use that instead of javascript, and then make a serverside environment for rustscript. Now you can do fine-grained module permissioning. 1.5) remove only the dynamism that breaks this sort of security access control as part of a new ECMAScript spec and add support for the security access control at the same time. This breaks existing code, but the old code can still run in a runtime for the earlier spec. New code can take advantage of the new spec features. Old code can be modified to work with the new features. Broken code can be rewritten to the new spec. This makes rustscript ESNext. It will be up to various runtime to support this new runtime, so nodeNext will have support for it but it won't get backported. Browsers will require transpilation from ESNext to an earlier ES version as they do now, but eventually even they would drop support for the older js versions. 2) accept that module permissioning systems are easy enough to get around in JS that anything attempting to implement them is at best security theater. The deno solution isn't security theater, but that's because it makes much less stringent guarantees (ie only runtime granularity and not module granularity). * why allow the user to make themselves insecure? In some cases, the user will choose to be less secure for some external reason or will be using the security solution as a part of a more holistic security solution, so some other part guarantees the security that is given up.

asiachick 5y ago

That is special about JS here? AFAICT the same is true for every python package, every rust crate, every linux package, every ruby gem, etc.... Maybe all of those need the same scrutiny but AFAIK they fundamentally have the same issue.

ryukafalz 5y ago
That is correct, these all fundamentally have the same issue and all need the same scrutiny.
Sohcahtoa82 5y ago
Python developers are slightly better behaved. I can't possibly come up with a reason WHY (Maybe Python's standard library is that much better than Node?), but Python dependency trees just tend to be so much simpler. If I "pip install $PACKAGE", it's usually only a couple additional dependencies that get included unless it's one of the huge ones like numpy. If I "npm install $PACKAGE", I can expect 50+ additional dependencies to get added. For some reason, Node engineers are much more likely to "npm install leftpad" than write the 2 lines of code it takes to implement string padding.
- verelo 5y ago
  The JS standard library is very slim. I think this is both its greatest strength and weakness, and to your point, makes it likely that people just install some random package v's solve the problem themselves. I'm not sure which is better philosophically, but personally having done a lot of PHP dev in the last decade I find the JS code i'm writing to be easier to read but much harder to understand and run from a package management perspective. I think the developers working on solutions in JS would probably behave very different if they were given more built in tools to work with.
  - paulmd 5y ago
    the same is true of java - less so in newer versions, but older versions the stdlib was pretty slim and low-level and there was a massive amount of library code written to wrap around it. it still doesn't devolve to the javascript phenomenon of one-file (or one-function) libraries and so on. Dozens of libraries, sure, hundreds, maybe, but nobody actually has thousands of dependencies like you do on node. Apparently "number of repos maintained" is a KPI so there's some gamesmanship there. Maybe it's also being used as a caching thing, smaller files might be more cacheable if you don't minify? More generally though this may be the result of that "enterprise culture" that is sometimes looked down on in other situations, that at least stuff is getting bundled into appropriate packages for distribution vs just chucking every single file into a node package.

hackerfromthefu 5y ago

I think what he is saying is that Javascript is a broken language. Fundamentally un-securable when third party code is used.

bastawhiz 5y ago
That's a pretty extreme way to say it. Python is in essentially the same boat, as is bash, Ruby, PHP, dart... Calling languages "broken" is to say that one hard problem makes them unsuitable for use, which is hardly true.
- akhmatova 5y ago
  I think the main concern here is that it isn't that the language is too permissive -- but that the primary installer (and what many people cite as one of the greatest strengths of JS, largely responsible for ushering in its Golden Age) -- is structurally (and perhaps irreparably) insecure. Whether this is really so (and in a significant way compared to its other competitors, out in dynamic programming land) -- is what people seem to be trying to suss out in this thread.
  - johnny22 5y ago
    how is it any less problematic than python or ruby in this regard?
  - bastawhiz 5y ago
    The top comment mentions Deno, which doesn't have NPM or even use a package manager. So I'm not sure how the "installer" is the relevant problem
- krapp 5y ago
  Javascript was designed and intended to be used within the context of a browser to manipulate the DOM and script webpages. It is unsuitable for any other use.
  - 5y ago