Skip to content

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

Closed
wants to merge 7 commits into from
Closed

Core policy specification #352

wants to merge 7 commits into from

Conversation

vdeturckheim
Copy link
Member

Here is a first draft of specification for core policy.

See #327
cc @drifkin @mhdawson @bmeck @mikesamuel @deian

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
Copy link
Member

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

Copy link
Member Author

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

@drifkin
Copy link
Contributor

drifkin commented Jul 23, 2018

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 require to work for user code, in which case you're providing limited filesystem access. Node in its current state doesn't provide enough isolation to safely allow some code to have access and other code to not. You'd either have to "fix" (I'm using scare quotes because it's not really broken, it's just that Node core has always considered user code to be extremely privileged: you can run arbitrary commands using child process, after all) lots of Node code (for example, @deian is giving a talk at Node summit about crafting attacks using the binding layer, which is currently considered to be a private API) and be extremely strict on every code review; or you can put a secure, isolated layer on top like what we're doing at Intrinsic, but that's a ton of work.

@vdeturckheim
Copy link
Member Author

@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.

@drifkin
Copy link
Contributor

drifkin commented Jul 23, 2018

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 |
|------|--------|
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member

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

@mhdawson mhdawson closed this May 27, 2021
@mhdawson mhdawson deleted the branch nodejs:master May 27, 2021 14:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants