[cap-talk] origin of the power box - earlier context

[Jed at Webstart]

At 05:01 AM 10/9/2006, Neal H. Walfield wrote:
>What is the origin of the power box idea?  Mark Seaborn states on
>http://plash.beasts.org/ that
>
>   The powerbox concept appears to have first been proposed by Ka-Ping
>   Yee and Miriam Walker in Interaction Design for End User Security
>   (December 2000).
>
>I find it amazing that this idea was suggested so recently.  How did
>earlier capability systems handle run-time access delegation?
>
>Thanks,
>Neal

I guess it also depends on how critical the "window" or graphical 
aspect is to the notion of a "power box".  The nicety of the power 
box idea I think is that we already have windowing systems where open 
file dialog windows appear separately from windows directly managed 
by our applications ("system" windows) that can in principle be 
managed by a trusted process and then used to allow the user to 
essentially filter resource requests that are dynamically generated 
by applications.  We still have to distinguish the windows that we 
can trust more from those we can't trust as much, but the window is 
already there.

Still, as you say the issue was there in earlier capability 
systems.  I discussed this issue in my "Managing Domains" paper (1981):

http://www.webstart.com/jed/papers/Managing-Domains/

in the context of the NLTSS Operating System:

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

that was running test applications at that time and went on to run 
production scientific applications in the Livermore Computer Center 
from about 1985 until 1995.  I discuss there the idea of having a 
user application (there termed a "utility") request needed resources 
(permissions) from the user's "command interpreter" (the process 
given all a user's permissions and the responsibility to pass them 
out responsibly).

The lead up to the discussion in the paper is in section 15 (from the 
above Managing Domains paper):
_________________________________________________________
15. Human Management of Process Domains
Up to this point we have only considered processes controlling the 
domains of other processes. This level of control allows system 
designers to manage their resource allocation internally for economy, 
reliability, security, and privacy. If computers really are around to 
do our bidding, however, then we humans will have to get into the act 
somewhere.

 From a computer's point of view we are simply input. The input that 
we supply goes into the domain of some process. Generally when we 
begin to use a computer system our input is read by some powerful 
process that can identify us and make sure that we are given access 
to only our authorized resources. This "login" mechanism has been 
discussed ad nauseam elsewhere so we will not consider it further here.

Once we are identified, however, we begin communicating with a 
process that (unfortunately) must have access to all of our resources 
so it can satisfy our requests. Generally the program in this process 
(e.g., an OS command language, job control language, or terminal 
input language processor) does little work by itself, so it is 
usually quite trustworthy. Whenever we want anything done, however, 
it gives some of our resources to some other utility process to carry 
out our bidding. This is where our human domain management becomes important.

It is difficult to understand why people seem to trust computers so 
implicitly. They certainly don't trust us if they can help it. 
Perhaps people feel they have no choice. With many computer systems 
this is true, but it need not be. Why give programs that do our 
bidding a chance to waste resources (economy), mess up resources 
(reliability), or give resource access to our enemies (security and 
privacy)? If we have adequate protocols for process domain control, 
we can give processes working on our behalf exactly the resources 
they need in order to do our bidding.
__________________________________________________________

and then the section that deals with user "utilities" requesting 
resources from the users "command interpreter" is in the next 
section.  I was focused mostly with application initialization, but I 
also noted the possibility of having the utility "request needed 
resources from the command interpreter":
__________________________________________________________
  16. Human Expression of Resource Access Control
A basic problem in this area is to define a protocol that people can 
use for expressing their domain specifications. We consider several 
approaches for such a protocol.

a. Explicit Resource Specification

Using this approach, a person would explicitly name each resource or 
resource group that should be given to a utility process. Since 
parameter information is usually required by utilities in addition to 
their required resources, resource specifications would have to be 
distinguished syntactically. An approach such as this could be 
facilitated by passing some resources by default or with a shorthand 
notation. In spite of such efforts, however, this approach would 
likely prove inconvenient for users. The simple expedient of passing 
all resources to every utility would probably be the norm.

b. Let the Utility Choose

With this approach utilities would request needed resources from the 
command interpreter, either directly or by instructing it how to 
parse the user's request. This approach, might keep utilities from 
inadvertently doing harm to a person's resources, but it still leaves 
every utility in the position of a Trojan Horse.

c. Canned Command Parsing Specification

With this approach, the command interpreter is given predefined 
procedures for parsing the user's commands to decide which resources 
to pass to utilities. These parsing specifications might come in the 
form of macros or tables for a table-driven parser. The 
specifications should be generated or at least reviewed by a trusted 
person (if you can't trust a systems programmer, who can you trust?). 
People can use any convenient command syntax with blissful 
indifference and still be protected from inadvertently or maliciously 
destructive programs. A difficulty would arise only if someone were 
given a new utility and parsing specification as a gift. Anyone that 
would use such a gift specification without review would knowingly 
submit to a potential Trojan Horse. Let the user beware.
_____________________________________________________________

Remember that the above was written during a time before graphical 
user interfaces were widely deployed.  At that time we had rather 
crude means of separating input between that going to the user's 
"utility" (application) from that going to the user's command 
interpreter (e.g. "escape" commands about the status of their 
application, etc.).  It would have been quite awkward, but in 
principle such means could have been used to allow an application to 
request a resource (e.g. file, whatever - generally a capability) 
from the users "command interpreter" (shell, front end, etc.) and 
then to have the command interpreter ask for such a resource from the 
user dynamically and return it to the "utility" if the user named it 
or otherwise allowed it.  I didn't push too hard on this issue in 
that paper because I recognized how awkward that would be to do 
ergonomically and because my primary point was to raise the issue and 
to try to get people thinking about having applications run in 
separate domains (with different permissions) from users and their 
front end command interpreters.  Even in this effort my words fell on 
deaf ears.

Perhaps this will help explain some of the issues faced by such 
earlier systems, at least by the NLTSS system, in this "powerbox" 
area.  In the NLTSS system this problem was never solved because it 
wasn't considered a problem by users or management.  Despite using 
capabilities to communicate permissions internally, whenever the 
NLTSS command interpreter started a process on behalf of a user, it 
initialized it with access to the user's "home" directory (an object 
containing named capabilities - not to be confused with a Unix or 
Windows directory) containing all the user's permissions.  NTSS ran 
production scientific computing at Lawrence Livermore National 
Laboratory from about 1985 until 1995, though active development 
stopped in 1988.

I see this as still a/the fundamental problem today.  Most 
people/users (99+%? - even most expert computer users) believe that 
it's not possible to run applications with restricted 
permissions.  This is pretty much true in today's Windows, Mac, and 
Unix systems, though of course extensions like Polaris or Plash can 
improve (correct?) that situation.  Even most expert computer users 
(e.g. those that are aware of capability systems) believe that 
running applications with limited permissions isn't practical because 
doing so would impossibly complicate the user interface.  This belief 
is simply not true.  What is true is that so-called "Mandatory Access 
Control" systems (systems where access permissions are managed by 
systems administrators and cannot be manipulated by users or the 
processes that act on their behalf) DO make managing systems 
impossibly complex - because the decisions about access control must 
be made by entities (systems administrators - I am one) who have no 
idea what permissions are appropriate for what applications of what programs.

I believe this situation harkens back to some of the earliest 
computer developments (e.g. Multics and Unix) and was then enshrined 
in what I consider the disastrous development of the "Orange Book" 
criteria for computer security.   From some of my discussions with 
Bill Tulloh he seems to be working to tease apart what happened 
during this period and why running processes with limited permissions 
was abandoned in favor of "mandatory" (I quote that term to recognize 
the fact that it can't stop cooperating conspirators) access control 
for users running processes with ambient authority (all user 
authority).  I hope to help as I can in clearing up some of these 
early developments and their consequences.

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