denoland / deno

A modern runtime for JavaScript and TypeScript.
https://deno.com
MIT License
98.14k stars 5.4k forks source link

Proposal: add permissions to config file #12763

Open kitsonk opened 3 years ago

kitsonk commented 3 years ago

Context

Currently Deno supports a deno.jsonc configuration file which allow users to provide a configuration file that can provide TypeScript compiler options, lint options and format options.

It does not currently support other information that can only be expressed on the command line, while this proposal is what

Semantics

Examples

An example of a configuration file using permissions:

{
  "permissions": {
    "allow-all": true,
    "allow-env": true,
    "allow-hrtime": false,
    "allow-read": [ ".", "/tmp" ],
    "allow-write": ".",
    "allow-net": "deno.land,nest.land"
  }
}

Considerations / Open Questions

cc/ @bartlomieju @ry

crowlKats commented 3 years ago

In my opinion allow-all should just be

{
  "permissions": true,
}
* Having an explicit `allow` in the keys provides a mechanism to introduce `block` in the future (for example `"block-net": "deno.land"`) giving more granular permissions.

not a fan of this. it would mean you'd be able to do something with the config file that is impossible to do with just flags.

Also I don't think it makes sense to support comma separated items in a string, only arrays should be usable (for the perms that take multiple values)

bartlomieju commented 3 years ago

I'm in favor of the proposal in general (especially combined with tasks/scripts), but I'm not in favor of top-level permissions key. IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions. With this proposal it becomes non-obvious how permissions would be applied to different entry-points.

As for the signature of permissions object I believe we should follow definition used in TestDefinition and WorkerOptions as closely as possible:

https://github.com/denoland/deno/blob/dd91ecef502456ba39495d8e178f8101a87c0e34/cli/dts/lib.deno.ns.d.ts#L144-L275

kitsonk commented 3 years ago

IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions.

But there are currently no semantics in the config file for entry points, so it becomes a chicken and egg.

And specifically the example of the "test" permissions seems to apply a top level "permissions" key that would be the default set of permissions to be applied. Given the current lack of a way to express entry points in the config file, it only seems logical to describe the default set of permissions, and then allow addition/different sets of permissions to be described on individual entry points when they become available.

My key point was that we shouldn't flatten permissions to be different top level keys.

kitsonk commented 3 years ago

not a fan of this. it would mean you'd be able to do something with the config file that is impossible to do with just flags.

That is already the case with TypeScript compiler options.

kitsonk commented 3 years ago

As for the signature of permissions object I believe we should follow definition used in TestDefinition and WorkerOptions as closely as possible:

I am agreeable with that, and it makes sense in the context of "top level" permissions and allowing overriding for different tasks/entry points.

bartlomieju commented 3 years ago

IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions.

But there are currently no semantics in the config file for entry points, so it becomes a chicken and egg.

And specifically the example of the "test" permissions seems to apply a top level "permissions" key that would be the default set of permissions to be applied. Given the current lack of a way to express entry points in the config file, it only seems logical to describe the default set of permissions, and then allow addition/different sets of permissions to be described on individual entry points when they become available.

My key point was that we shouldn't flatten permissions to be different top level keys.

Okay, this is a valid point. You're also right about chicken and egg problem. I guess this is a good way to start iterating on these features. Let's do it 👍

crowlKats commented 3 years ago

not a fan of this. it would mean you'd be able to do something with the config file that is impossible to do with just flags.

That is already the case with TypeScript compiler options.

yes, but those are "external", as in, they arent something made by/for deno exclusively. the only other option for thsoe would implement all options as flags, which would be unrealistic. Also this would mean we have some permission related features as flags, but other features only in config file, making things just more confusing imo by having things "all over the place" (i am aware it isnt as bad as i just made it sound, but my point stands).

Soremwar commented 3 years ago

I'm in favor of the proposal in general (especially combined with tasks/scripts), but I'm not in favor of top-level permissions key. IMO there's not much benefit of having a single top-level definition if most projects contain several entrypoint, each of them requiring different permissions. With this proposal it becomes non-obvious how permissions would be applied to different entry-points.

This could be tackled by allowing composition of config file, an extends of sorts

crowlKats commented 3 years ago
{
  "permissions": {
    "allow-all": true,
    "allow-env": true,
    "allow-hrtime": false,
    "allow-read": [ ".", "/tmp" ],
    "allow-write": ".",
    "allow-net": "deno.land,nest.land"
  }
}

Thought about the blocklist thing again: how about instead

{
  "permissions": {
    "env": {
      "block": ["PATH"],
      "allow": ["HOME"]
    },
    "hrtime": false,
    "read": [".", "/tmp"],
    "write": ["."],
    "net": ["deno.land", "nest.land"],
    "prompt": true
  }
}

so to specify the blocklist, its an object instead of a proper value for the perm directly. this would all us to add blocklist support at some later point as it would be an extension from what it would be without. also this would allow for allowing specifying --prompt behaviour on a permission level instead of just a global level

lilnasy commented 3 years ago

I really like this proposal. It encourages fine-grained control over what directories can be read and written to, for example. At the moment, it's inconvenient to get this precise with command line options.

jsejcksn commented 2 years ago

I really like this proposal. It encourages fine-grained control over what directories can be read and written to, for example. At the moment, it's inconvenient to get this precise with command line options.

@crowlKats When you said

the only other option for thsoe would implement all options as flags, which would be unrealistic

by "unrealistic" did you mean "inconvenient"? My impression is that most software which executes with more than a few flags either builds them using a script or hardcodes them into a script.

Adding additional CLI flags from options actually sounds useful (as no extra filesystem i/o in the form of reading/writing a config would need to happen in dynamic execution).

remyrylan commented 2 years ago

EDIT: I was initially in favor of this proposal as-is, but now after thinking it over the only thing I desire is a flag to opt-out of the functionality to load permissions from the config. I just think about a scenario of updating to a new version of some popular third-party module that's been hacked and having said module write to deno.json to provide new permissions for itself that could be utilized the next time the script is ran.

For the strictest security, I would want to be able to explicitly opt-out of reading permissions from the config and instead require all the permissions be provided via flags... that's what I would always want to run in production.

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

jsejcksn commented 2 years ago

For the strictest security, I would want to be able to explicitly opt-out of reading permissions from the config and instead require all the permissions be provided via flags... that's what I would always want to run in production

Related: https://github.com/denoland/deno/issues/13452 will become even more important if this feature is implemented

sno2 commented 2 years ago

Now that we have permissions scoped to tests, it would probably be best to just unify a deno.jsonc config property permissions with Deno.test's permission object type. Also, when it is string | URL we can just only accept string. I think it would be a bad idea to have two different type of objects for specifying permissions and this would give us a chance to have a uniform behavior.

Edit: I hid this because I did not realize that this was already mentioned above.

ry commented 2 years ago

I'm in favor too. Added to 1.22 milestone.

bartlomieju commented 2 years ago

I'm working on this in https://github.com/denoland/deno/issues/12763.

For the first pass I think we should cut the scope a little bit, namely by not supporting permissions in remote configuration file. Instead we should print a warning, pointing to an issue about it. The reason is that it will cause a bifurcation in behavior depending if the config file is local or remote, in the former case we'll be resolving allowlists relative to config file, while in the latter we'd have to fallback to CWD. I think this is gonna be a surprising behavior.

jsejcksn commented 2 years ago

I'm working on this in #12763.

@bartlomieju You linked to this issue 🪞. Did you mean #14520?

bartlomieju commented 2 years ago

Yes

stale[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

GuillaumeAmat commented 2 years ago

:eyes:

happy-little-one commented 2 years ago

there is a short way to achieve this, run this in window terminal:

alias d="deno run --allow-net --allow-env --allow-read --unstable" $*

and you then d foo.ts

pkoch commented 1 year ago

On #14520, @bartlomieju said:

There's no consensus about this feature in the core team. Closing for now.

Is now maybe an ok time to retry corralling consensus?

cawa-93 commented 1 year ago

I would like to be able to set default permissions for each command individually. Example:

{
    // Global permissions
    permissions: {
        'allow-read': ['./config.json']
    },
    // Additional permissions for any `deno test` command
    test: {
        permissions: {
            'allow-read': ['.'],
            'allow-write': ['tests/fixtures'],
            'allow-env':true,
        }
    }
}
jsejcksn commented 1 year ago

Isn't this kind of functionality practically already in place, provided by the task runner (deno task) and configurable through task definitions? IIRC, the task runner was not yet implemented at the time this issue was created.

bartlomieju commented 1 year ago

Isn't this kind of functionality practically already in place, provided by the task runner (deno task) and configurable through task definitions? IIRC, the task runner was not yet implemented at the time this issue was created.

Yes, you can specify the permissions via tasks definition. The core team's hesitation is coming from the fact that if you specify permissions in the config file, adding the "write" permission allows to then update the config file by rogue dependency that would be able to escalate permissions further. We're currently focusing our efforts on other parts of the runtime, but we might revisit this issue in Q1 2023.

lilnasy commented 1 year ago

Isn't that just as much of a concern right now with the task runner? Task aliases are also vulnerable to being edited by a rogue dependency.

sigmaSd commented 1 year ago

Here is another proposal https://github.com/denoland/deno/issues/17177

It has in my opinion some advantages:

pkoch commented 1 year ago

Maybe the maintainers can define a starting point for the threat model? I feel we're going back-and-forth in a piecemeal fashion. I'd love to have full lay of the land to be able to propose something that's able to be well received.

oscarotero commented 1 year ago

My 2 cents:

sigmaSd commented 1 year ago

My main problem with json config is that you cant express very useful permissions, like --allow-read=cache-dir() or even --allow-cache-dir=cache-dir().join(myapp) in a cross platform way

In my opinion these happens all the time, and neither the current system or this proposal improve on thar, which is why ppl just give up and use --allow-read=all

jsejcksn commented 1 year ago

My main problem with json config is that you cant express very useful permissions, like --allow-read=cache-dir() or even --allow-cache-dir=cache-dir().join(myapp) in a cross platform way

@sigmaSd I'm not sure that I understand this exactly, but it seems like a suggestion of some kind of dynamic value resolution. The ability to audit fully-resolved, static values prior to runtime is foundational to the security of permission configuration.

sigmaSd commented 1 year ago

That's a valid point

It's a dynamic system, it can be improved by putting the permission file in a immutable registery like deno.land but it still is dynamic

dsherret commented 1 year ago

Isn't that just as much of a concern right now with the task runner? Task aliases are also vulnerable to being edited by a rogue dependency.

@lilnasy it's not as much of a concern because it doesn't apply to every deno run/test/etc invocation and with deno task you probably have some idea about what task in what config file you are running. With deno run if you don't have a config file and the script has write permissions, then the malicious script could write one in an ancestor directory which would then be auto-discovered on the next run. With the config file being modified for deno task, it is still something that people should be aware about (along with scripts that modify code that someone will probably execute with elevated permissions), but again, not as much of a concern.

DerZade commented 1 year ago

How about another flag to use the permissions from the config file? Something like --allow-from-config or --permissions-from-config 🤔 Then you would have to explicitly specify that you want to use the permissions from the config. Admittedly that doesn't fix the problem all together, but imo brings it down the a similar threat level we currently have with deno task

dsherret commented 1 year ago

@DerZade yeah, that’s been discussed internally for certain commands like deno test and bench. Basically if you run without the flag it would prompt and show you the permissions to confirm, or you could provide a flag to use the permissions from the config file and override the prompt. This would help prevent people from accidentally running their tests without permissions granted and have it fail halfway through.

For deno run, I’m not sure how useful it is to have permissions in the config file because someone could define a deno task. Anyway, this is just all my personal opinion.

DerZade commented 1 year ago

I agree that deno task helped with this a lot. My personal setup usually includes three tasks, which all execute deno run. One with just the permissions, another one with the permissions and --watch and a third one with the permissions and --inspect-brk. Now I have basically the same task with just minor differences and each of them includes the same (very long) permissions options. So every time I need change permissions, I have to do it three times. That is still bothering me a bit 😅 and why I personally would welcome defining the permissions in the Deno config (or even a external config).

oscarotero commented 1 year ago

Maybe the permissions in the config file could be assigned only to tasks (instead of globally) because there can be different modules that you want to run with different permissions.

I remember an idea I suggested some time ago to include descriptions in the tasks (https://github.com/denoland/deno/issues/14949). Although it was rejected, it had the ability to configure a task using an object with different properties, not only a plain string. This would allow to configure the permissions in a more ergonomic way:

{
  "tasks": {
    "serve": {
      "run": "deno run ./server.ts",
      "allow": {
        "net": "localhost:3000",
        "read": ["./img", "./styles"],
      },
    },
  }
}

It would be equivalent to:

{
  "tasks": {
    "serve": "deno run --allow-net=localhost:3000 --allow-read=./img,./styles ./server.ts"
  }
}
wojpawlik commented 1 year ago

Shebang is aleeady a nice place for permissions, it just doesn't work on Windows: https://github.com/denoland/deno_task_shell/issues/23.

domenic commented 3 months ago

I think I'm running into this problem. I want deno test to come with some permissions. But as far as I can tell, I have to either:

jsejcksn commented 3 months ago

I want deno test to come with some permissions. But as far as I can tell, I have to either:

  • Specify the permissions on the command line every time; or
  • Give up on using deno test and instead define a custom task and remember to use deno task test.

Deno can't know which permissions you want to grant to executable code (whether it's code that's executed by deno run, deno test, etc.) without your specifying them… somewhere.

This is my view of the current state of things: if you plan to locally execute code (more than once using the same options) by interactively typing a command into your terminal, and you don't want to type very much each time to execute that code (who does? 😅), then specifying a task using the task runner is the simplest way to granularly open up the security sandbox — then, like you said, it's as simple as deno task test to run your tests — or deno task start to start your program — with only the minimally necessary permissions defined in those tasks.

However, if you want to grant all permissions (disable the security sandbox) for all test modules whose filenames pattern match by default when running deno test (and all of those modules' dependencies)… then you can always use deno test -A.

Example: `fs_read_test.ts`: ```ts // Requires permission --allow-read import { assertStrictEquals } from "jsr:@std/assert@^1.0.2"; Deno.test("can read the local filesystem", async () => { const fileInfo = await Deno.lstat(new URL(import.meta.url)); assertStrictEquals(fileInfo.size, 298); // This test module is 298 bytes }); ``` Running without any granted permissions: ```txt % deno test running 1 test from ./fs_read_test.ts can read the local filesystem ... FAILED (0ms) ERRORS can read the local filesystem => ./fs_read_test.ts:5:6 error: PermissionDenied: Requires read access to "/Users/deno/fs_read_test.ts", run again with the --allow-read flag const fileInfo = await Deno.lstat(new URL(import.meta.url)); ^ at Object.lstat (ext:deno_fs/30_fs.js:410:21) at file:///Users/deno/fs_read_test.ts:6:31 FAILURES can read the local filesystem => ./fs_read_test.ts:5:6 FAILED | 0 passed | 1 failed (1ms) error: Test failed ``` Running with all permissions: ``` % deno test -A running 1 test from ./fs_read_test.ts can read the local filesystem ... ok (0ms) ok | 1 passed | 0 failed (1ms) ``` ```txt % deno --version deno 1.45.5 (release, aarch64-apple-darwin) v8 12.7.224.13 typescript 5.5.2 ```
domenic commented 3 months ago

Yes, perhaps I was not clear. I want to specify in my config file what permissions deno test should run in, so that people coming to my project can use the standard deno test command. Right now I have to instead include special instructions in my readme for a nonstandard testing command.

jsejcksn commented 3 months ago

I want to specify in my config file what permissions deno test should run in, so that people coming to my project can use the standard deno test command.

This would violate the security concept of sandbox-by-default and explicit granting of permissions: it would be implicit granting of permissions (because configuration files are implicitly resolved).

Right now I have to instead include special instructions in my readme for a nonstandard testing command.

Can you instruct users to type deno task test instead of deno test?

domenic commented 3 months ago

Can you instruct users to type deno task test instead of deno test?

Yes, I can. And then this makes Deno an inferior ecosystem to npm, where to learn how to run a project's tests, I don't need to look it up in the project's readme. I just always use npm test.

dandv commented 2 months ago

As deno run interactively asks for the most granular permissions the code requires, and the user answers, it would be really handy to have an option to save these permissions somehow, in a configuration file, as a tasks entry, or even as a CLI command.

omarcresp commented 1 month ago

following @oscarotero idea, here is a real app example of why having it declare as an object improves the readability of allowing permissions in the deno config 2024-10-18T06-20-25_code

brianpeiris commented 1 month ago

Please consider my proposal #26372 as well. This proposal seems fine, but in my issue I suggest a simpler solution, but one that also supports multiple "profiles" that can be applied appropriately in different contexts. If my proposal is less appealing, I'd suggest adding the idea of multiple "profiles" to this proposal, so that you aren't globally applying the same set of permissions to all contexts. For example, my proposal would allow you to use one profile for deno run and a different profile for deno serve.

mo commented 1 week ago

I hit this as well today for my first deno project. I like having a default profile in deno.json plus the option to specify "-P custom_profile" for projects where it's actually necessary to have two profiles.