"Keeping your dependencies close" does not address industry practice re private NPM registries about node-sec-roadmap HOT 11 OPEN

Artifactory supports 5 (https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AdvancedConfiguration).
Sinopia (https://www.npmjs.com/package/sinopia#override-public-packages) and Verdaccio (https://github.com/verdaccio/verdaccio/blob/66b2175584e29587be0fd7979ea9f9c73b08b8e9/docs/use-cases.md#override-public-packages) supports it as well.

I'm very confident that NPM Enterprise support this as well, but there is no public documentation around this feature.

from node-sec-roadmap.

Thanks for giving it a read.

Do you know of any good comparison of non-free registry mirrors?

Your point re add-ons is well made but I thought the problem with architecture-specific artifacts also affected anything that builds binary tools as part of it's installation process.

I agree that sandboxing builds may be tricky and may be biased by what Google has internally but haven't CI systems like Travis already solved the problem of farming out jobs to a pool of shared machines comprising a variety of architectures.

from node-sec-roadmap.

I looked a bit more into your suggestions.

I think you're right there are some separable issues, and we should not have discussed yarn without at least mentioning other practices. I'll try to fix that.

The only point that is not addressed by using a private NPM registry is the
danger of installation scripts.

It's unclear to me, that this is true.
To address the threat model we outline, a registry needs to provide

1. Local caches of npm packages so that an interruption in service by registry.npmjsdoesn't affect the ability to deploy a security update to existing products.
2. The ability to cherrypick versions from registry.npmjs so that reviewers can exercise oversight, and rollback globally when a version of a package is found to have been compromised or have security-relevant regressions.
3. The ability to associate organization specific metadata with packages and specific versions of the same.
4. The ability to cross-compile binaries.
5. The ability to publish one's own local patches to packages in the global namespaces, so that incident responders can workaround zero-days without waiting for upstream.

I've no real world experience administering any of (artifactory, ...) but my read of the docs suggests that they all have (1), most have (2,3), some have (4), and it's unclear that any have (5). Could you or do you know of someone who could confirm my simplistic analysis?

from node-sec-roadmap.

Do you know of any good comparison of non-free registry mirrors?

Unfortunately no. I've worked with both NPM Enterprise and Artifactory and they both worked very well.

Your point re add-ons is well made but I thought the problem with architecture-specific artifacts also affected anything that builds binary tools as part of it's installation process.

Absolutely, but this is a key component of the node ecosystems. In other communities, they use very few architecture-specific artifacts.

I agree that sandboxing builds may be tricky and may be biased by what Google has internally but haven't CI systems like Travis already solved the problem of farming out jobs to a pool of shared machines comprising a variety of architectures.

Yes! However that approach is definitely not widespread or used in the industry at large. Some companies completely blocks native addons, install scripts and prebuilt binaries for security purposes. Others consider development machines unsafe, and force anybody that touch production-level systems to use a different machine.

Frankly, very few cares about this attack vector because of the user-friendliness of binary addons and install scripts.

from node-sec-roadmap.

The ability to cross-compile binaries.

This should fold around the "install scripts and binaries" threat, because it's different from the other points that aim to guarantee access to the registry itself.

from node-sec-roadmap.

Artifactory supports 5 ...

Lovely. Thanks much.

Yes! However that approach is definitely not widespread or used in the industry at large. Some companies completely blocks native addons, install scripts and prebuilt binaries for security purposes. Others consider development machines unsafe, and force anybody that touch production-level systems to use a different machine.

A goal of the roadmap is to show how we can have our cake and securely eat it too.
It may be worth noting that some disable these, but if there are ways to allow most node projects to use core Node features while managing risks, then the roadmap ought address that.

Treating a development machine as unsafe is wise when deciding who can connect to production machines.
But it's not sufficient when malicious code running on a development machine can affect production builds by writing source code and abusing the developer's commit privileges.

Your point re add-ons is well made but I thought the problem with architecture-specific artifacts also affected anything that builds binary tools as part of it's installation process.

Absolutely, but this is a key component of the node ecosystems. In other communities, they use very few architecture-specific artifacts.

I'm confused. I agree that it's awesome that NPM makes it so easy to expose JavaScript interfaces to tools written in other languages. Maybe I misunderstand you, but you seem to be arguing that a Node security roadmap should not bother addressing the attendant risks. It seems to me to argue for the opposite though.

Frankly, very few cares about this attack vector because of the user-friendliness of binary addons and install scripts.

I think you are correct. Nevertheless, the roadmap aims to start a discussion about what the community should care about. If we are correct that there is a real risk of malicious code affecting production via worms that abuse access to a developers workspace or by abusing npm publish privileges, then the roadmap needs to address it.

from node-sec-roadmap.

Treating a development machine as unsafe is wise when deciding who can connect to production machines.
But it's not sufficient when malicious code running on a development machine can affect production builds by writing source code and abusing the developer's commit privileges.

This can happen even if the install scripts/build are run in a buildbox. Those artifacts will end in production, so an attacker could affect production anyway. However, no development secret are leaked in this way.

I'm confused. I agree that it's awesome that NPM makes it so easy to expose JavaScript interfaces to tools written in other languages. Maybe I misunderstand you, but you seem to be arguing that a Node security roadmap should not bother addressing the attendant risks. It seems to me to argue for the opposite though.

I think that allowing binary modules and install scripts has a certain level of insecurity in itself, and the only practical solution to this problem is to not ship them. A gypfile can trigger actions (https://gyp.gsrc.io/docs/LanguageSpecification.md), basically executing possibly malicious code.

I think you are correct. Nevertheless, the roadmap aims to start a discussion about what the community should care about. If we are correct that there is a real risk of malicious code affecting production via worms that abuse access to a developers workspace or by abusing npm publish privileges, then the roadmap needs to address it.

Agreed!

I'm mainly pointing these out to so that we can reason about two things:

a. processes and tools that are common in the Node.js industry, so that we spread the knowledge to people that do not know
b. things that should get better in the Node.js community at large.

I do not think we have a good answer to the install script/build/worm threat.

from node-sec-roadmap.

Good work @mikesamuel!

I would add the criteria that you listed above in the document, as Artifactory is a product from a vendor I would like that the guide lists the properties that the vendor should have (so that the users can evaluate form themselves).

I would also note that, in the case a security vulnerability come up, it should be reported via this process https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md.

from node-sec-roadmap.

I do not think we have a good answer to the install script/build/worm threat.

Agreed.

I see 3 problems:

1. Separation of privileges during installation.
2. Separation of privileges during local testing.
3. Ken Thompson's malicious compiler problem.

(1) should be able to write files under node_modules/
(2) should not typically write files except log files typically under tmp/

We can mitigate (2) by tweaking npm start in the project's own package.json, so this is an entirely project internal issue.

The reason I focus, perhaps overly, on (1) is that it is not a project internal issue.

I assume we will not solve (3) in my lifetime :)

from node-sec-roadmap.

I would add the criteria that you listed above in the document, as Artifactory is a product from a vendor I would like that the guide lists the properties that the vendor should have (so that the users can evaluate form themselves).

Replaced the bullet list under "Proposed Solution" with it.

I would also note that, in the case a security vulnerability come up, it should be reported via this process https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md.

Added to the "Background" section at the top.

from node-sec-roadmap.

https://nodesecroadmap.fyi/chapter-4/close_dependencies.html includes the rewrite.

The static file server has a cache timeout of 30min so if you see the old version, a hard browser refresh should suffice.

from node-sec-roadmap.