DAO DAO Upgrade Delegation

[0xekez]

Moved from wiki page as this is likely a better place for this sort of thing.

In order to quickly perform security upgrades a DAO may want to
delegate module upgrade authority to a smaller subDAO. Allowing that
subDAO to unilaterally perform upgrades comes with risks. The subDAO
may swap in a malicious module that allows them to take over the DAO.

To mitigate this risk, I propose a proposal module with the following
properties:

1. Only one "admin" (read: subDAO) may create proposals.
2. When a proposal is created the module pauses the core module for
   the duration of that proposal.
3. (maybe) When proposals are created the admin may select an
   arbitrary block height from which voting power queries are
   performed.

Imagine the following scenario: a vulnerability in a DAO DAO module is
discovered. It either may not be immediately exploitable or may not be
publicly known. A possible mitigation is known. The subDAO delegated
upgrade authority may then:

1. Create a proposal to swap out the offending module, pausing the
   core module in the process.
2. DAO members validate the proposal and then vote on its outcome.
3. Should the proposal be passed members take care to execute it in
   the same block as the DAO unpauses.

Excluding the possibility of a future proposal module that allows the
creation of execution of a proposal in one block, there will be no
window in which a malicious proposal module could execute a message on
the DAO.

Should we choose feature (3) above a DAO will also be able to recover
from a state in which voting power has been manipulated but the issue
has been caught before that manipulation has allowed for a message to
be executed on the core module.

[blue-note]

I think both pausing the DAO and being able to select an arbitrary block height for voting power are critical in the scenario where a security bug has been discovered and a quick upgrade is needed. However, how do we create enough checks and balances to ensure that the upgrade subDAO does not have undue power to take over, especially if they are allowed to choose an arbitrary block height for voting power?

Another thing I've been thinking about is the ability to delegate upgrade authority to another subDAO in general, or even a bot. It's pretty burdensome to ask people to take action to create a proposal every time we have a contract update that requires code migration. What if there were a bot which was allowed only upgrade (migration) permissions, just like the subDAO proposed above? Or at the very least, would auto-create a proposal in a DAO every time there was new code to consume? Again, we'd have to ensure that there are checks and balances such that this bot could be prevented from upgrading the DAO to malicious code.

[0xekez]

Excluding the possibility of a future proposal module that allows the
creation of execution of a proposal in one block, there will be no
window in which a malicious proposal module could execute a message on
the DAO.

This is not the case if a proposal is in a "passed and queued up" state as it can just fail execution until it gets to race the legitimate DAO members' proposal to see who gets there first after the DAO unpauses. Great example of why @Buckram123's work is so important. #385

[nicolaslara]

The authorizations module supports creating and executing proposals in one block, but I think most people wouldn't add authorizations to upgrade the dao (or at least would be very careful when doing that). A preemptive solution would be to include a contract to handle upgrade auths so that users don't go adding their own permissions without the proper checks.

I like the idea of selecting a block height in the future (min x blocks) when updates are executed, but for that to be effective you may also need to add the ability to "unschedule" these proposals.

Another mitigation for takeover during unpause may be that only a set of trusted proposal contracts can execute during the unpausing block.