[cap-talk] A dabblers take on security

[Jed Donnelley]

On 2/5/2008 12:42 PM, William Pearson wrote:
...
> 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.

What does "non-distributal" mean in the above?  Do you
mean non-delegatable?  That is you're talking about a
situation where A has access to Obj and A and
B can communicate, but A should not be allowed
to grant B access to obj?  If so, this is referred
to as the "Communicating Conspirators" problem:

http://www.erights.org/elib/capability/conspire.html

(though I notice the erights.org site seems to be
unavailable at the moment.  Anybody know what's going
on there?  MarkM?)

Depending on how serious you are about your security
issues, I hope you think carefully through these issues.

> 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.

Ha!  I wondered if anybody would ever take such an approach
seriously.  We considered it in our NLTSS system (to protect
against the data theft problems - e.g. capabilities in
dumps - that capabilities as data can cause) but never
implemented it.  To many problems.  We decided on a
cryptographic approach, optimized with heavy caching.

If you plan to support delegation (communication
of capabilities in messages - without which any
approach seems rather negligibly "capability"),
then you need to be aware that there are dangers
lurking in this per process ACL approach.

You might want to consider sections #10-#12 in:

http://www.webstart.com/jed/papers/Managing-Domains/#s10

What is referred to there as the "Reflection Problem"
is a form of confused deputy.  It's a form of a particularly
pernicious type where the server (recipient of a
capability) has no way of knowing whether the authority
that was putatively communicated to it as a capability
was actually not and just happened to already exist
in it's "environment".

> 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.

Whew.  I think Alan is right that probably the Polaris model
is not applicable.

> 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.

Sorry, but my first reaction is "ug".  I hope the above
proves unnecessarily complex.

> The trade-offs seem to be between
> 
> Ocap has the negatives of
> 
> Increased storage space for longer capabilities over normal pointers

To me the above seems a negligible issue.

> Spreading the capability to all parts of a process that need it

I don't understand the above.  Is a "process" synonymous with
a "domain" in your scheme/thinking?  That is, is the fundamental
unit of computing (an executing thread) that can be separately
protected a "process" (with all the usual meanings, separate
memory space, register set, scheduling, etc.)?

> Where as my ACL based one has the negatives of
> 
> Storage of permits
> Checking the process has access

Take care.  I think you may find more problems with
such a scheme.

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

I would emphasize "cleanliness"!  This can really simplify
your life.

> 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.

I expect something like Horton tunnels are only applicable if
higher level "identities" (e.g. people) show up in you system
for which you need more control than over low level capability
communication ("who" did what, who passed what authority to who,
later opportunities to block just one "who" from access, etc.).

> 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.

Since this is the first we've heard of your project, would
you mind sharing any background that you can?  E.g. commercial
or academic, what organization, what sorts of users, etc., etc.?

Good luck with your work Will!

--Jed  http://www.webstart.com/jed/