[cap-talk] getting authorization from the user and the great insight

[Jed Donnelley]

Since the topic of what user actions should result in
authorizations has come up twice recently in different
threads, I thought I would take this opportunity to
draw them together.

John Carlson writes:

On 10/2/2007 10:08 AM, John Carlson wrote:
> So I'm thinking about how to get authorization from the user, and  
> what ways to do it.  I am sure someone can send me a link for ways to  
> do it.  Here's ways that I can see for the user to authorize the  
> system to do an action:
> 
> 1.  Copy and Paste
> 2.  Drag and Drop
> 3.  Select an icon, file or folder to open or save
> 4.  Typing
> 5.  Mouse click
> 6.  Basically, a lot of GUI stuff.

And then asks:

> My question is, is every action the user makes authorization?  For  
> example, does drawing a line give the system authorization to change  
> an image?  Or does opening the image give the user the authorization  
> to draw a line?   What draws the line between something that requires  
> authorization and what doesn't?  Or is authorization something that  
> is inherent in the design?

David Chizmadia more recently responded:

On 10/3/2007 1:23 PM, David Chizmadia (JHU) wrote:
> > James A. Donald wrote:

>> >> The great insight for creating secure systems is that
>> >> user actions *should* be authorizations, as many user
>> >> actions as possible - that more trusted modules should
>> >> continually harvest from the user's actions information
>> >> about what less trusted modules should be permitted to
>> >> do.  This concept is the key to dealing with the storm
>> >> of attacks that trouble us today. Capabilities are a
>> >> technology that assists in architecting systems that do
>> >> this.
> >
> >     There is strong evidence from IDS/IPS research that this
> > approach has definite flaws and dangers. The most obvious and
> > significant one is that a poorly informed or trained user - or more
> > insidiously, a malicious insider - will continually perform
> > inappropriate actions that are soon interpreted as normal and
> > appropriate and quietly embodied as policy by the UI.

<and result in inappropriate authorizations>
...  and that thread continued.

I believe this suggests an answer to John's question.
To me it seems that the answer is that user actions
that result in authorizations should be carefully
clarified in the UI and made known to the user.

This seems to fit with this private note from David Mercer:

On 10/3/2007 6:17 PM, David Mercer wrote:
...
> I think that James' "harvest as much intention as possible" bit above
> is off kilter in exactly the way that you point out in your example
> Jed.  They may not realize that an action they are taking is being
> interpreted as an authorization under James' scenario.  It seems the
> very antithesis to things like secure window decorations for
> authorization windows and things of that ilk.

My 'ideal' view of computing has many small active
objects running programs in their own authorization
domains (vats, processes), communicating via messages
that may include delegated authority for the purposes
of the message requests.

When people enter the equation as 'user's, they
inevitably have to have some running program (in
an active object with it's own authority)
act on their behalf.  To allow a person full
access to their authority it seems they must
at least start with a running program with
access to all their authority.

This is a program that we sometimes refer to as
their "shell" (I think from the unfortunate Unix
analog which sadly doesn't server the function of
distributing users' authority parsimoniously),
but more concretely as the program that responds
to "power box" requests.

I wish I had a better demo of CapDesk, but here is
the one that Marc Stiegler gave in the Google Tech
Talk series:

http://video.google.com/videoplay?docid=-7961423532989255419#20m16s

MarcS goes into great detail on how the user can get
confidence in the interface that they are interacting
with.  There he shows at least the double click
mechanism (which authorizes the application bound
to an object type to access the object when the
application is initialized) and the "power box"
open file window (which can authorize an application
to access any object granted by the open 'file'
window).  I didn't see him demo drag and drop there,
but perhaps I just didn't wait long enough this
time around when viewing the video.

> What authorization should entering a URL into a web browser give?

I think this is a good question.  I'll tell you the direction I
would like to head in with what I've started calling 'CapDoc'
(better names solicited, I suggest CapBrowser below):

To me the ideal would be that what one enters into a
"browser" is not a URL as we currently have them, but
rather a capability.  For now let's think of it as a
capability as data that bundles the authority to
communicate to the remote service that delivers the
content of the "web page" (designated and access
permitted).

In this case, just as with any CapDesk application,
the browser would only be able to access the remote
Web page because you gave it the capability to
do so by virtue of "pasting" the capability into
its location window.

But then you ask, "What about if the fetched 'Web'
page has embedded links?  E.g. to http://www.google.com/
or the like?"

There it starts getting a bit tricky, because
http://www.google.com/ is not a capability.
The "browser" would not be able to access the
remote site with that link.  Maybe I should
instead refer to "CapDoc" as CapBrowser?
This is the essence of the distinction, to
allow access to embedded capability hyperlinks.

The slight technical challenge lies in providing
for the secure communication of the capability
from the server to the browser, importantly
including the permission to communicate
to the destination server.  How does the
server of the Web 'page' demonstrate that
it did indeed have the capability to
access the remote object?  I believe this
requires a handshake with the server
of the communicated capability.

> What authorizations should not be allowed?:

> 1.  The authorization to change the visual effect of the web browser  
> window.

No - see the CapDesk demo.

> 2.  The authorization to communicate over the network to any machine  
> with standard protocols ( a protocol capability?  Can we grant HTTP,  
> HTTPS and FTP, but not TCP or UDP?)

To "any" machine?  No.  Only to the one machine authorized
by the capability to only access the one object.

> 3.  The authorization for the page to receive user interface events.

Just those events addressed to the browser window.

> 4.  The ability to cache?

Such an ability to cache, even to a shared cache,
can be granted securely - but of course no such
caching capability (intended double meaning) can
allow global access to shared data.

> 1.  The ability to open any file on the system.

Of course not.  Only user authorized access - e.g. through
a power box, drag and drop, double click, etc.

> Obviously you could say that saving the image is the correct place to  
> put authorization...

You started to lose me there.  If the above and what followed is
still relevant in light of the above, please rephrase it
and reply with that restatement.

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