search

anoma / green

https://anoma.github.io/anoma/
MIT License
7 stars 0 forks source link

Guarding "Public" API #784

Closed agureev closed 2 months ago

agureev commented 3 months ago

customer: @mariari performer: deadline: estimated: started: actual: completed: confirmed: dependencies:

As @paulcadman mentioned in one of his reports, by assumption, our public API is usable by anyone who can connect to the Anoma Node. So (regardless of reworked scry) any malicious actor may have an opportunity to write whatever they want using the Storage writing functionality.

This has an easy fix: we have intended Anoma semantics from https://research.anoma.net/t/graphing-anoma-agents-v3/341 which specifically outlines which messages are received by which agents. Every API processing messages that has only inter-engine use (rather than capable of being used by arbitrary user) should be guarded in a specific sense.

Each engine is connected with the Node, which stores all relevant addresses. The engines should, upon launch, read the addresses and then guard the mentioned API so that the calls only get properly processed if the agent calling the message has exactly the address specified.

agureev commented 3 months ago

After discussions with @juped this seems to be less of a problem than initially thought, since we have not decided which functionality to expose for the UI (so we can just not add any writing functionality there). Nevertheless, seems like a good thing to have for nice semantics.

mariari commented 3 months ago

After usage is known, it would be better to start cutting out what messages are safe, we can probably rename this issue to:

hardening and put it on blocked until we get a better idea on how this will be used.

mariari commented 3 months ago

Blocked upon further disucssion

mariari commented 3 months ago

Blocked by specs @agureev

mariari commented 2 months ago

This is no longer blocked @m1dnight knows of a library that can do this for us and with our current designs.

Let us open the following issues:

  1. An issue on blocking the trifecta ( )
  2. An issue on blocking messages for known actor pairs specifically for V2 whenever we see that