Add ACLs to contexts to control read-access to objects. #940
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Another attempt at solving the problem of object access control (an alternative to #930).
This adds 3 separate but related mechanisms to object access control:
The first mechanism (ACLs) broadly isolates objects belonging to each contract from one another. The second mechanism (system objects) lets two subsystems of the host -- auth and events -- freely allocate "their own" objects without perturbing object numbers seen by users and without worrying if they can be seen from the current context. The final mechanism (system mode) allows those subsystems to access system objects from any context, as well as access user objects (eg. for recording objects into the event buffer or authentication trees).
When the auth system calls contracts back for custom auth logic, it transitions back from system to user, and copies the objects of interest from the system table to the object table. Not ideal, but it works.
This is not 100% perfect isolation: there is still a covert channel observable in the allocation of objects. Namely if contract A calls contract B, after B returns A can tell how many objects B allocated by looking at the next available object number. This might be enough to leak information about behaviour B wanted to keep secret. I have an idea of how to close this channel also (changing the system/user split to a global/local split and replacing the ACL with a per-contract indirection table) but that'll take a bit more time. This at least "works" and closes the most egregious channel.
(There are no tests yet, I'm still trying to figure out if this is even the right / final approach to settle on)