[cap-talk] A dabblers take on security

[Karp, Alan H]

William Pearson wrote:

> 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.
>
Polaris isn't relevant to your work.  It is based on a hack that let us approximate POLA without changing the applications or the OS.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp



> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of
> William Pearson
> Sent: Tuesday, February 05, 2008 12:42 PM
> To: cap-talk at mail.eros-os.org
> Subject: [cap-talk] A dabblers take on security
>
> 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
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>