[cap-talk] What Horton cannot do? (Was: mailkey: transfer of accountability...)

[Jed Donnelley]

At 03:59 AM 6/2/2007, James A. Donald wrote:
>...
>  >
>  > What Horton shows is that an effective mechanism to
>  > determine who did what can be added to
>  > object/capability systems...
>
>Had I been responding to such a criticism, I would have
>found it sufficient to say that one can track who is
>using a capability, and who was issued the capability.

Exactly.  Horton does simply that.  If you have an
alternative, simpler approach, please describe it.

>Horton seems to me the approach of a mathematician,
>rather than an engineer.  Mathematicians infamously
>"solve" problems by "reducing" them to an already solved
>problem, which "reduction" tends to make the problem
>much bigger, rather than much smaller.

Uh - but the problem is solved.  Before it wasn't.
That seems to me a huge contribution.  Now if you
wish to suggest a better engineered solution to
the problem - fire away.  Actually I'll have
something to say about this in a subsequent
message, but for now I think I'll continue to
focus on the problem that Horton is trying to
solve - which I believe to be both concrete
and valuable.

>As a demonstration that capabilities can support
>identities, Horton doubtless works.

To me it isn't "doubtless", but it does indeed seem
to work.  A somewhat surprising result from my
perspective given the "bearer right" aspect of
capabilities.  When a key opens a lock, do you
know "who" was responsible for that opening of
the lock by that key?  Generally not.  Imagine
electronic keys.  Now find a way to achieve this
added value of knowing who was responsible for
the opening of a lock.  There you have the problem
Horton is trying to solve.

>As a proposal for
>an actually useful system, I doubt that it works.

I agree that in it's current form(s) Horton is not
part of a useful system solving important problems.

Still, I've developed capability based systems (e.g.
the NLTSS system that ran production scientific
computing at Lawrence Livermore National Laboratory
for over 10 years:

http://en.wikipedia.org/wiki/NLTSS

) that I believe could have benefited by a mechanism
along the lines of Horton.  It was one of the
implementations that was criticized in this document:

TRADITIONAL CAPABILITY-BASED SYSTEMS:
AN ANALYSIS OF THEIR ABILITY TO MEET THE
TRUSTED COMPUTER SECURITY EVALUATION CRITERIA
http://www.webstart.com/jed/papers/P-1935/

- along with all other capability systems.

The problem that we (speaking generally for
cap-talk) are trying to address is that of POLA.
Namely, replacing the current approach of running
programs where the programs run as a "user" with
all the user's permissions (often here referred to
as "ambient authority" - authority according to
who the program is running) with a system in which
programs can be given just the permissions that
are needed to provide whatever service is needed
of them.

This is a very important practical problem.  Ever
had a system of yours become infected by a virus?
Ever decide not to run a program (e.g. that
executable Christmas card or perhaps a computer
game available on the Internet) because you were
afraid of what it might do to your system if
you ran it with all your authority?

To me that is a much more serious problem than
the spam problem.

Do you have a suggested solution?  If so, by all
means contribute it to the mix.

Capability systems address this problem.  Unfortunately,
they have been criticized as not permitting logging
by responsible parties for what MarkM refers to as
"reactive" control.  The idea of Horton is to demonstrate
that we can get the best of both worlds:

1.  Fine grained capability granting of permissions, and

2.  The ability to delegate such permissions between
responsible identities, with of course the bound
mechanism to determine who was responsible for what
action permitted by a capability (dynamically
communicable permission token).

>  > It does not directly address the problem that you seem
>  > to be focused on.  The problem of spam I accept is
>  > important, but to me it seems quite a bit more narrow
>  > than the issue that we are addressing with the Horton
>  > paper.
>
>The problem of spam is concrete.

The problem of viruses and more generally the threat
from misbehaving programs is equally concrete.

>When dealing with
>abstractions, it is easy to get lost and not notice.

There is nothing abstract about using capabilities
for POLA to deal with the threat from viruses,
except perhaps that over the years frameworks have
been developed to deal with the paradigm.  To argue
against that would be analogous to me to arguing
against object oriented programming because it is
"abstract".  There certainly is an abstraction
there, but the clarity of that abstraction adds value
rather than contributing to "getting lost".

>It seemed to me that Horton is lost and does not know it.

I wish I understood why you feel that way.  Is it any
more than that you don't understand what Horton is
doing?  There is a certain amount of complexity in
the description of the Horton protocol.  That's why
I tried to simplify it in my previous explanation
that you suggested was clearer.

>Building identities on top of capabilities is rather
>like writing a bit wise addition operator in lisp, to
>operate on bit patterns represented as sets.

Uh, except that lisp has a working addition operator.
Capabilities do not have a working identity mechanism.
Are you suggesting building such a mechanism into
capabilities somehow?  Providing, as MarkM suggested
in the Horton paper, a combined system of some sort
that includes both communicable individual permissions
("capabilities" for POLA) along with some sort of
identity notion that will provide for logging
for auditing and "reactive" control?

>It <adding a bitwise addition operator to lisp> can be
>done, and showing it can be done tells us something
>interesting about lisp, but it probably should not be
>done as actual method for performing addition.

I agree, though if the language supports building
higher level operations (Ruby comes to mind), perhaps
with building addition from bitwise operations, and
then can provide the abstraction that can be invisibly
optimized, I see some value there.

Still, I don't believe your analogy is relevant
because, as I mentioned, lisp does have a useable
addition operator.  Capabilities do not have a
usable mechanism for delegation permissions between
responsible identities.

What we are seeking is:

1.  Practical POLA control of permissions.  We believe
the most effective way to achieve this value is through
communicable tokens of permission (objects) that we refer
to as "capabilities" or object/capabilities.

and

2.  Identification of responsibility for permitted
actions.

Any way of achieving the above is fair game.  How do
you believe the above should be achieved James?  Or
do you believe there isn't enough value in doing so
to be worthwhile?  In that case do you believe we
should just continue to live with the problem of
viruses and comparable threats from programs running
with over broad authorities?

I acknowledge the value of reducing spam.  I've spent
a good deal of time working on that problem.  It just
isn't the problem I'm working on with the cap-talk
list.  I admit that I do believe a network capability
infrastructure would go a long way toward addressing
the spam problem.  Still, I don't want to divert to
defend that position here, but will be content to defend
the concreteness of problem that capabilities are
addressing (fine grained object access control,
Principle Of Least Authority) and that Horton adds
to "traditional" capabilities (responsibility
tracking).

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