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

[Ben Kloosterman]

Thankyou for you message maybe escalation is the wrong word as it is overused...

1) However I still want to cover upgrading the capability from say browse to R/W when a browse capability is received via iPC. 
2) As per my other message how to handle directories trees , rights to non capability servers and cases where the user does not have rights. Eg a Windows UAC popup could be useful, eg support personnel turns on denied rights popups policy, customer starts app , right is denied prompts for other user id , support person enters and then transfers the Capability to the app permanently or temporarily. I termed this escalation also even though it looks like UAC then mechanism is very different as it is just used to transfer the Capability. 


Most rights in these organizations will be centrally distributed, how is this handled do you pass this into the File Dialog ( eg what files it can see)  and Setup installer. Even on my own PC if I let other users use it I don’t want them to see all files how do you restrict this ? Does capdesk sit on top of User/Group/Everyone rights ?

Regards, 

Ben Kloosterman

>-----Original Message-----
>From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
>bounces at mail.eros-os.org] On Behalf Of David-Sarah Hopwood
>Sent: Thursday, December 17, 2009 9:40 AM
>To: General discussions concerning capability systems.
>Subject: Re: [cap-talk] Reducing Ambient user authority in a Type
>Safe/Memory Safe OS.
>
>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.
>