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

[Ben Kloosterman]

>> >
 >> >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.
 >>
 >You can get a confused deputy any time there is an increase in
 >permission on a delegation.  Consider Norm Hardy's compiler example.
 >Say that I have a capability that lets me read the log file.  If I
 >delegate it to the compiler, and the compiler receives it as a R/W
 >capability, I could induce the compiler to use that capability to
 >clobber the log file.

Only with extremely bad code ..  This is a specific API specifying a file to open ( for RW we are a word document here) . 

I would imagine the code being very similar to 

ProcessRequest  ( FileCapability fileToEdit)
{
	if ( fileToEdit == null) // ensures its not null and correct type
		throw(); 
	if ( fileToEdit.Rights != FileRights.RW) 
	{
		var result = KeyStore.FindUpgradeCapability( fileToEdit)  // trusted code that ensures capability is the same type (FileCapability) and refers to same file/inode
		if ( result == null) 
			throw (); 
		else
			fileToEdit = results;	
	}

	// continue ..
}

I agree in a non strongly typed language OS you probably couldn’t do it.  This way the File Explorer/browser doesn’t have R/W and nothing can convince it to give it a Capability with R/W. 

 >> 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.
 >>
 >WYCSIWYCU: What You Can See Is What You Can Use.  There should be no way
 >for users to be able to see files they can't use.  Allowing it hurts
 >both security and usability.  The right answer is to delegate the right
 >if the co-worker wants to share access.

WYCSIWYCU would be nice. If they share the same machine is there a convenient way to delegate it ?

 >>
 >> 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.
 >
 >One user (or process) delegates the capability to another.  How that's
 >done depends on the kind of system you have.  Object capability systems
 >pass object references, with local proxies for passing over the network.
 >With webkeys you share the URL.
 >
 >You would delegate rights to lots of files by delegating access to a
 >directory holding capabilities to those files.  Delegating to a group is
 >also possible, but the embodiment of the group is different.  In a
 >capability system, the group is nothing more than a container for
 >capabilities that several people have capabilities to use.

That makes sense. The only trouble here is mapping a Capability group /list to a Directory Group see other thread.

 >
 >> 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
 >
 >You said you're using a browser-based interface, so it's easy.  There
 >are no accounts in the conventional sense.  When you as administrator
 >add a user to the system, you create a web page with a link for each of
 >the user's capabilities and give the user an unguessable URL to that
 >page.  This page is the user's powerbox.  The links can be to
 >capabilities for files or other kinds of resources.  Clicking on a link
 >carries out some action or takes the user to a page with fields and
 >other links.  For example, a link to the capability for a directory
 >takes the user to a page with links for the contents of that directory.
 >The link for networking can take the user to a page with a link for each
 >port the user is allowed to use.  Your UI can provide a checkbox for
 >each link on the page, and a Delegate button next to a field denoting
 >the delegatee.  These delegations can be within a machine or across
 >machines.

Ok this will work quite well seems quite simple. Note the UI is RIA which is a weird kind of  browser but is rendered and served from a http page and there is html as a backup.
I can see you can delegate directly to an LDAP tree here with the delegate field adding to Ldap.  www.example.com/AU.SYD.users.bklooste or a group. 
Also see first user on a machine would be an admin user with full right and new users are created with reduced rights , this is not so different. 
Still need quite a bit to make it user friendly but it makes sense this will work very well with right click share in Windows for folders.

Thanks for your time , I know I'm milking the list but my limited budget can't afford a capability security expert and will go to 3-5 FT devs for 2 years . 

 >
 >> 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.
 >>
 >The problem is that people have conflated authorization decisions and
 >access decisions.  Once people understand the difference, they'll see
 >that they can still use LDAP to make authorization decisions and use
 >capabilities as the embodiment of those decisions.  For example, users
 >might worry about delegating to someone who should not have the right.
 >You can build a system that uses LDAP to help.

I agree eventually it will change ( also via peer to peer and home network) but corporate networks will be slow ( organisational policies and structures) and they are such an important market for a strong security OS. 
In the mean time I need a directory tree to work and I think I may add some things to facilitate this 

Eg 
Some default local Capability Lists ( Local groups) eg Admins , Users , Service Admins , Device Admins. And a feature that when you add LDAP group to this list ( which is not really a capability)  any user in that group will automatically get all these capability list right when he accesses the capability machine. It won't compromise security , will only be used in enterprises and it will keep the admins happy.  Kind of interested ( but prob wont implement) in the idea of storing all Capabilities in an LDAP tree a trusted module can pull it out of the tree and cache it locally and you can also store it in other trees (AD,NDS) ; it would solve the issue of trying to locate all users in the network as well .


Regards, 

Ben