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