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](https://github.com/tendermint/tendermint). SDK-based blockchains are built out of composable [modules](https://docs.cosmos.network/v0.44/building-modules/intro.html), 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

0.45.3

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[aaronc]

The goals stated there have not been achieved by the project yet... There is still the intention and plans to achieve them. However, for now one should assume modules need to be highly trusted and audited. Even if the capability system is better (ADR 033), practically speaking all apps should have high trust in the modules they deploy and the low trust model may never be feasible without sandboxing.

[plafer]

Shouldn't this be reflected in the docs though, until the sdk achieves this goal? As currently documented, it gives a false sense of security to developers, especially newcomers to the project, to integrate third party modules without a thorough audit (although not commonplace currently as I understand it).