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

Ben Kloosterman bklooste at gmail.com
Fri Dec 18 00:03:48 PST 2009


>From: Karp, Alan H [mailto:alan.karp at hp.com]
>Sent: Friday, December 18, 2009 2:43 AM
>To: bklooste at gmail.com; General discussions concerning capability
>systems.
>Subject: RE: [cap-talk] Reducing Ambient user authority in a Type
>Safe/Memory Safe OS.
>
>Ben Kloosterman wrote:
>>
>> 1) However I still want to cover upgrading the capability from say
>> browse to R/W when a browse capability is received via iPC.
>
>Then you are enabling confused deputy attacks.

How so ? This is merely using the browse capability to indicate which file and then looking up a r/w capability within the application ( and hence upgrading to the higher level R/W)  , If an R/W capability was passed in there would be no need for a lookup .  Your only open to confused deputies if you extend that R/W to look in the users and user groups capabilities instead of the application. 

>
>> 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.
>>
>This doesn't sound like a very scalable approach.  Do I have a support
>person sitting in my cube to enter credentials every time one of my
>requests is denied?

Obviously it would only apply to cases where you can't or don’t allow the right from the acting user eg an application has upgraded itself and now decides it want to open a new port to run a P2P message service. You could just deny it but than the user may wonder why something is not working.

Another example is a user is looking at a directory on a file server and has no access a co worker can login and grant the access via escalation.  The only other alternative I can see for this case is if the co-worker granted the right  via some form of cross machine IPC ( or Directory tree) or it is centrally allocated.

>>
>> 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 ?
>>
>The general idea is that the user has a petname for each capability.  If
>the user doesn't have a capability, there's no name.  That is what the
>CapDesk file chooser does while sitting on top of a Linux or Windows file
>system.


I can see it working for most functions (along with an installer/configurer) and data being created by users is shared from one user to the next but am a bit confused how it works in terms of 

1) How the Capability is shared between Users within a machine and cross machine ( not the technical implementation but how the user does it).  Does a user grant access to another user ? Can this be brought up to groups to rapidly grant access to hundreds of files on a machine eg AccountFiles ?  I suppose it's easy enough for a user to create a group as he merely transfers capabilities to the group. 
2) I struggle with access to many non file things Network ports  , install services , device drivers etc especially on shared machines with many users  ( eg Windows Terminal Server) . Is the first user an admin user and has the capabilities to say create new user accounts ? Remember there is no console/command line here 
3) Central Management- This also includes LDAP/AD/NDS tree integration.   I still think you must provide this to get company acceptance. Getting people to move to Capabilities is a big enough task with adding social structure changes. 


Regards

Ben Kloosterman





More information about the cap-talk mailing list