Summary
Creating a module account should return a dynamic capability. Modules must pass in the dynamic capability in order to authenticate and spend from their module account.
Problem Definition
Currently any module with access to the supplykeeper can spend from any module account so long as they know the name of the module account. Thus, a malicious module can spend funds out of a module account it does not know so long as it knows the name of the other module account. This is usually trivial since module account names are predictable and queryable.
In the user account model, we prevent users from spending funds from unowned accounts whose address they know by requiring a cryptographic signature to authenticate expenditures.
Similarly in the module account model, we can prevent modules from spending funds from an unowned module account by requiring they pass in a dynamic capability bound to the module account to authenticate expenditures
Proposal
SupplyKeeper is passed in a ScopedCapabilityKeeper. Upon creation of a module account, it returns a new Capability which is associated with that module account name.
The module that creates the account can then claim this capability.
SpendCoinsFromModuleToAccount now takes in a capability. supply.Keeper authenticates this capability using the name of the module account. If authentication succeeds, allow the spend. If it fails, return an error
All modules that need to create and spend from module accounts must now have their own ScopedCapabilityKeeper so they can claim and retrieve capabilities.
For Admin Use
Summary
Creating a module account should return a dynamic capability. Modules must pass in the dynamic capability in order to authenticate and spend from their module account.
Problem Definition
Currently any module with access to the supplykeeper can spend from any module account so long as they know the name of the module account. Thus, a malicious module can spend funds out of a module account it does not know so long as it knows the name of the other module account. This is usually trivial since module account names are predictable and queryable.
In the user account model, we prevent users from spending funds from unowned accounts whose address they know by requiring a cryptographic signature to authenticate expenditures.
Similarly in the module account model, we can prevent modules from spending funds from an unowned module account by requiring they pass in a dynamic capability bound to the module account to authenticate expenditures
Proposal
SupplyKeeper is passed in a ScopedCapabilityKeeper. Upon creation of a module account, it returns a new Capability which is associated with that module account name.
The module that creates the account can then claim this capability.
SpendCoinsFromModuleToAccountnow takes in a capability. supply.Keeper authenticates this capability using the name of the module account. If authentication succeeds, allow the spend. If it fails, return an errorAll modules that need to create and spend from module accounts must now have their own ScopedCapabilityKeeper so they can claim and retrieve capabilities.
For Admin Use