Consider formally employing use of a protection ring scheme for all components as deployed in the agoric net

[b4d2]

What is the Problem Being Solved?

Currently, there are shared services chainTimerService, sharingService, priceAuthority , and privileged services zoe that are exposed to userland (user contracts) in the same context, where the underlying chainTimerService appears to be used as a critical dependency of services like zoe and vaultFactory. Since this resource is addressable by untrusted context (user contracts), it's possible to enter a situation where the underlying resource is abused by a user, resulting in a degradation of service of a core "critical" service. This ambiguity can create the possibility for hidden dependencies on resources that are both used by critical systems, and also untrusted userland context.

Example facilities exposed to the user

home = local + agoric:
{
"http":[Object Alleged: httpRegCallback]{}
"localTimerService":[Object Alleged: timerService]{}
"network":[Object Alleged: vref]{}
"plugin":[Object Alleged: plugin-manager]{}
"scratch":[Object Alleged: scratchPad]{}
"spawner":[Object Alleged: spawner]{}
"vattp":[Object Alleged: vattp]{}
"uploads":[Object Alleged: scratchPad]{}
"agoricNames":[Object Alleged: nameHub]{}
"bank":[Object Alleged: bank]{}
"board":[Object Alleged: Board]{}
"chainTimerService":[Object Alleged: timerService]{}
"faucet":[Object Alleged: faucet]{}
"ibcport":[[Object Alleged: Port]{}, [Object Alleged: Port]{}, [Object Alleged: Port]{}]
"myAddressNameAdmin":[Object Alleged: myAddressNameAdmin]{}
"namesByAddress":[Object Alleged: nameHub]{}
"priceAuthority":[Object Alleged: fake price authority]{}
"sharingService":[Object Alleged: sharingService]{}
"zoe":[Object Alleged: zoeService]{}
"wallet":[Promise]
}

local:
{
"http":[Object Alleged: httpRegCallback]{}
"localTimerService":[Object Alleged: timerService]{}
"network":[Object Alleged: vref]{}
"plugin":[Object Alleged: plugin-manager]{}
"scratch":[Object Alleged: scratchPad]{}
"spawner":[Object Alleged: spawner]{}
"vattp":[Object Alleged: vattp]{}
"wallet":[Promise]
}

agoric:
{
"agoricNames":[Object Alleged: nameHub]{}
"bank":[Object Alleged: bank]{}
"board":[Object Alleged: Board]{}
"chainTimerService":[Object Alleged: timerService]{}
"faucet":[Object Alleged: faucet]{}
"ibcport":[[Object Alleged: Port]{}, [Object Alleged: Port]{}, [Object Alleged: Port]{}]
"myAddressNameAdmin":[Object Alleged: myAddressNameAdmin]{}
"namesByAddress":[Object Alleged: nameHub]{}
"priceAuthority":[Object Alleged: fake price authority]{}
"sharingService":[Object Alleged: sharingService]{}
"zoe":[Object Alleged: zoeService]{}
}

Description of the Design

Creating the context of privileged boundaries for core services would force the identification of critical services, and allow for the opportunity to create trusted instances of that functionality purpose built for that service (e.g. a zoe-specific timer facility, a vaultFactory-specific timer facility).
e.g.

Ring 0: SwingSet
Ring 1: Internal - unexposed vats: vattp, bootstrap, instance timers used for supporting Ring 1
Ring 2: Internal - services required to support the DMZ services, zoe-specific timer, vaultFactory-specific timer
Ring 3: DMZ - user facing: board, zoe, vaultFactory, chain timers meant for user use
Ring 4: Userland contracts

The intent is Ring 3 has very few services, that are well understood in the interfaces they expose to Ring 4, and all resources that are used from Ring 2 are explicit (and ideally instance-specific)

Additionally, this would result in a configuration where only Ring 3 chain services can be exposed to userland, and abuse of any Ring 3 service would not directly impact any service in lower rings. To build on the ocap/injection model, privileges from lower rings can be injected into higher rings, however doing so would be explicit and ideally part of a static analysis/linting validation. By adding this protection, it would be easier to identify when a service is unintentionally exposed to the wrong audience in CI/CD.

Much of this work already implicitly exists (e.g. vatAdmin isn't exposed to the user), however this issue is suggesting that this approach be more formalized, and implemented in a way that can be observed by automated testing, and ultimately be part of a formal API spec of the entire network. This would also include documentation around "why X is in Ring 3 and who X is intended to be used by with what APIs".

[michaelfig]

This is a great suggestion! I've used Rings in the implementation of programming languages in the past, whose outer rings are "safe" but the inner ones are not.

This seems like it should be a bootstrap feature (@dckc), as we plan on using bootstrap mechanisms to deploy all vats, and it already has static enforcement of accessible capabilities.

[dckc]

agreed. ref #4165

[dckc]

Taking another look at this, I'm not sure how it should work...

Since Zoe no longer uses a timer, the observable difference that I can see is a separate timer for VaultFactory vs home.chainTimerService. (plus, the timer given to the VaultFactory is available to anyone who asks via getTerms, though we could address that by moving it to a private arg). Do we not want users to be able to synchronize events with the VaultFactory?

We publish the VaultFactory instance in agoricNames. This is by design, since creating pools is permission-less, right?

[michaelfig]

We publish the VaultFactory instance in agoricNames. This is by design, since creating pools is permission-less, right?

IIUC, the ability to create pools is on the creatorFacet, which is not accessible via the instance handle.

[dckc]

I was confusing VaultFactory with AMM. The AMM public facet has addPool.