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

[Ben Kloosterman]

>> Hi Alan ,
>>
>> The first form escalation is merely someone passing a browse
>> capability to the app to indicate a file which the application
>> escalates internally to R/W Capability since the browser may not have
>> r/w
>
>I'm confused as to why you think the browser doesn't have r/w authority
>to the file.
>
>If the browser is able to launch an app instance that will have r/w
>access to the file, then the browser *must* effectively have r/w
>authority to the file, since it could just make up an app that it
>controls and then pass the r/w capability to it.
>
>(It would be possible for the browser to use file capabilities that are
>sealed up to the point at which they are passed to the app instance.
>This would reduce the size of the part of the browser code that needs to
>be reviewed in order to conclude that it only passes r/w file caps to
>applications that it launches, and doesn't use them itself. However, in
>principle this does not reduce the browser's overall authority.)
>

In a full type safe Object Capability system you can grant capabilities and rights that are much more fine grained eg you can grant access to the Move API without access to the Read and Write API  (though the granter of the Move must have the access). Similar things go on with the network stack you can give access to the body but not the Ip/TCP header without the R/W capability there is no way to do the R/W.  The only question to ask is the extra layer of granularity worth the complexity. I supposed you could argue that the browser could try to manipulate the Move API and try to do a R/W  but in practice that’s pretty hard.

Note there are 2 variations of this the first is a to treat Move/Browse/Delete as full rights similar  to R/W , the second is to just build it on top of normal R/W rights and restrict it through lack of access to the API. 
 
>There is no escalation mechanism in typical capability systems. None at
>all.
>This is a feature: escalation, elevation, impersonation, setuid, etc.
>are almost impossible to reason about or use correctly.
>
>> ( in my case the  folder
>> Browser can have move/browse/delete but not rw even though the move
>> and delete uses r/w the browser doesn’t have access to the lower level
>> API)
>
>No it can't. If a subject can move and unlink arbitrary directory entries
>in the user's namespace, then it can effectively write the file at any
>such directory entry (even if it can't write a particular file object).
>"Don't prohibit what you can't prevent."

Yet its trivial to not expose the API , is this not a good form of prevention ?

>
>> 2 things I don’t think CapDesk covers very well
>
>Bear in mind that CapDesk is a prototype.
>
>> -          The desire by admins ( and hence organizations) to allow
>only
>> system/security admins to approve certain functions which may includes
>> installing applications in some organizations.   This includes the
>> centralized control of rights.
>
>Admins may think that they need centralized control of rights. This is
>very rarely in the interests of users. Indeed it just results in users
>spending a significant amount of time figuring out how to bypass this
>apparent control, and usually succeeding.
>
>(Note that if capability advocates often express opinions like that in
>the above paragraph, it's not because capability systems are less able
>than non-cap systems to provide the appearance of centralized control;
>just because we realise that it's futile.)

While I somewhat agree  since I got full access to the main equities file server at a major merchant bank once and kept it for years and it is rarely in the interests of workers but I don’t think its correct in many cases, organisations have Chinese walls , software licensing are paranoid about Payroll files on the same computer ( because they rip of people who don’t know) and Like the idea of a trusted security admin. Around 97-2000 I did a lot of work with Citrix/WTS and locking machines down and it determined the success of the project, people complained but they could no everything they needed well and kept IT costs to a minimum but the systems where the users did what they liked ended up with very poor user experience. Anyway  you have no chance of convincing companies to change so at best user administered system should be an option and in many teams it will work best once people start using it more it may take off but it's  not something you can rely on and use as a starting point. Lastly those security admins whose jobs you are replacing will probably have a major impact on whether your product gets approved... 

>>
>> -          Non file type endowments like port/network /service/3D/Audio
>> access etc
>
>These are no different to files. In some cases we might want to
>statically configure all instances of an app to be able to access a given
>object, but the same is true of files.

Logically they are just capabilities but you still need some practical way to get them into the app and File dialog is not appropriate. 

>
>> All we are doing is limiting what rights the user (Actor) can delegate
>> and provide flexibility  in terms of the security model .
>
>How are you limiting what rights the user can delegate?

By limiting what the user has access to eg groups ( which can be centrally managed but don’t have to be) . I don’t think im far off from what others have done ( which is good) , this is what im really interested in. 

>
>> A home user (Actor)
>> for example would have admin rights  and infer these through the File
>> Dialog and installer/Configurer . A cube worker may have to wait till
>> the application is added to his runable list  and he is not allowed to
>> run the installer/configure.
>
>I'm skeptical as to the value of doing that. However, that's just my
>opinion; capability systems are certainly able to support users without
>admin rights, and even without installation rights (although note that if
>they can install any app that acts as an interpreter, including any app
>that supports scripting, then they can still effectively run their own
>code). This does not require any escalation mechanism.
 
I have seen many organization have a lot of success with this ( where it is normally accompanied by the installation of the app on the machine including files , registry settings etc and also central licensing managing)  on a typical Windows or hand held system you have no ability to run scripts ( aside from the Sandboxed Java script) .  Developers are a separate case   and some organizations even put Devs on their own network .  Im still trying to think up a better term. 
>
>> Im no expert and still learning but I can see how a file/Open and
>> setup/configure trusted dialogs can grant privilege  but I don’t see
>> how you can do it without giving the user (Actor) carte blanche access
>> to the machine,  which in some cases is not desirable. Secondly if
>> there are any bugs with these trusted controls you are completely open
>> eg click jacking even though you can’t access the API /message loop
>> there are ways to manipulate UI rendering  so the user (Actor) is
>> clicking on something he shouldn’t normally approve.
>
>A secure operating system needs a secure windowing system. The trusted
>controls need to render themselves correctly, but a secure windowing
>system will draw the "chrome" of a trusted dialog (distinguishable from
>other windows), and ensure that the window is fully opaque and free of
>unredrawn content of other windows, even without assuming that the window
>renders its contents correctly. There should be no trusted controls that
>appear directly in windows controlled by an untrusted subject; that's an
>unsafe pattern.

Most modern systems allow extensive dialog customization and you can make an app window look like a Chrome Dialog. It is especially an issue for UIs ( not just apps ) that may be rendered eg based on Css or Xaml especially how they manipulate the z order and may pass through a 3D engine. It's not an unsolvable problem but you need to be careful here people are very ingenious with UI manipulation.  I like the idea of UAC of darkening the background  (dropping all max z orders by one or require a capability to use max z order and preventing z order changes ) and making the rest of the screen inactive to clicks ( kind of easy with a modal dialog).

Regards, 

Ben Kloosterman