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

[David-Sarah Hopwood]

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

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

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

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.

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

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

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

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

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20091219/785a11ec/attachment.bin