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

[Ben Kloosterman]

>
 >[Ben, your Outlook email client is making a terrible mess of quoting.
 >Perhaps try <http://home.in.tum.de/~jain/software/outlook-quotefix/>.]
 >
 >Ben Kloosterman wrote:
 >> Alan Karp wrote:
 >>> 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 .
 >
 >Alan is right; there's clearly a confused deputy vulnerability here.
 >If the browse cap gets amplified/escalated to a r/w capability just
 >because it is the browser that is sending it, then "being the browser"
 >is an ambient authority.
 >
 >Note that the approach I suggested in which the browse cap is a sealed
 >r/w cap doesn't have that problem, because the unsealer is not ambient.

No I'm not trusting the browser anyone can send a File Explorer/browser or R/W capability in this case ( obviously this would be a browse capability on the file not the whole dir) . What im doing is making sure that the File Explorer/Browser does not need R/W writes on many things. 

 >
 >> 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.
 >
 >That's not correct. In this particular case, the browser application (if
 >it is acting as the user's shell) has most of the user's authority
 >anyway.

Why is that a good thing if I can reduce it significantly ?
 >
 >>>> 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.
 >
 >Most existing OSes, in their default configurations, don't bother to
 >have built-in access control for network ports at all. So, independent
 >of mechanism, the policy you're suggesting here is far more draconian
 >than I think most users would accept.

By network ports I meant tcp ports ...Windows still requires admin access to listen on a port , is also requires a custom ACL to listen on the port 80 path. Also considering most OS have firewalls I think users are already being obligated to limit the ports. Many things can be done here to integrate it with a firewall , speaking of which with capabilities and ingoing port control you don’t need firewalls. 

You can also improve outgoings as botnets use these.
Eg 
limit access to port 25 to mail programs 
Limit access to port 23 to ftp programs 

Considering with a trusted install/configure program and application metadata it  places no burden on the user why not ?  And im sure if some Trojan tried to get access to outgoing port 80 in an install I would have a good chance of spotting it. 

 >In any case, why would you require a support person to traipse over to
 >the user's cube to type in a password, when you could instead have them
 >send the cap to the user? The pop-up is just a waste of everyone's time.

There is a reason for this in that he is normally trying to see what the problem is and is there anyway. Anyway the way Alan mentioned it with a browser he can just connect to his own machine and grant it without logging out something like a remote desktop session.  

 >
 >>> 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).
 >
 >By encrypted email, for example.

I got this now , I like the use of urls here.
 >
 >> Does a user grant access to another user ?
 >
 >They can.
 >
 >> 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.
 >
 >Groups aren't really necessary as a separate concept, because you can
 >put stuff into directories that you know are accessible to everyone who
 >would have been in a group.

True but sometimes it can get a bit messy I have had people restrict certain files in a dir  etc this will require a list 


 >
 >> 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 ?
 >
 >That's one way of doing it. This isn't really dependent on the access
 >control model; it's a matter of policy.

Got it .

 >
 >> Remember there is no console/command line here
 >
 >There doesn't need to be.
 >
 >> 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.
 >
 >Changing technology usually has social consequences, to a greater or
 >lesser extent. The kind of centralized control enabled by existing
 >systems hasn't been particularly conducive to real security.

I agree but having worked 10 years in large companies it's very difficult to change policy and structure  even at management level yet they are the best market for security.


Regards, 

Ben