seeking a better UX for permission management

[sramam]

I am new to deno, so this is somewhat of a mix between a noob-question and a feature request.
Hopefully an issue is the right way to start.

The security aspects of the deno runtime are particularly attractive to me.
However, so many of the modules I am exploring seem to default to a deno install -Afq ...

It's a bit disappointing to see that the first thing one does is to actually disable the security sandbox.

But then, looking at the current command line required to make this work with fine grained permissions, its clear
this is easier said than done. In general, the finer control one desires, the more unwieldy it becomes.

As a newcomer attracted to the security messaging, I'd like a better UX for

1. inspecting the permissions required by a dependency
2. auditing changes between versions of a dependency
3. reverse attribution of permission to a dependency
4. determining if a is permission optional or required for the working of a module (net access for analytics)

All of these look unwieldy if not impossible to accomplish with current tooling.

Wonder if any thought has been given to allowing the developer to register a permission at point of use
and then generate a list of permissions required as an auxiliary artifact - permissions.json or permissions.yml.
This would keep with the single file philosophy of deno but solve the manageability issues raised above.

Something along the lines of:

// within some file in a module that needs permissions,
import { registerPermission } from 'https://deno.land/std@0.99.0/permissions/mod.ts'

const required = true // controls optionality of the permission - allowing limited mode operation or not. 
registerPermission('env', ['VAR1', 'VAR2'], required)
// and so on.

And then from the cli

deno permissions
# or 
deno install

which would generate a white list required and append it to a permissions.json|yml file at point of use.
The file can then be used to provide the end consumer the UX desired - by the deno CLI or 3rd parties.

It seems deno is doing most of hard work of tracking and validating. Just that the end user has no insight,
resulting in deno install -Afq ...

[crowlKats]

inspecting the permissions required by a dependency

Not possible. Dependencies are checked at runtime; so either you have to run the dependency and see what it asks, or read through the codebase.

reverse attribution of permission to a dependency

What do you mean? Do you mean specific perms for a specific dependency?

determining if a is permission optional or required for the working of a module (net access for analytics)

again, not possible.

The whole registerPermission is not possible as well due to this being at runtime

[sramam]

Not possible. Dependencies are checked at runtime; so either you have to run the dependency and see what it asks, or read through the codebase.

again, not possible.

The whole registerPermission is not possible as well due to this being at runtime

My understading of Deno and it's eco system is very shallow and barely beyond the documentation pages.
Worry that I am on the wrong track here, hence the noob disclaimer. Please pardon my ignorance and indulge me a bit further.

It seems that pseudo-run is the term that would best meet my expectations.

Should it not be possible to break up the runtime validation into a 2-step for fine grained control and manageability?

deno install https://some-dependency-url`
# ...  more installs here

# the 2-step:
deno permissions --output ./permissions.json|yml
deno run --permissions ./permissions.json|yml ./main.ts

deno permissions is the pseudo-run that

• starts with an empty list of permissions,
• collects the permissions necessary just as the current run command does
• but instead of validating, dumps that list to a file for user benefit

The generated list can be inspected, modified as necessary, and used to run programs in the permissions regime the user deems acceptable.

For people who are happy with the current state of affairs, they can continue with deno install -Afq ....
Seat-belts are optional after all.

The install -Afq ... thing seems the natural outcome of current implementation. The worst of this is it becomes the "documented" way to install something.

For example, from nest.land installation guide,

Please make sure to use the -A flag to grant all permissions to eggs, so you can enjoy all features seamlessly.

Does it really get much worse than this? A package manager whose job it is to download and upload arbit blobs of code
is asking for a blanket waiver of all permissions - now and into the future.

To be fair, this is from a good citizen that is well-meaning and well-documented. In the next paragraph, they make permissions claims necessary.
However these have to be either be taken at face value or by auditing the code.

The "audit your dependencies" recommendation, much like a paper-raincoat, seems designed to fail.

Well technically, I can run the program without permissions, wait for the complaints and then grant them, but that's
why this issue was labelled title "UX improvements". It's unlikely I'll do it at the finest grain possible on a continual basis.

Am I alone here in feeling a bit naked from a security perspective?

---

reverse attribution of permission to a dependency

What do you mean? Do you mean specific perms for a specific dependency?

Yes - an ability to attribute "this permission" was requested from "that dependency".
If the permissions list can be generated, this should be easy enough I imagine.

[kitsonk]

The only realistic solution is #10183 which would turn permission prompting on by default. Currently, instead of passing -A you could pass --prompt.

[sramam]

Interesting. Thanks for the pointer.

I understand that the control exist if one needs it.

Isn't the fact that so many deno install instructions recommend a install -Afq, a smell that the default behavior is to escape the security sandbox for better UX?

The worst part is that greater the complexity of the dependency, the more likely this is the recommended path.

[sramam]

I was going off the "Dependencies are checked at runtime so it is not possible" point made by @crowlKats

At the risk of exposing my obtuseness, I created a simple repl.it as a POC, to demonstrate what I was intending.

file: samples\reader\reader.ts

Is a sample deno file with a call each to Deno.readTextFile and fetch.

file: src\callee.ts

Is the extractor - that uses a transformation pass to inspect and extract all calls that need permission grants.
It uses the swc module to extract the location of function calls with arguments and location into a collection.
It is implemented as a transformation - with the idea that it can be added as a plugin to the current transformation
that occurs within Deno.

Obviously, it'll need to be extended to deal with all the permissions and full programs. And if we get that far, to integrate
into however Deno invokes swc currently. The point being that it didn't look like too much code and could be implemented
at minimal incremental execution cost.

The module could be implemented as a 3rd party module, but then it would not be possible to use the permissions.json as
a grantor of permissions with deno run. Ideally, one would be able to use deno run --permisions permissions.json to get
this going. The advantage of using this approach I think is that fine grained permissions become manageable and one can
avoid deno run -Af style subversions.

Output

The sample output (on stdout for now):

> npm start

> carte-blanche@1.0.0 start /home/runner/carte-blanche
> node lib/callee.js

{
  "./sample/reader/reader.ts:13:47": {
    "fnCall": "Deno.readTextFile",
    "permission": "read",
    "args": "./people.json"
  },
  "./sample/reader/reader.ts:117:144": {
    "fnCall": "fetch",
    "permission": "net",
    "args": "https://deno.land/"
  }
}

---

I am still wrapping my head around moving to deno from npm-land. If I am missing something, or just being a fool, please let me know and I'll stop.