From: Bill Frantz <frantz@pwpconsult.com>
Replying To: Tyler Close <tyler@waterken.com>
Date: Thu, 12 Dec 2002 11:28:07 -0800
Subject: Re: [e-lang] Modelling Blindness (was: "Capability Myths Demolished" (was: Software security workshop))

At 4:41 AM -0800 12/12/02, Tyler Close wrote:
>(Note: this argument applies only to the protection primitives. It
>is possible to build an ACL system using a capability system. In
>this case, the Confused Deputy problem again becomes a problem.
>Avoid ACL designs.)

I am not sure statement this is necessarily true.   The KeySafe design,
which imposed an ACL system on communications between "compartments" which
are implemented using standard KeyKOS programming conventions, still had at
it's base, the KeyKOS capability designation.  A program would designate
which capability it wished to operate on in the normal KeyKOS style.  If
that operation lead between compartments, then the ACL over layer would
have vetted the transfer to ensure that it was permitted by the security
policy being enforced by the ACL layer.

[It occurs to me that one of the things that capability systems make easy
is multiple layers of security policy.   I wish to impose different policies
on computation which results from looking at an item of email than I wish
to impose on my emacs sessions.  I don't know of any ACL systems which make
these layers of policy easy to implement, while capability systems make
them almost natural.]


At 10:32 AM -0800 12/12/02, Jonathan S. Shapiro wrote:
>On Thu, 2002-12-12 at 07:41, Tyler Close wrote:
>> In a capability system, it is only possible to form a request by
>> selecting the permissions that the request should use. It is not
>> possible to form a request without exactly specifying the
>> permissions to be applied.  This eliminates the possibility of
>> confusion.
>
>That is greatly overstated. Designation provides the *possibility* of
>non-confusion. Confusion results from misuse. The ability to designate
>does not preclude misuse. The inability to designate does not guarantee
>misuse, though it renders misuse likely and verification of correct use
>impossible.

I think this statement overstates also.  What is stated as "possibility"
should be "high probability".   There aren't very many production programs
that read or write on the wrong file descriptor, and I believe that is an
exact analogy to the issue of invoking the wrong capability.  (I can't
remember the last time I had a program under development reading or writing
on the wrong file descriptor.)

The confused deputy problem with ambient authority systems is that the
verifier uses the wrong authority to allow an operation.   This confusion is
not possible in a designated authority system.  (It is certainly possible
that the program being subject to the verifier designates the wrong
authority.  I argue in the proceeding paragraph that designating the wrong
authority is very unlikely, even for un-debugged programs.)


In these areas there is also the difference between theory and practice.
In theory all computer languages are equal.   (They are all Touring
complete.)  In practice, as Paul Karger and Roger Schell state in their
paper, "Thirty Years Later: Lessons from the Multics Security evaluation"
(try http://www.research.ibm.com/resources/paper_search.shtml), "Multics
generally did not suffer from buffer overflows, both because of the choice
of implementation language and because of the use of several hardware
features."  They go on to compare the fixed maximum length with automatic
truncation string implementation in PL/I with the C varying length up to
the NUL implementation.  While these issues aren't important in a
theoretical analysis, they are vital engineering differences in the real
world of tight deadlines, incomplete code review, and minimal testing.


By the way, I fully agree that we should concentrate on the misconceptions
that exist about the strengths and weaknesses of capability systems,  and
not stoop to personal attack, either of each other, or of others in the
field.


Cheers - Bill 



-------------------------------------------------------------------------
Bill Frantz           | Sacred cows make the   | Periwinkle -- Consulting
(408)356-8506         | tastiest hamburgers.   | 16345 Englewood Ave.
frantz@pwpconsult.com |         - David Wagner | Los Gatos, CA 95032, USA


_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang