[cap-talk] Reducing Ambient user authority in a Type Safe/Memory Safe OS.

[David-Sarah Hopwood]

Ben Kloosterman wrote:
> I note this powerbox is a form of App-> User escalation  and would be
> limited by what the User ( actor) can do.

Some comments about this "escalation" concept:

Pure capability systems never perform escalation in the sense that applies
to, say, a Vista UAC prompt, which changes the effective principal under
which a program runs.

The file chooser powerbox is able to delegate the authority to access a
file to the app instance because the powerbox already had that authority.
The app instance is able to communicate with the powerbox because it already
had that authority (delegated by the shell when it launched the instance).
There was no "escalation" of permissions; just communication and delegation.

Systems like Vista need escalation because the only commonly used ways [*]
they have to dynamically give permissions to a given process, are:

 - to change the permissions of the principal under which the process
   is currently running (which would also affect other processes), or
 - to make that process run under (or impersonate) a different
   principal ID.

A capability system, OTOH, can dynamically delegate the precise permissions
needed, just by sending the process a message. Understanding this as
"escalation" seems like a tortured interpretation to me.

(To go into the deficiencies of various escalation mechanisms would be a
little off-topic here, but note that in Vista UAC, for example, the
authority to prompt the user to escalate is ambient. We definitely do not
want anything like that.)


[*] It may be possible to transfer HANDLEs in Windows or file descriptors
    in Unix between processes, but that's not the common usage of those
    systems' access control systems.

> I suppose there are really 4 forms of escalations here
> 
> -          When a explorer or folder invokes an app by calling the document
> the app needs to convert a browse and execute by association capability to
> a R/W . So this is escalating a given Capability to a higher one.

No. The explorer necessarily already had the authority to write to the
document file, and is just delegating this to the app.

> -          Escalating from an app to a user whether this is via a prompt or
> automatic. Obviously automatic is desirable. 

I don't know what you're referring to here. If you mean the file chooser,
then as explained above, that is not escalation.

> -          Escalating from user to group ,group with admin rights or Super
> user.  The main thing here is groups may be cross machine.

If we want to use capability access control across machines, then we need
a distributed capability system. In that case, again there is no escalation,
just delegation of authorities between processes on different machines
(typically, by transmitting unguessable capability representations over
secure channels).

> ( Obviously a
> User (actor) is different form an admin (actor) . I don't think forcing
> people to login as admin is a good idea either that was tried with
> Windows/XP  in NT4/2000  and most home users became admins though the
> separation was retained for servers in Corporate IT.  Even an admin here
> would have greater user authority such as browsing system logs. 

It isn't obvious that a user is different from an admin. As you say,
most home users are admins. That isn't the problem; users *need* admin
authority on their home machines (and many people probably need it on
their work machines as well).

Logging in as admin is problematic not in itself, but because existing
systems give the full admin authority indiscriminately to any process
that the user runs once logged in. That's just insane.

> -          Escalating to some sort of  global privilege you could create
> this when the Capability is created but you would still need an escalation
> system to handle changes.  Technically its easier here have an escalation
> mechanism than propagating Capabilities to all applications. 
> 
> I have a number of concerns about the powerbox mainly that it only covers
> files

What gave the impression that this pattern is only usable for files?
(That's a serious question; if our descriptions of this pattern give the
impression that it's restricted in that way, we need to fix them.) It is
usable for any object.

> and is hence a subset ( though obviously any automatic passing on of
> capabilities should be good) . eg how do you grant access to the systemLog
> file for some apps when can't even browse it as a user.  Escalating to admin
> rights seems the best way . 

To grant access to the systemLog file, the granting subject must have
access to it. That's a basic principle of access control: you must not
be able to grant access that you don't have.

If the user is an admin, then they do have authority to access the
systemLog. Whether they have to type in a password before they can
access it is a separate issue, but note that having the user accustomed
to typing in adminstrator passwords after they have logged in is liable
to cause as many security problems as it solves.

> Anyway I think the primary goal everyone agrees to is to have minimal
> starting privileges and the secondary goal is to infer as much security
> automatically as possible while still being specific.

Minimal starting authority *per process*, for almost all processes.

The main form of inference about permissions used in capability systems
is that authority is bound to designation, i.e. if a subject designates
a given object in a message, it is inferred that it wants to transfer
the permission to invoke that object (and therefore the authority that
such invocation allows). That this inference works well in practice is,
I would say, the primary basis for the security of capability systems.

> Consider Install popup 
> 
> 
> Green Dialog - Word processor ( Escalate to user rights) 
> 
> This app  desires r/w access to your .doc files 

This is *far* in excess of the authority that a word processor should
have. Each instance of the word processor should only have (at most)
R/W access to the file that has been opened in that instance. Using
the chooser powerbox pattern, it's possible to achieve that without
complicating the user interface at all.

I'll stop there to keep this post a reasonable length and let you reply.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091217/3bba125a/attachment.bin