Grand Unified Capabilities

Hopefully soon, the Standard Model.

Advantages: embodies OrthogonalSecurity, FineGrainedHistory?, BidirectionalCapabilities?

the graph is made of nodes and directed edges CONSTRAINT: permissions for null edges are all absent and unchangeable, so that message sends occur on edge names and versions

on every message send through an edge, for every permission flag change operation on an edge, for every permission flag change operation on an edge's partner, for every delete operation, for every operation on a node or edge (This means that you can change the permissions of edges which have override OFF so long as the message itself managed to preserve override ON by the time it reached that particular edge. This is necessary in order to guarantee that someone somewhere can always delete any particular edge.)

additionally, for every modification timestamps for edges: timestamps for nodes: statistics for edges: statistics for nodes: CONSTRAINT: for frequently updated and/or very small objects, CONSTRAINT: absent/not_absent values for watch, delete, create, write and read are identical. therefore, IMPLEMENTATION DETAILS can store the flags using 2 bits each, for 12 bits total

[watch, delete, create, write, read, override = set/unset][watch, delete, create, write, read, override = absent/not_absent]

when absent, the corresponding flag must be ZEROed

precompute all significant alternatives use the perm blocks as numbers into an array of possibilities which gives go or no go

table conditioned on 6 bits so it's 64 states

of course, this doesn't take into account extended permissions

I'm working hard on this, but it's remaining "unconnected" in my head - I'm having trouble anchoring it to what I think it's trying to accomplish. Perhaps a very specific, very small example of the problem it's solving and how it solves it would let me get a toe-hold.

Study hints: The point of this model is to make security practical to human users. Security is a difficult enough topic. Explaining why a particular abstract model of security is more practical for human beings than another ....

I appreciate that, and I'm trying to understand what you've described here. I think I'm missing some context. Maybe this is a case of "You can't learn something until you already almost know it".

[It would probably help immensely if you started out with a description of what each vertex and edge represents. You describe the data structures so abstractly that I can't tell what they're supposed to model. And ... what's a "null edge"?]

In Smalltalk, a full edge is an object reference and a null edge is a byte pointer. In a filesystem, a full edge is an inode and a null edge is an index into a file's contents (eg, 534th byte).

What are edges and nodes supposed to model? They're supposed to model EVERYTHING. The above model is the fundamental basis for implementing, handling and managing the security in ANY object-oriented system. It's caps based security exposed to normal users in a way that they will understand.

So for instance, if you modified Smalltalk references so they were capabilities as per the above with all permissions absent, and you modified the object engine so it followed the above semantics on message sends, and you had it start off with all permission flags set at the beginning of message sends, then the above would be an exact model of that particular Smalltalk implementation.

What would be the point though? The point would be that as soon as anyone threw in a couple of capabilities (Smalltalk object references) with override_UNset, then anyone making use of these capabilities would slam right into a brick wall of permissions, and then slam into another one, and then another one, and another, and however many the owners of those objects chose to put up. IOW, everything would function exactly as always until the TRIVIAL operation of switching off a couple of permission flags here and there.

Going the other direction, it would also be possible to lobotomize the model so that it represented the actual Smalltalks. But THAT would have no point.

So what can you do with the above security model? Everything that has to do with access security, everything that doesn't require cryptography (a topic that's been done to death in research and which is orthogonal to capabilities). Without any need for any "higher-level abstractions" or "managers", because it would all be built in at a low level. Except of course for things that should be higher-level abstractions like UserDomains. -- rk

I seem some similarities between this and Turing's B-Type unorganized network.

See also GeneralCapabilityModel

View edit of August 5, 2014 or FindPage with title or text search