The docs mention that modules can be untrusted, but they are currently must be trusted

[plafer]

Summary of Bug

The docs state:

The goal of the Cosmos SDK is to allow developers to easily create custom blockchains from scratch that can natively interoperate with other blockchains. We envision the SDK as the npm-like framework to build secure blockchain applications on top of Tendermint. SDK-based blockchains are built out of composable modules, most of which are open source and readily available for any developers to use. Anyone can create a module for the Cosmos-SDK, and integrating already-built modules is as simple as importing them into your blockchain application. What's more, the Cosmos SDK is a capabilities-based system, which allows developers to better reason about the security of interactions between modules.

And the object-capability model docs:

When thinking about security, it is good to start with a specific threat model. Our threat model is the following:

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.

The Cosmos SDK is designed to address this threat by being the foundation of an object capability system.

However, this is not currently the case. @colin-axner:

Access to module internal storage is gated by the SDK which does not have module capability support. [...] Atm we have high trust in the modules deployed so it isn't a high concern (any untrusted module could simply drain the bank keeper).

I also have concerns about how the current object-capability model is implemented if we assume untrusted modules, as outlined in this issue comment (it was written with Rust in mind, but also applies to go due to the unsafe package).

Version

v3.0.0

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[crodriguezvega]

Thanks @plafer for opening this issue and raising your concerns.

But the docs that you link are from the Cosmos SDK, not ibc-go, so it would be better to open this issue in their repository.

[plafer]

Oh wow, I must have been distracted... Sorry about that!