From: marcs <marcs@skyhunter.com>
Replying To: David Wagner <daw@cs.berkeley.edu>
Date: Thu, 5 Dec 2002 22:38:08 -0700
Subject: Re: [e-lang] capability myths demolished!

I am a bit behind on my email, so I am responding to this long out of order: 

On Tuesday 03 December 2002 04:43 pm, David Wagner wrote:

> My conclusion is that there are two different goals one might shoot
> for in a security-aware programming environment: good support for
> the principle of least privilege, and combining designation with
> authorization.  (It seems ACLs can provide the former, even if they
> don't provide the latter.)  And it seems to me that we ought to try
> to understand each of these different goals, if we're going to make
> a fully persuasive case for E-style capabilities systems.

Since we have entered into a long discussion here in which capability as 
authority bundled with designation is crucial,  and since I know that there 
are at least a few new people listening who haven't heard it all before, I 
thought I'd reiterate the reason I myself eventually became passionately 
devoted to this principle (old-timers can stop reading at this point). I know 
that bundling designation with authority is not self-evidently wonderful, 
because it took years for me to understand how important this was, after 
markm had explained it to me and indicated that I should be overpowered by 
the concept :-)

For me, the merit of designation-with-authority became clear only when I 
started writing user interfaces for secure systems.  If designation is not 
bundled with authority, then the user has to take 2 different steps where we 
desperately want the user to have only one step: he winds up having one 
discussion with his computer about designating what he wants to work with, 
and a separate discussion about the security properties. Consequently, 
security becomes a constant in-your-face nuisance. The best example of this 
is Java Web Start, which hopefully most of you have never seen and never will 
see. Java Web Start is Java's attempt to do applications, not applets, that 
have good security properties. It is excruciatingly painful. If you are in 
the Java Web Start text editor, and you request openFile, you go through the 
normal file dialog box and pick a file, and then the system pops a second 
dialog at you to ask you whether you are willing to give permission to the 
application to edit the file that you just picked. The correct answer, which 
even my 12 year old daughter spotted right off, is "yes, of course I give 
permission, I just picked it!" This is authority and designation unbundled at 
its ludicrous best. daw

In CapDesk, of course, the designation and authority are bundled, i.e., a 
single ordinary file dialog box opens, the user picks the file,  and the 
system is smart enough to know that the act of designation was also the act 
of authorization. No extra dialogs, just smooth standard user interface 
procedure.

Having found the profound value of designation/authority in the user 
interface,  I only then came to clearly understand how it performed the same 
function for programmers as well as users (even though I had been using the 
designation/authority bundling correctly for over a year). Since the object 
reference (its designation) grants the authority, there is for the most part 
no special hoop-jumping to get security: you just pass object references that 
you had to pass anyway, and goodness!--suddenly all your objects are confined 
in their own private POLA environments. Though there are circumstances in 
which you do still have to do special things to get security right, at least 
the things you have to do are in harmony with the underlying machinery you 
are working with, you are not fighting the infrastructure in addition to the 
problem.

Anyway, this is the path down which I became convinced of the power of lambda 
capabilities.  Your mileage may differ :-)

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