Wisely using Deno permissions

[wKich]

I'm pretty new in Deno and heard of one major thing in Deno is "Permissions":

https://docs.deno.com/runtime/manual/basics/permissions/

Deno is secure by default. Therefore, unless you specifically enable it, a program run with Deno has no file, network, or environment access. Access to security sensitive functionality requires that permissions have been granted to an executing script through command line flags, or a runtime permission prompt. This is a major difference from Node, where dependencies are automatically granting full access to everything, introducing hidden vulnerabilities in your project.

And there is a way to allow anything:

Allow all permissions. This enables all security sensitive functions. Use with caution.
Definition: -A, --allow-all

Which means developer must carefully allow access to only required resources for each specific task and avoid using -A. But that I can see in the project confuses me:

https://github.com/denoland/fresh/blob/main/deno.json#L10-L20

  "tasks": {
    "test": "deno test -A --parallel src/ init/ update/ && deno test -A tests/ www/main_test.ts",
    "fixture": "deno run -A --watch=static/,routes/ tests/fixture/dev.ts",
    "www": "deno task --cwd=www start",
    "build-www": "deno task --cwd=www build",
    "screenshot": "deno run -A www/utils/screenshot.ts",
    "check:types": "deno check src/**/*.ts src/**/*.tsx tests/**/*.ts tests/**/*.tsx update/**/*.ts plugin-tailwindcss/**/*.ts init/**/*.ts",
    "ok": "deno fmt --check && deno lint && deno task check:types && deno task test",
    "test:www": "deno test -A www/main_test.*",
    "release": "deno run -A tools/release.ts"
  },

[marvinhagemeister]

The permissions model is extremely valuable when you're running untrusted code. We don't rely on many dependencies and the lockfile ensure that the dependencies cannot be changed without us knowing about it. Running our test suite requires all permissions anyway because they need to read environment variables, start a web server, spawn child processes, make network requests etc. This in essence is pretty much equal to allowing all permissions. That's why a lot of the commands have -A instead of giving access to each permission granularly.

But not every Deno project is like that. If you for example wrote a custom script that does some calculations in memory, it's better to not give it any permissions. If you have a project that only ever needs access to environment variables, only give it permissions to that.

[wKich]

@marvinhagemeister, so allowing all is a common way for most tasks cases (because not many people run untrusted code on daily basis, or writing tasks without side effects). Am I right?

But the lock file doesn't protect you from unknown vulnerabilities or mistakes in newer version after update. It is the same as working under root user and telling that every system binary version is locked and trusted, isn't it?

[marvinhagemeister]

It's not the same as working as a root user as the deno process only inherits the system capabilities of the user you ran it with, unless you ran deno as a root user. The permission model all about tradeoffs you can make and what you see as an attack vector in your particular project. It sounds like you want maximum security, and so passing the least amount of permissions sounds like the most appropriate path forward for you. So in your case I'd recommend changing the commands to not pass -A and enable permissions on an as needed basis.