constrain mailbox to devnet config, to protect against c-list/liveslots DoS attacks

[warner]

What is the Problem Being Solved?

One way to attack a vat is to send it messages that induce a storage obligation (many of these are enumerated in #5953). If the target vat does not deliberatly (or accidentally) hold on to the received data, then our GC implementation can help mitigate a chronic attack (in which no single message is a problem, but the long-term accumulated state might be). But our lack of adequate GC tracking of Promises means that imported vpids will incur a RAM cost that cannot be shed until the attacker decides to resolve that promise.

If generalized swingset-level messaging access to a vat also enables the sender to kill a vat (or at least drive its RAM usage high enough to interfere with operations), then maybe we change our attitude towards that access, and treat it as a closely-held authority. If we go in that direction on our chain, the practical outcome would be that we stop provisioning Mailbox access for all accounts. Signed messages that are delivered to the on-chain smart wallet aren't a problem (those always arrive as strings, and the trusted smart-wallet vat decides what to send to other vats in response). The only pathway for arbitrary swingset messages (bearing vpids and creating Promises) to enter into the kernel from external parties is through the Mailbox.

That would mean denying ag-solo access by default, which would require:

• 1: most accounts to be able to do their business entirely through the smart wallet
• 2: some sort of governance mechanism to decide which accounts are allowed Mailbox access
  • I think we need this for contract installation, at least, but we should probably talk about the contract installing experience and see if maybe it should involve something similar, in spirit, to the smart wallet (and driven by a signed string delivered over the bridge, rather than a E(zoe).installBundleID() delivered over the mailbox)

This would be at odds with our general "vats everywhere" philosophy. In the long run, we want metering and fees to be the defense against resource consumption attacks (the message sender can hand you a promise, but they have to pay for it, and their cost goes up as your available resources get consumed).

I don't know that this is feasible/practical, but I wanted to start the discussion.

Description of the Design

If implemented, we'd need to change our provisioning process to omit the E(comms).addRemote() and E(vattp).addRemote() steps.

@dckc mentioned that the process already has a flag to enable the smart wallet setup or not, so maybe we could add a flag to enable/disable the comms/mailbox portion, and then set that flag to false.

We'd also need some mechanism to mailbox-provision accounts when necessary, and a governance mechanism to trigger it.

Security Considerations

Mailbox-provisioned accounts would still be capable of attacking vats. The hope would be that the account holders thus provisioned do not choose to do this, and/or their attack could be noticed in time for some governance mechanism to revoke their access before the attack caused damage.

Test Plan

not sure

cc @michaelfig @dckc @erights

[dckc]

The decentral-psm-config.js from #6020 does restrict mailbox access: it provides none at all (unless and until the BLDer DAO decides to use swingset-core-eval to turn it on). This mitigates things like contract installation (#4395 ) and instantiation (#3725 ) significantly.

[dckc]

#6568 re-introduces mailbox access.

[JimLarson]

If provision passes continue to be closely held, we can close this.

[michaelfig]

#6568 re-introduces mailbox access.

The change 6568 introduces requires one of:

a) a provisionpass to get a mailbox (as is used for local development and the upcoming devnet)
b) a BLDer DAO vote to enable the ability to get mailbox access for a finite price

[dckc]

In meetings / discussion Nov 30 we agreed to constrain mailbox access to devnet and not allow it at all as of the vaults release.

As @michaelfig points out above, this is consistent with the approach in #6568 , since we don't plan to issue any provisionpass tokens in production and the BLDer DAO can always vote to refine this mechanism at a later point.