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

Ben Kloosterman bklooste at gmail.com
Wed Dec 16 20:57:58 PST 2009


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

 

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

 

All we are doing is limiting what rights the user (Actor) can delegate and
provide flexibility  in terms of the security model . 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.

 

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

 

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. 

 

Ben

 

 

 

From: Karp, Alan H [mailto:alan.karp at hp.com] 
Sent: Thursday, December 17, 2009 12:25 AM
To: bklooste at gmail.com; General discussions concerning capability systems.
Subject: RE: [cap-talk] Reducing Ambient user (Actor) authority in a Type
Safe /Memory Safe OS.

 

Ben Kloosterman wrote:

 

Ø  I suppose there are really 4 forms of escalations here

 

I don’t understand the need for  escalation.  I assume each application has
an installation endowment granting it the permissions it needs every time it
runs.  In addition, the running instance will need additional permissions
specific to each run, but that information must be specified by the user
(Actor).  CapDesk showed that the user (Actor) acts of designation denoting
what the user (Actor) wants done can be used to infer which of the user
(Actor)’s rights to delegate to the running instance.  Am I missing
something?

 

________________________

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/c286eac4/attachment-0001.html 


More information about the cap-talk mailing list