uip-draft: userspace permissions #83
Conversation
Proposal for limiting capabilities of gall agents, and related work.
|
|
||
| Agents on the `%base` desk MUST be exempted from this permission control ("run as root"), and any agent MUST always be allowed to issue cards which would delete/revoke one of its created resources/subscriptions. Outside of that, there are no implicit permissions. Even interactions or reads to an agent running on the same desk MUST require a corresponding permission. | ||
|
|
||
| Desks MAY statically specify required permissions, in a `/desk.seal` file. The desk MUST NOT run (install, revive) until the specified permissions are granted. |
There was a problem hiding this comment.
What happens if a the permissions in this file are revoked for a running agent, does this automatically suspend the agent?
There was a problem hiding this comment.
Once live, a desk's required permissions MUST NOT be able to be revoked. To do so, the desk must first be suspended.
There was a problem hiding this comment.
Once live a desk MUST be suspended for its permissions to be revoked
There was a problem hiding this comment.
Reason I chose to phrase as-is: The operative requirement here is not being able to revoke required permissions. Needing to suspend falls out of that, not the other way around.
|
|
||
| Considering the possibility of building "app managers" in userspace, it is important for the kernel to expose permission information and management capabilities. | ||
|
|
||
| xx kernel-style subscriptions follow established pattern, see examples |
There was a problem hiding this comment.
The big unknown for user interfaces is going to be TUI apps and optional permissions. It would suck to force TUI apps to end up using the generic kernel web interface but I don't have an easy solution for how they would get user permissions. Maybe dojo has some affordances
There was a problem hiding this comment.
As discussed during core architecture today:
Given the permission management situation as specified (with Eyre serving a "stock" manager), every UI capable of displaying text has the out of displaying a link to that manager. This is not ideal for non-browser UIs, because it takes you out of context, but it will work.
For dill-based TUIs in particular, there are thorough solutions here, but they require a ton of out-of-scope work. You can imagine dill, or drum, or some alternative having a rendering affordance that's spiritually equivalent to an iframe, letting apps say "show the %perm-manager agent as a pop-over here". Many ways to go in that general direction, all of which are out of scope for this UIP and line of work, but good to note that "truly native" solutions are possible.
| When an agent affected by a permission is not locally known, a permission manager MAY prevent the granting of the permission, even if this would prevent installation. | ||
|
|
||
| The recommendations around "known" agents SHOULD only apply to local agent interactions. Interactions that go over the network SHOULD be presented generically as "sharing data" or "reading". | ||
| xx does that imply "poke over the network" and "watch over the network" perms shouldn't specify agent name? can we meaningfully narrow by mark? |
There was a problem hiding this comment.
Can you meaningfully enforce anything over the network? Once I allow a read, that kinda let's the data go in any real sense even if it was to some ostensible approved agent and the recipient was malicious and did something with the data after that approved read..
Same seems true in effect w/r/t poke over the network; counterparty could claim any sort of stuff about where it is coming from assuming it is properly formed. The limitation here seems like it is confirming that it came from a specific urbit, unless your doing something with a ZKP?
There was a problem hiding this comment.
As discussed during core architecture today:
We indeed cannot meaningfully enforce anything over the network. The only "enforcing" you can do is, on the receiver side, recognize what ship a read or write came from, and dispatch based on that as appropriate. That's the status quo for dealing with ingress, and that won't change.
From the UIP:
This does not aim to extend provenance over the network in any way.
Additionally, re "Once I allow a read", I should emphasize (and do so in the UIP too) that this model restricts what agents on your ship can do. It does not restrict what can be done to agents on your ship. Agents continue receiving all interactions sent their way, and continue to be responsible for checking the src.bowl or using whatever else they want to do to decide whether to respect a poke, allow a watch, etc etc.
Proposal for limiting capabilities of gall agents, and related work.
Gall agents have always had access to the entirety of the kernel API, as well as all other gall agents. Here we propose a permissions system, restricting the capabilities of agents on a given desk until a user grants corresponding permissions. We distinguish between static permissions, required by the desk prior to installation, and dynamic permissions, requested by a desk's agents at runtime.
Draft because of many remaining
xxs requiring further elaboration, but largely ready for initial look-overs.