Remove --experimental-policy

[mcollina]

Our docs reports:

The approval of the module integrity in the policies threat model implies they are allowed to muck with and even circumvent security features once loaded, so environmental/runtime hardening is expected.

Therefore, once a module is loaded, they have the keys to the castle.

After reviewing a few security reports about this feature, I don't think it provides much additional protection against our threat model: https://github.com/nodejs/node/blob/main/SECURITY.md#the-nodejs-threat-model.

Note that this was developed before we had a threat model.

[mcollina]

cc @nodejs/security-wg

[targos]

I think the main issue with this feature is that we don't have an active collaborator who understands and maintains it.

[mcollina]

Also ref nodejs/security-wg#1283.

[marco-ippolito]

I believe there is some interest from microsoft folks for windows
#51786

[mcollina]

The current volume of issues on HackerOne that cannot understand that policies do not protect against RCE suggest me it's a misunderstood feature. They protect against an "offline" threat, which is very unusual compared to our current threat model.

#51786 makes it significant more robust, so at least the integrity hashes could not be tampered with, making the feature solid.

I'm still leaning toward removal, unless @rdw-msft would like to step in a more active role to help with this.

[avivkeller]

In my opinion, it is a misunderstood feature. When I saw the policy, I thought it was a way to stop 'trusted' code from accessing modules, which, in turn, ignores the whole explanation of what 'trusted' code really is.

[RafaelGSS]

As a person who reviewed a bunch of those reports, unfortunately, I agree with its removal. We have tried a few times to make its boundaries clear, and to be honest, it's still quite confusing (See: https://github.com/nodejs-private/node-private/issues/448). I'm also attempting to improve it at nodejs/security-wg#1255 (comment). But, its scope is too large that I'm afraid we will never be able to handle all those edge cases.

cc/ @bmeck for awarness

[bmeck]

This feature never reached a critical minimal adoption, this seems a fine experiment to remove and pursue other security model possibilities; however if import maps do add SRI it likely would be in a similar situation per Add subresource integrity support for ES modules, through importmaps by yoavweiss · Pull Request #10269 · whatwg/html · GitHub <whatwg/html#10269/> ; which would also carry a security framing. Not sure what to do about that in the future, but I'm not able to invest time into this and it is just a heads up.

…

On Thu, Apr 18, 2024 at 8:41 AM Rafael Gonzaga ***@***.***> wrote: As a person who reviewed a bunch of those reports, unfortunately, I agree with its removal. We have tried a few times to make its boundaries clear, and to be honest, it's still quite confusing (See: nodejs-private/node-private#448 <nodejs-private/node-private#448>). I'm also attempting to improve it at nodejs/security-wg#1255 (comment) <nodejs/security-wg#1255 (comment)>. But, its scope is too large that I'm afraid we will never be able to handle all those edge cases. cc/ @bmeck <https://github.com/bmeck> for awarness — Reply to this email directly, view it on GitHub <#52575 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZJI6AYQK6JFIT6KA6B63Y57EO7AVCNFSM6AAAAABGMYJVU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANRTHA4TMNBYGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[4xpl0r3r]

My reports pushed you to make this thinking and this decision, but my reports are invalid as “informative”. That’s how you treat the researcher spent time on your experimental features.

[avivkeller]

My reports pushed you to make this thinking and this decision, but my reports are invalid as “informative”. That’s how you treat the researcher spent time on your experimental features.

I don't think any one person is responsible, and it's a team effort for any decision to be made. Instead of being upset over it, we should be happy that NodeJS is changing for the better.

[4xpl0r3r]

My reports pushed you to make this thinking and this decision, but my reports are invalid as “informative”. That’s how you treat the researcher spent time on your experimental features.

I don't think any one person is responsible, and it's a team effort for any decision to be made. Instead of being upset over it, we should be happy that NodeJS is changing for the better.

Thank you for your reply, but the related vulnerabilities are reported through Hackerone. I spent days and nights to discover security issues to earn reputation and bounty,. They decided to remove unsecure feature after reading my reports, but leave me nothing but a "informative" which equeals 0 reputation. Do you believe it's fair for me?