[cap-talk] Wikipedia: Object-capability model - reference vs. capability?

[Jed Donnelley]

At 10:37 AM 1/8/2007, Mark S. Miller wrote:
>David Hopwood wrote:
> > Jed Donnelley wrote:
> >> In defining the "Object-capability" model, do we intend to exclude
> >> distributed (network) systems where any notion of a "capability"
> >> (communicated object reference) must necessarily be serialized
> >> (data)?
> >
> > I'll leave MarkM to answer that...
>
>The Monash system is a fascinating category breaker. As documented 
>by previous
>cap-talk and/or e-lang correspondence, many of us were using the term
>"password cap system" for the kind of cryptocap system represented by Jed's
>Managing Domains, Amoeba, the Web Calculus, CapTP, etc. However, whatever
>these are, the Monash system is something different. Since the Monash folk
>coined the term "password capability" to describe what the Monash system did,
>I feel we must honor that, and adopt a different term. My proposal is
>"cryptographic capability" or cryptocap. However, I have no objection to the
>Amoeba term "sparse capability".
>
>In any case, the Monash system isn't an objcap system either, since for any
>cap and any subject, there exists some bit string which, if the subject did
>guess it, it would be able to exercise that cap. Within the rules of their
>system, it is only infeasible to guess such a number, not impossible.
>Therefore, ultimately, we have to say that access in the Monash system, as in
>a cryptocap system, is knowledge limited rather than permission limited.

Fine.  What I think we're asking is whether being "permission limited"
rather than "knowledge limited" is a characteristic of an object-capability
system.  Making such a restriction seems a bit picky and non-functional
to me.  How do you even state such a restriction in a functional sense
so as not to imply a specific implementation (or non implementation)?
If it works in practice like an "object-capability" system then I believe
we should consider it an object-capability system, whether its permissions
are based on knowledge or descriptors.

Just to again mention another potentially fine distinction, it can be
that even confinement can be enforced by knowledge limitation rather
than as MarkM says, by 'permission.'  That is, before I as a subject am
even able to communicate (send a message) it can be that I'm required to
present some sort of a capability (reference) as data (knowledge).

>A test of any attempted taxonomy of capability systems should be whether it
>can describe the Monash system.

Hmm.  To try to better understand why you distinguish the Monash system(s)
as above I went back and re read what I believe is a relatively 
recent (2001) paper
on Walnut:

http://www.csse.monash.edu.au/~rdp/research/Papers/Password-capabilities_their_evolution.pdf
"Password-capabilities: their evolution from the password-capability 
system into walnut and beyond"

that includes:

"In this system, a capability is a 128-bit string, called a
password-capability, knowledge of which permits some
sort of use of some object.

A password-capability is divided into a 32-bit volume
identifier naming the volume (typically a disc pack)
containing the object, a 32-bit serial number uniquely
identifying the object in the volume, and a 64-bit
randomly chosen password. The volume identifier and
the serial number form a unique object name that will
never be reused in this or any other system using the
architecture."

As far as I can tell from that paper and from previous reading
I've done on this topic, Walnut (and Monash before it) focus
mostly on performance issues dealing with memory/disk access.
While of course the typical POLA value intended from capability
systems is considered a value in Walnut and it's predecessors,
I don't see anything there about how the base objects are
extended or how wrapping/virtualization is done or if indeed it is.

I would be interested to know where these systems run.  That in
support of what community.

Somewhat intriguing is this note:

"There are however some deficiencies in the support
required to implement rule-based mandatory security
policies. These are being tackled in the SPEEDOS
system [15] through the use of 'bracket' routines and a
more sophisticated confinement mechanism than is
possible with the existing Password-Capability System."
<reference to the Bell LaPadula rule based model>

from the above paper.  Sigh.  I haven't been able to find
relevant references on SPEEDOS such as:

Keedy, J.L., Espenlaub, K., Hellmann, R. and Pose, R.D.,
(2000) SPEEDOS: How to Achieve High Security and
Understand It, Proc. CERT Conf. 2000, Omaha, Nebraska,
USA, .Sept. 2000.

I guess it goes without saying that the above authors don't
show up on the cap-talk list.  Is there some other list/community
where they show up on that we aren't aware of?  Some parallel
universe?  It seems to me that would be a great gap to bridge.
If anybody else has some contacts that could prove useful
that would be good.  Otherwise I think I may try a "cold" email.

I'm puzzled why you (MarkM) consider the Monash password
capability system such a litmus test.  Can you perhaps explain
or point to some paper(s) that can provide further clarification?

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070108/542ee933/attachment.html