2019-12-17 03:44:44 -08:00
<!--
2022-04-03 02:17:37 -07:00
order: 12
2019-12-17 03:44:44 -08:00
-->
2019-08-26 06:09:18 -07:00
2018-11-14 11:44:17 -08:00
# Object-Capability Model
## Intro
2019-12-10 06:29:46 -08:00
When thinking about security, it is good to start with a specific threat model. Our threat model is the following:
2018-11-14 11:44:17 -08:00
2021-09-28 10:33:58 -07:00
> We assume that a thriving ecosystem of Cosmos SDK modules that are easy to compose into a blockchain application will contain faulty or malicious modules.
2018-11-14 11:44:17 -08:00
The Cosmos SDK is designed to address this threat by being the
foundation of an object capability system.
> The structural properties of object capability systems favor
> modularity in code design and ensure reliable encapsulation in
> code implementation.
>
> These structural properties facilitate the analysis of some
> security properties of an object-capability program or operating
> system. Some of these — in particular, information flow properties
> — can be analyzed at the level of object references and
> connectivity, independent of any knowledge or analysis of the code
> that determines the behavior of the objects.
>
> As a consequence, these security properties can be established
> and maintained in the presence of new objects that contain unknown
> and possibly malicious code.
>
> These structural properties stem from the two rules governing
> access to existing objects:
>
2021-05-27 08:31:04 -07:00
> 1. An object A can send a message to B only if object A holds a
2018-11-14 11:44:17 -08:00
> reference to B.
2021-05-27 08:31:04 -07:00
> 2. An object A can obtain a reference to C only
2018-11-14 11:44:17 -08:00
> if object A receives a message containing a reference to C. As a
> consequence of these two rules, an object can obtain a reference
> to another object only through a preexisting chain of references.
> In short, "Only connectivity begets connectivity."
2020-07-07 03:19:36 -07:00
For an introduction to object-capabilities, see this [Wikipedia article ](https://en.wikipedia.org/wiki/Object-capability_model ).
2018-11-14 11:44:17 -08:00
## Ocaps in practice
The idea is to only reveal what is necessary to get the work done.
For example, the following code snippet violates the object capabilities
principle:
```go
type AppAccount struct {...}
2020-07-07 03:19:36 -07:00
account := & AppAccount{
2018-11-14 11:44:17 -08:00
Address: pub.Address(),
2018-11-20 01:22:35 -08:00
Coins: sdk.Coins{sdk.NewInt64Coin("ATM", 100)},
2018-11-14 11:44:17 -08:00
}
2020-07-07 03:19:36 -07:00
sumValue := externalModule.ComputeSumValue(account)
2018-11-14 11:44:17 -08:00
```
The method `ComputeSumValue` implies a pure function, yet the implied
capability of accepting a pointer value is the capability to modify that
value. The preferred method signature should take a copy instead.
```go
2020-07-07 03:19:36 -07:00
sumValue := externalModule.ComputeSumValue(*account)
2018-11-14 11:44:17 -08:00
```
In the Cosmos SDK, you can see the application of this principle in the
2019-12-10 06:29:46 -08:00
gaia app.
2018-11-14 11:44:17 -08:00
2022-02-14 14:39:35 -08:00
+++ https://github.com/cosmos/cosmos-sdk/blob/v0.41.4/simapp/app.go#L249-L273
2019-12-10 06:29:46 -08:00
2021-04-06 02:50:56 -07:00
The following diagram shows the current dependencies between keepers.
2021-04-16 00:59:21 -07:00
![Keeper dependencies ](../uml/svg/keeper_dependencies.svg )
2021-04-06 02:50:56 -07:00
2020-07-07 03:19:36 -07:00
## Next {hide}
2019-12-10 06:29:46 -08:00
2020-07-07 03:19:36 -07:00
Learn about the [`runTx` middleware ](./runtx_middleware.md ) {hide}