[cap-talk] getting authorization from the user, GUI transactions/undo

[Stiegler, Marc D]

Comments embedded.

--marcs 


> From: John Carlson <john.carlson3 at sbcglobal.net>
> Date: Oct 2, 2007 10:08 AM
> Subject: [cap-talk] getting authorization from the user, GUI 
> transactions/undo
> To: "General discussions concerning capability systems."
> <cap-talk at mail.eros-os.org>
> 
> 
> 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.

Typing and mouse clicking are tricky as authority-bearing actions,
because you have to be sure the context in which the clicks and
keystrokes take place are correctly understood. A part of the operation
always needs to be the trusted path that makes sure the user knows what
he is dealing with. Given strategies 1,2, and 3, it is pretty evident
where the context comes from and therefore where the trusted path must
be implemented. But with 4 and 5 it is still necessary to answer these
questions on a case-by-case basis. The app that wants the user to answer
an authority-bearing question must not be able to disintermediate the
trusted infrastructure and still gain authority.
 
> 
> 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?

None of the above. Authorization is not inherent, and whether draing a
line produces an authorization depends on which parts of the system are
being considered "trusted" for the specific action, and whether that
part of the system is distinct from the part getting the input.

An example similar to the draw-a-line-authorization: People have often
asked me whether highlighting a section of text in the text editor
should give authority to modify that section of text. Several
observations. First, if you are looking at this through the eyes of the
desktop, the granularity of the action is too fine for the desktop to do
anything sensible. The desktop works with objects the size of files and
urls. When you launch a text editor with an edit-authority on the file,
you have pretty much finished the authorization chain the desktop can
sensibly handle. The text editor can change the text in the file
regardless of whether a particular piece is highlighted. The user has
designated that the text editor is part of the reliance-set for the
whole file.

But now suppose that the text editor has macros written by third
parties, not necessarily fully trusted: visualize a Cap-Emacs if you
will (a thing I did some design work on 6 years ago). Now the text
editor is fully trusted with respect to all the paragraphs, but it has
the knowledge and control needed to confine the macros at much higher
levels of granularity. It is reasonable (indeed I implemented a
prototype for this) for the text editor to grant the macro only-read
and/or only-edit authority on the highlighted text. So the highlighting
is useful as a designator of authority at one level of abstraction but
not at another.

When we first started implementing this stuff, I thought we were really
truly implementing least-authority-by-God. And the granularity of grants
we were making was so fine, that compared to traditional acl granularity
clunkers, this illusion seemed correct. But I was wrong. We are
designating authority, not at the granularity of least authority, but
rather at the granularity of understandable user act of designation.
That granularity changes with context, and with novel insights into how
to create/identify understandable user designations (for example, it
took me 5 years to figure out how to create a File Explorer that didn't
need full read/write authority over everything the user might possibly
want to read or write). And it is never perfect POLA. It is merely an
approximation of POLA so good that traditional computer viruses and
other cyberattacks will find the environment so constraining that they
are rendered, in many important threat models, uninteresting.
 
> 
> What authorization should entering a URL into a web browser give?

In the DarpaBrowser, the browser application as a whole is given full
authority to go anywhere on the web it wants. In that system, typing a
URL gives no authority. Doing better than this in a user friendly
fashion will require one of those novel insights I was talking about,
one that has eluded me for years :-) It may not be worth the effort. The
desperate effort of the common man to escape from the vagaries of his
operating system have driven him to turn the Browser into part of his
TCB. The common man endows even more authority into his browser (paypal
passwords, etc) than the programmers endown into their EMACS text
editors, which are also, for all intents and purposes, part of the TCB
on a programmer's desktop.

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

There must be a trusted path on the chrome that includes a petname/pet
icon designator for the page. The chrome must be rebuilt from scratch in
a new generation of web browsers so that the chrome is indeed a trusted
path. Tyler close recently highlighted for me just how much of the
supposedly trusted chrome is under the absolute and total control of the
page. No one can be surprised that real people see no distinction
between the chrome and the page -- it is all ludicrously untrustable.

> 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?) 

When I implemented DarpaBrowser, I implemented a protocol-based
separation of powers. I have since concluded it makes no sense. If you
can communicate with a site, and if the site is interested in talking to
you, you can transmit any kind of information wrapped in any kind of
protocol. If the site is not interested, and you are going to impose
yourself on it, well, that site is almost certainly using standard
protocols anyway, so only allowing the attacker to use the protocols
that victims accept is hardly interesting. Secure cooperation must be
found by other means.

What does work pretty well is domain-based separation of powers: only
allowing the application object to communicate with specified sites can
be very user friendly and really hammer lots of threat models.

There is a weird special case that stretches this rule: the FILE://
urls. These are all localhost urls, so in a sense this is domain-based
separation of powers, but the Gods of the Web munged the url system to
put this localhost domain power into the protocol field of the url.
Anyway, FILE:// has to be denied in the typical case, whether you call
it a protocol or not.

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

Only user interface events inside the page area, i.e., no general
purpose keyboard sniffing or mouse watching. 

> 4.  The ability to cache?

This is a resource usage question, from an attack standpoint only
interesting in DOS attacks, which we conveniently write off as
out-of-scope :-) So we always grant this authority at launch. There are
good reasons for putting this out of scope, but it would be cool to put
it in scope if we could figure out something useful to do :-)

> 
> What authorizations should not be allowed?
> 
> 1.  The ability to open any file on the system.

Sorry, there are apps that need this authority. Consider Norton's disk
fixer programs. But we can fit out the installer with useful and helpful
information for the user (as opposed to the useless information in
typical security dialog boxes).

> 2.  The ability to communicate with non-standard protocols 
> over the network?

As I said earlier, I have found no threat model in which this is
anything but useless.


> 
> Obviously you could say that saving the image is the correct 
> place to put authorization, but my comment would be, what if 
> we have multiple transactions (undos), and each change to the 
> image actually changed the persistent object, and the user 
> could just run through a bunch of rollbacks to get back to 
> the original image (Undo All, Undo all in session).  Say the 
> transactions were persistent too, so that the user could get 
> right back to the correct transaction state if the system 
> reboots.  We could give the user the option to clear the 
> transactions if they were running out of disk space.  Should 
> every application have transactions? What is the difference 
> between a transaction and a contract?  Invoking a contract 
> would cause the system to flush the transactions (they would 
> move to auditing).  Are constructing transactions too onerous 
> for the application developer?  To the web developer?  What 
> if I am just viewing readonly?  Should I have transactions 
> for navigation?  What happens to the transactions if access 
> to the image is revoked?

Much harder questions, because they are more philosophical. I'm only
answering the easy ones today :-)