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.
There was a problem hiding this comment.
As a note (IIRC the topic of updating the software source was lightly touched on during core arch), my gut says there is a potential concern around a permissions escalation attack here if a desk can update it's source and then inherit the already granted permissions. This would mean that an attacker, instead of getting the user to grant some 'scary' perms directly to them, would just need to hijack the already granted perms of another desk; You could imagine this along the lines of "Install this desk as a dependency". My point being the better UX pattern might be to re-grant permissions with clarity of who you are installing from.
There was a problem hiding this comment.
Yes, any desk source code modification is a vulnerable point in that sense. The "Desk Sources" section under "Security Considerations" already talks about this:
Changing the installation source of a desk for which permissions have been granted implies trusting the new source with all of the granted permissions. Revoking permissions when changing installation source may be excessive, but warning about this in installation UI could be sensible.
Updating clay to support running off source desks directly (that is, running agents from a[=ship =desk]instead of a necessarily-localdesk) would mitigate this, but such a change is outside the scope of this UIP.
|
|
||
| All `%pass` cards emitted by agents and all `.^` namespace reads performed by agents MUST be subject to permission control by gall. Permissions MUST be granted at the desk level in clay. Permissions on a desk MUST apply to all agents running from that desk. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
How should this account for %spider? Should a thread from a desk %foo inherit the permissions of %foo or the permissions of the %base where %spider lives? Is this implemented in %spider or in the %khan vane?
There was a problem hiding this comment.
Good catch.
Spider is essentially implementing a "userspace within userspace". As such, if it wants to restrict the capabilities of the threads it runs, it itself is responsible for doing so.
Open question on whether threads should be restricted by the desk that supplies them, or by the desk that invokes them. (I'd guess the latter but defer judgement.) Both are possible.
In the former case, the relevant desk is obvious. In the latter case, when spider gets invoked, the sap.bowl should reflect the agent trying to start the thread. Gall has a scry for getting the desk an agent is running from.
Because spider runs from the base desk, it's free to read the permissions that have been granted to each desk from clay. It can then check the thread's effects against those permissions.
The only thing I can't immediately say with certainty is the .^ story. Right now spider runs threads with +mule. Surely it must be possible to replace that with (essentially) a typed +mock instead? That way spider gets to control the scry resolution of threads too, can reject them based on perms if desired.
I vaguely remember there being demons here, but maybe I'm conflating this with attempts at capturing .^ failures in userspace?
There was a problem hiding this comment.
Khan just defers to spider for running its threads. It should be responsible for calling spider in such a way that the caller provenance remains legible.
(The existence of "inline threads" further confirms my suspicion that thread effects should be restricted by their caller, rather than the desk they are supplied by: inline threads have no source desk.)
There was a problem hiding this comment.
We'd also want to have mandatory Spider-supplied parent TIDs for child threads rather than optional user-supplied parent TIDs to ensure correct permission inheritance.
5 participants
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.