Security-wg: feature request for `require.pure(id)` or `pkg.pure:true`

[LongTengDao]

Feature request.

Most third part module we are using are pure function things. If we can control that (when we require them even install them), then maybe most security problems could under control easily?

"pure module require" means:

1. no i/o, like fs, net native module.
2. no global writting, like global variables and native module properties.
3. other things, like Buffer.allocUnsafe, child_process API.
4. pkg.scripts field actions will have no chance to attack the computer (For example, install a package to check if the source is evil. Package installed. Computer dead).
5. pure module can only require pure module.

[vdeturckheim]

This is a good idea, but we need a SES-like protection to prevent the globals tempering. I need to check what is the status here.
@LongTengDao would you start working on that?

[LongTengDao]

@vdeturckheim My pleasure. But I'm an user land coder, I'm good at JavaScript, but know nothing about C++, and the JavaScript part source code of Node.js is also so huge, I have almost no idea about the engine level things. If I can help in any case (API discussion?), I'll be glad to do.

[LongTengDao]

@hax @i5ting @island205 @JacksonTian @justjavac Would you provide some suggestion? 🛩

[hax]

@LongTengDao It's a very interesting idea. I plan to first try to figure out whether we can implement it in user land (though I don't know how to achieve point 4.)

[LongTengDao]

though I don't know how to achieve point 4.

@hax Thank you, predecessor!

We usually inevitably use scripts field for self building after install it. We can limit it can only use fs to i/o in the module directory, in addition to this, the scripts must run in "pure" mode.
If it's a bash... Maybe we can only via an auto system user which only has local i/o permission in the module directory.

Point out, if I misunderstand of scripts field.

[LongTengDao]

This is a good idea, but we need a SES-like protection to prevent the globals tempering. I need to check what is the status here.

@vdeturckheim I can't find information about "SES" by Google, what does that mean? And I found "Chrome Content Scripts" in Electron docs, do you mean that? Thanks!

contextIsolation Boolean (optional) - Whether to run Electron APIs and the specified preload script in a separate JavaScript context. Defaults to false. The context that the preload script runs in will still have full access to the document and window globals but it will use its own set of JavaScript builtins (Array, Object, JSON, etc.) and will be isolated from any changes made to the global environment by the loaded page. The Electron API will only be available in the preload script and not the loaded page. This option should be used when loading potentially untrusted remote content to ensure the loaded content cannot tamper with the preload script and any Electron APIs being used. This option uses the same technique used by Chrome Content Scripts. You can access this context in the dev tools by selecting the 'Electron Isolated Context' entry in the combo box at the top of the Console tab.

[vdeturckheim]

@LongTengDao sure, here is a wiki page https://github.com/google/caja/wiki/SES

you can also check the current state of the realms proposal on TC39 https://github.com/tc39/proposal-realms

[LongTengDao]

@vdeturckheim Oh, it's cool! Realms is good for plugins of software like vscode. Maybe it's a solution behind require, but I can't see how to use it directly for most module requiring without support of node, am I right? Should we wait realms for meeting this need, or still do it with SES at now?

[LongTengDao]

I found a related repo today: https://github.com/secure-require/secure-require

Hope it works, if it's possible in userland.