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

[Karp, Alan H]

Ben Kloosterman wrote:


è 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 ( 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)

R/W is too much authority.  The user wants to grant the browser R/W authority to a single file or perhaps directory.


è 2 things I don't think CapDesk covers very well

-          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.

-          Non file type endowments like port/network /service/3D/Audio access etc

I've asked Marc Stiegler to reply.


è All we are doing is limiting what rights the user (Actor) can delegate

The only meaningful limit is that users can only delegate rights they have.  It makes no sense from a security standpoint to prevent them from delegating those rights because they can always use them on behalf of the party they wish to delegate to.  The only exception is if you're worried about users making mistakes.


è 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.

The Actor has some set of rights that it can delegate.  There's no reason that implies carte blanche access.  Some Actors will have more rights, some of them less.


è 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.  In both cases the concept of user rights is almost meaningless and it is just a container to hold the user group relationship and rights to home directory . Lastly access on  shared servers is normally controlled through such groups.

Clickjacking is a particular attack against a browser interface.  As Tyler pointed out in "ACLs Don't" capabilities in the form of webkeys defeat clickjacking because the attacker doesn't know the URL for the page holding interesting authorities.

The problem with thinking of user rights in terms of accounts and groups is that there is no way to modify the access rules from within the model.  You need a set of meta-rules outside of the basic mechanism, such as the owner can change the ACL entry, but "owner" is not part of the basic ACL model.  A better way of thinking of user rights, whether local or on a shared server, is to think of a c-list.  The dynamic delegatability of capabilities allows for modification of the access rules within the model.

You are right that there is the possibility that the user will make a mistake.  That's where Voluntary Oblivious Compliance comes in.


è By providing an underlying layer with escalations I can limit what the user (Actor) has access to though I still can provide full machine rights  for a  home user (Actor)  based on a policy setting.  In addition it can work well with existing file servers , directories such as NDS and AD of which you have no change to ever replace.

Any access control model must be able to grant full rights to some users and restrict the rights of others.  That's not enough.  You also need to think about the rights of processes the user starts.  Today, those processes get all the user's rights, which is the root cause of the virus problem.  Capabilities make it easy to do better, and there are numerous examples of how to interface them to standard file systems.  Directories, such as AD, are one way to specify what might be called the user's installation endowment in a capability system.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20091217/e083e031/attachment-0001.html