-
-
Notifications
You must be signed in to change notification settings - Fork 131
Core policy specification #352
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
Conversation
README.md
Outdated
@@ -126,4 +126,20 @@ The [Node.js Code of Conduct](https://github.com/nodejs/admin/blob/master/CODE_O | |||
|
|||
The [Node.js Moderation Policy](https://github.com/nodejs/admin/blob/master/Moderation-Policy.md) applies to this WG. | |||
|
|||
# Code of Conduct |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are duplicates of existing code of conduct and moderation policies already in the document
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Git sticky fingers on my side, will remove
Thanks for writing this up! I do think that we still have unanswered questions about the attacker model: are we trying to disable access to particular resources for well meaning, yet buggy code, or are we trying to disable access to resources so that malicious code cannot possibly have access to those resources? To illustrate why this is tricky, consider disabling filesystem access. Even if you disable filesystem access for user code, Node still needs to load the user's code in the first place! Also, you may still want |
@drifkin right that's all questions we need to answer. I mostly opened this PR so we have a brainstorm ready for Thursday afternoon. My canonical example is "how could have we prevented the ESLint situation". Disabling network access would have done the trick here. |
Yeah, for sure, we’ll definitely talk a lot about these issues. Re: the eslint issue, remember that it was an install time script that npm ran, which can be an arbitrary (even non-Node.js) command. These policies wouldn’t help against a malicious user trying to exfiltrate data (they could, for example, just use curl or manually run Node with network access enabled). |
## Pre-built-policies | ||
|
||
| flag | impact | | ||
|------|--------| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cjihrig suggested preventing bindings altogether
|
||
Question: | ||
* Do we want to allow policy definition from a file | ||
* How can we make sure modules like linters, that people start from `.bin` never have access to network |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should discuss if the scope of permissions is on files within node_modules/.bin
or if it is in node_modules/linter/*
. In particular I have concerns about if the permissions are self defined within node_modules/linter
in a way that allows linter
to alter the permissions after the first run. I think establishing the authority structure is potentially going to need more care than the feature flags.
``` | ||
|
||
Question: | ||
* Do we want to allow policy definition from a file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are we talking about the:
- requested policies for a given package being put into a file
- the flags enabling features to be put into a file
- the authorized pre-authorized permissions for features being placed into a file
It seems like we might need more than 1 file and/or need to clarify which parts need to live where
Here is a first draft of specification for core policy.
See #327
cc @drifkin @mhdawson @bmeck @mikesamuel @deian