[cap-talk] A dabblers take on security

[William Pearson]

On 06/02/2008, Jed Donnelley <jed at nersc.gov> wrote:
> 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?

Kind of but more in the sense that every delegation would have to be
proxied rather than in the sense that you expect that only giving it
to one person means that no one else can use  the resource. I know
that in standard security you want everything to be explicit (and
rightly so), but the lazy manager isn't smart enough to understand the
inner workings of the office so just blames everyone if something goes
wrong and lets the office try and figure out what went wrong.

> 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?)

I noticed it was working only intermittently in the past few days.

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

I'm serious about security in that if A never gives access to obj to
any other domain/process, they should not be able to access it. And if
A revokes all access to obj, all other domains/processes should not be
able to access obj from this point on. Until they regain access in an
approved fashion.

So the nuts and bolts, rather making sure everything cannot be
confused. Although I may be swayed as I read more security stuff. I'll
try and explain why I hold the position I do (for my particular
problem), the lazy manager is supposed to be the only oversight of the
architecture I am making, and it will generally not care how exactly
some process got authority it shouldn't have done. I suppose I am not
interested in transparent security, because the oversight of the
system is not capable of investigating it for itself. I can definitely
see why it is needed in the real world though.

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

Well it looks like I am going for a ocap based architecture, so I
won't have those to look forward to.

> > 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 found it an interesting pattern for security, nothing more.

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

Pretty much, although possibly not separate memory space, although
definitely protected memory space. I am more bemoaning the lack of
ability to do absolute addressing without copying it to each part of
the code, once it is acquired. I'll just have to load it into a
register each time. Not a big deal in isolation but might add up.
Probably nothing to worry about though.

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

You can view my system as "agent based", for what it is worth. So
processes are somewhat people like.

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

Pre-Academic looking to start a PhD on this. I have some supervisors lined up.

> Good luck with your work Will!
>
Thanks. I'll probably just lurk and post a draft of the architecture
to be torn apart by  people when I have it somewhat finished. This is
a very interesting and valuable email list.

  Will Pearson