Accept WHATWG URL objects in private-key inputs and load referenced keys
through OpenSSL STORE loaders. Pass optional property queries and
passphrases while preserving provider-owned EVP_PKEY objects for
ordinary KeyObject and CryptoKey operations.
Signed-off-by: Filip Skokan <panva.ip@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/63949
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Expand the documentation for the --permission-audit flag, which was
fixed in 51c09eae6c to no longer throw ERR_ACCESS_DENIED on denied
operations. The previous docs only had a two-sentence description in
cli.md and no mention in the permissions guide or process.permission
API docs.
- permissions.md: add enforce vs audit mode overview, a new
"Audit Mode" subsection listing the diagnostics channel names
(node:permission-model:*) and the { permission, resource } message
shape, and a usage example. Update the Runtime API section to
mention both --permission and --permission-audit.
- cli.md: expand the --permission-audit section to clarify that
--permission is not required, --allow-* flags are not needed,
errors are not thrown, and --permission takes precedence when both
are set. Add a cross-reference from --permission to
--permission-audit.
- process.md: note that process.permission is available under both
flags, and clarify permission.has() and permission.drop() behavior
in audit mode.
- node.1: regenerated via `make node.1`.
Refs: https://github.com/nodejs/node/pull/64426
Signed-off-by: Adrian Estrada <edsadr@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64791
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Marco Ippolito <marcoippolito54@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
The permission model grew enough to be splited into multiple files, the
link in the md file is broken. And as it is not part of a single file,
the best way to fix this is just remove the link, many APIs in Node.js
does not have the source code linked, this is not bad for our docs.
Signed-off-by: Juan José Arboleda <soyjuanarbol@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/58972
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Previously, only child_process.fork propagated the exec
arguments (execvArgs) to the child process.
This commit adds support for spawn and spawnSync to
propagate permission model flags — except when they are
already provided explicitly via arguments or through
NODE_OPTIONS.
Signed-off-by: RafaelGSS <rafael.nunu@hotmail.com>
PR-URL: https://github.com/nodejs/node/pull/58853
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
This improves Permission Model usage when allowing read access to
specifi modules. To achieve that, the permission model check on
internalModuleStat has been removed meaning that on module loading,
uv_fs_stat is performed on files and folders even when the permission
model is enabled. Although a uv_fs_stat is performed, reading/executing
the module will still pass by the permission model check.
Without this PR when an app tries to --allow-fs-read=./a.js
--allow-fs-read=./b.js where `a` attempt to load b, it will fails as
it reads $pwd and no permission has been given to this path.
PR-URL: https://github.com/nodejs/node/pull/55797
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Ulises Gascón <ulisesgascongonzalez@gmail.com>
When creating an fast api the callback might use the receiver. In that
case if the internal binding is destructured the method won't have
access to the reciver and it will throw. Passing the receiver as second
argument ensures the receiver is available.
PR-URL: https://github.com/nodejs/node/pull/54408
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
Reviewed-By: Yagiz Nizipli <yagiz@nizipli.com>
Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Much earlier, a design decision was made that the permission model
should not prevent following symbolic links to presumably inaccessible
locations. Recently, after some back and forth, it had been decided that
it is indeed a vulnerability that symbolic links, which currently point
to an accessible location, can potentially be re-targeted to point to a
presumably inaccessible location. Nevertheless, months later, no
solution has been found and the issue is deemed unfixable in the context
of the current permission model implementation, so it was decided to
disclose the vulnerability and to shift responsibiliy onto users who are
now responsible for ensuring that no potentially dangerous symlinks
exist in any directories that they grant access to.
I believe that this design issue might be surprising and that it comes
with significant security implications for users, so it should be
documented.
Original vulnerability report: https://hackerone.com/reports/1961655
PR-URL: https://github.com/nodejs/node/pull/49154
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com>
As a side effect of 205f1e643e, Node.js
now resolves some paths differently when the permission model is
enabled. While these are mostly edge cases, they are worth mentioning in
the documentation. This commit also adds a known_issues test that
demonstrates one such difference.
PR-URL: https://github.com/nodejs/node/pull/49155
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
When the experimental permission model is enabled, the running
JavaScript code is subject to certain restrictions, all of which can
be bypassed or even disabled by native code due to the nature of the
permission model implementation. That is why Node.js native addons
are disabled by default when the permission model is enabled. However,
the built-in crypto, https, and tls modules still allow loading
custom OpenSSL engines. Because OpenSSL engines can execute arbitrary
(native) code while being loaded by Node.js, this has the same security
implications as allowing native addons. In other words, allowing user
code to load OpenSSL engines at runtime effectively enables bypassing
any supposed security restrictions.
This patch adds appropriate checks before attempting to dynamically
load an OpenSSL engine that throw an error if the permission model is
enabled.
PR-URL: https://github.com/nodejs-private/node-private/pull/409
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
CVE-ID: CVE-2023-30586
Filip Skokan