Enforce role-based/execution context access control to KV tables

[eddyashton]

We currently have a whitelisting system for preventing access to sensitive tables during Lua execution. We should extend this to apply to all table accesses elsewhere in CCF. There are several categories of table:

• Public service tables. These are unencrypted in the ledger, and readable by all transactions. They should only be written to in a service execution context. An example is the Signatures table.
• Internal service tables. These are encrypted in the ledger, and only readable by privileged node-created transactions. They should only be written to in a service execution context. An example is the PBFT Requests table.
• Governance tables. These are unencrypted in the ledger, and readable by all transactions. They should only be written to in a member execution context. An example is the CCF Users table.
• Application tables. These may be encrypted or unencrypted. They should only be readable and writable in a user execution context.

We should always know what context a transaction is executing, and pass this when requesting tables. Attempting to access table which is not accessible in the current context will raise an error.

We may need to narrow/alter the execution context within a single transaction. For instance it may begin in a service context, able to record a Request, but be narrowed to a user-context (preventing access to private service tables while granting access to application tables) before being passed to the application endpoint. There may be additional access checks imposed on top - for instance in the member frontend we want to prevent constitution-defined actions from breaking invariants on core governance tables.

[achamayou]

The last example (preventing writes to governance tables that do not go through predefined governance calls) was spotted and discussed in #806.

[eddyashton]

As first part of this we need a way to identify the different types of tables. Following dynamic table creation, we believe it should be possible to encode this information purely in the table's name, in the same way we currently use the public: prefix to indicate unencrypted tables. This will let us add quick ACL support to the js_generic runtime.

We already have a ccf. prefix for all the governance tables, though we also use this for the special 'service' tables. We will need some way to distinguish those, and should try to settle on those names now. We should also spread the public: prefixing requirements to all table names, even while some are still statically created.

I propose:

• public:ccf.members - a governance table, only written to by auditable member-driven proposals
• log_records - a private encrypted app table
• public:_ccf.signatures - a publically readable table, but written to by the service/node-started transactions
• _ccf.bft_requests - a private, encrypted service-written table

public:ccf. is a little redundant - the ccf. prefix always indicates a public table, but the public: prefix is included for consistency.
_ccf is a distinct prefix indicating extra-special service tables, optionally public or private.

[eddyashton]

We had a discussion and settled on some different prefices:

• ccf.gov. for governance tables
• ccf.internal. for internal service tables
• reserving ccf. for future use, disallowing it for apps

[achamayou]

This is now complete in my view:

1. For JS code, js_kv_lookup() sets the correct rules based on security domain, access category and context->access.
2. For C++ code, no particular restriction exists beyond auditing the code authorised to run, because none could be complete under the rules of the language.