Introducing Audit Hooks to Node.js

[vdeturckheim]

Last year, Python introduced audit hooks to the language.

In short, this is an API allowing users to:

• subscribe to certain actions (for instance, file system access)
• prevent certain calls (for instance, preventing accessing a file)
• add userland hooks (we could have some in DB libraries for instance)

Another bonus is that we could add a hook to eval and finally provide a good way to monitor its usage.

I remember that Microsoft team was intereted in having such an API (I understand they drove the effort in Python).

For reference, the Python spec is here https://www.python.org/dev/peps/pep-0578/

Is there any strong opinions on that topic?

[sam-github]

I'm generally in favour, there isn't any particular blockers to doing this, other than that someone has to do the work. :-)

[cjihrig]

I'm also generally in favor but we'd have to consider potential performance overhead, particularly when the hooks are not in use.

[vdeturckheim]

@sam-github I'll probably explore it to implement the eval hook at least and check about the syscall ones after we stabilize Async Storage APIs

@cjihrig yep, performance would be the main point here! I am not even sure of the right depth (having this implemented in JS vs in native land) yet.

[MarcinHoppe]

I would very much like to see it happen 👍.

[mhdawson]

If we can ensure the performance impact is acceptable this seems interesting to me as well.

[bmeck]

This seems reasonable and aligns with the vision I have had. That said, I do think any such API needs to be much more robust than what we often do in Core these days with mutable internals.

[vdeturckheim]

@bmeck in term of performance, mutable internals seems to be the simplest way. Do you forsee another strategy that could work here?

[bmeck]

@vdeturckheim I guess I should clarify my concerns. My concern is mutable globals/builtins affecting audit hooks. E.G. Someone replacing globalThis.Promise and/or something like fs.readFile to intercept, prevent, or otherwise manipulate the audit hook and prevent its intended purpose when such a hook uses those APIs (such as reading a config file off disk and/or using Promise.all, etc.).

If the mutation is able to remove the hook without directly manipulating the actual hook code, that is problematic I would think. The only way that seems safe is if you audit all your hook code, allow it to run prior to any untrusted code, and have a way to ensure they have access to the primordials they need (I wouldn't want to encourage process.binding as a way to create a robust fs.readFile).

I'm not really worried about performance but about the reliability of the feature itself. If it isn't reliable, we probably shouldn't encourage it.

[vdeturckheim]

@bmeck makes sense!

I was thinking about hooking internals that are not exposed to end user. It's an early idea, but for example, muting binding.open here rather than fs.readFile.

[bmeck]

@vdeturckheim that seems reasonable, but we would want to make sure we document all the bindings we expose and I'd still be concerned with global mutations. I know we have primordials now but that seems extremely inconvenient/error prone to have developers code against, I know we are working on moving ESM Loaders to a separate thread for isolation. IDK how others feel if enabling this feature had isolation even if just in a separate Isolate since that would affect performance and we could not pass non-primitives across isolates without cloning.

[vdeturckheim]

@bmeck I understand. I guess there is only one way to know for sure!

I will try to PoC hooking eval and fs in the next months and this should give us visibility over API/strategy.

[DanielRuf]

I'm also in favor of this. Sounds like that what the people of NodeSource provide with NSolid

https://nodesource.com/products/nsolid

It might make sense to allow users to control this through the Policy API, similar to Deno and other solutions on npm.

https://nodejs.org/api/policy.html

[vdeturckheim]

@DanielRuf Thanks for the refs. I digged into NSolid's doc but could not find details about this. Do you know where I could find it?