[cap-talk] A dabblers take on security

[William Pearson]

I'm studying adaptive systems and have come across the need for a
security system similar or possibly identical to capability based
systems. I'm just starting to absorb the language around these
security issues, so forgive any strange usage.

I'm working on the computer architecture level (the world of memory,
interrupts and so forth) so I have to balance carefully resource
issues. I've been reading

www.cs.washington.edu/homes/levy/capabook/

And have been wondering whether there has been much more work on the
revocation of capabilities at this level, as this will be done on a
periodic basis in my architecture. Since the revocation needs to be
global, I am happy with revoking the capability for everyone by
assigning it a new identifier and invalidating the old... apart from
the resource costs that that entails. That will require the system to
keep track of previous identifiers used and make sure they aren't
reused. And also a mapping stage from identifier to address and a
large identifier space in order to prevent collisions. Although
thinking about it as I wouldn't allow anyone to explicitly write a
capability so I don't need them to be strong. I can just use a
concatenation of  a 32 bit representation of today's date and the
object id and capability type, as I probably won't revoke things more
than once per day (famous last words).

My previous tentative approach had been to have the concept of an
owner of an object that could give non-distributal permits to other
processes. When an process attempted an action on something it didn't
own, the architecture would check the permits to see if any of them
covered this scenario. Basically ACLs on a per-process basis rather
than a per-user basis. The owner would know where all the permits were
and be able to revoke them as it had issued them. This seems somewhat
similar to what POLARIS does with each program being a user, but I may
be missing something as I have only watched a presentation on it so
far.

I'm pondering whether you could mimic the easy transmission of
capabilities under this scheme in the following fashion. Allow
resources to have an interrupt that when access on them is failed,
they can do some processing such as challenging the accessing process
for a password and granting a permit if the process can supply the
correct one. Basically allowing the password + resource identifier to
act as a capability so it can be handed to other programs and only
challenging them for the password on the first pass. I suspect (but
may well be wrong) that this scheme would allow the same spectrum of
security arrangements as horton tunnels over ocap, but moving the
resource usage to different points.

The trade-offs seem to be between

Ocap has the negatives of

Increased storage space for longer capabilities over normal pointers
Spreading the capability to all parts of a process that need it

Where as my ACL based one has the negatives of

Storage of permits
Checking the process has access

I'm currently leaning towards ocap, due to the perceived reduced
resource usage (under my scenarios) and cleanliness.

I had only meant this as a brief introduction. Oh well, pointers to
papers that I might find useful would be appreciated (I'm reading an
introduction to horton tunnels at the moment as well), as I suspect
these things have been hashed out a long time ago.

Oh and my adaptive system is based on something similar in spirit to
Agoric systems.  http://www.agorics.com/Library/agoricpapers.html
Though interested in the fake credit of reinforcement learning systems
instead of real money.

  Will Pearson