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

[Ben Kloosterman]

<snip Replied in other message>

 

 

è All we are doing is limiting what rights the user (Actor) can delegate

 

The only meaningful limit is that users can only delegate rights they have.
It makes no sense from a security standpoint to prevent them from delegating
those rights because they can always use them on behalf of the party they
wish to delegate to.  The only exception is if you’re worried about users
making mistakes.

 

BK> Agreed.  Some rights may  require a stronger confirmation if the risk of
a mistake is higher,

 

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

 

The Actor has some set of rights that it can delegate.  There’s no reason
that implies carte blanche access.  Some Actors will have more rights, some
of them less.

 

BK> But  what about all those OS files , Device drivers , Creating users ,
services and all the other non file rights. ( I talk about this in the other
message more eg is the first user a admin user ) 

 

 

 

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

 

Clickjacking is a particular attack against a browser interface.  As Tyler
pointed out in “ACLs Don’t” capabilities in the form of webkeys defeat
clickjacking because the attacker doesn’t know the URL for the page holding
interesting authorities.

 

BK> Disagree that click jacking is limited to browsers. It affects browsers
because it’s rendered from css and web pages have flexible layout. I  have
seen click jacking with forms by using full  transparency. This is a bit of
an issue for me as it is very likely that the UI I will be using will be
rendered ( prob using Moonlight  from Xaml) , the same rules apply its just
a bit more tricky as it the security interacts with the rendering engine.

 

The problem with thinking of user rights in terms of accounts and groups is
that there is no way to modify the access rules from within the model.  You
need a set of meta-rules outside of the basic mechanism, such as the owner
can change the ACL entry, but “owner” is not part of the basic ACL model.  A
better way of thinking of user rights, whether local or on a shared server,
is to think of a c-list.  The dynamic delegatability of capabilities allows
for modification of the access rules within the model.

 

Agree on the issue of modify the access rule in the model and that  groups
are no issues and are easily modeled by a Capability List .   

 

It’s the interaction with  ACL systems and how to manage if say you have a
Directory Server , A Capability File Server and Older NT File Server (Acl)
, Machines running Windows 7 , Macs and machines running a new Capability
OS.  How do you interact the capabilities  ?   I’m not designing a Research
system but a practical one.  Windows allows you to add Domain groups to
local groups eg you can add Domain Admins to Administrator and Domain Users
to Users and all domain users can the login with User or Admin rights. How
do you model  that any user in the organization can log in get basic rights
from the tree , deploy his allocated applications from the tree and access
his files on the server. I seem to always need this user –Group mapping is
there a nicer way .. I need to rethink.

 

You are right that there is the possibility that the user will make a
mistake.  That’s where Voluntary Oblivious Compliance comes in.

 

BK> But VOC from little what I have read of it  still relies on another
user.  

 

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

 

Any access control model must be able to grant full rights to some users and
restrict the rights of others.  That’s not enough.  You also need to think
about the rights of processes the user starts.  Today, those processes get
all the user’s rights, which is the root cause of the virus problem.
Capabilities make it easy to do better, and there are numerous examples of
how to interface them to standard file systems.  Directories, such as AD,
are one way to specify what might be called the user’s installation
endowment in a capability system.

 

BK>  I think I understand capabilities and its benefits by limiting it to
apps  it aligns well with OO programming and strongly typed/mem safe systems
. What I still don’t get I think is who has the privilege rights  to install
device drivers on say a new system and the “user’s installation endowment”
or “User namespace” and how this is different from user/group rights ? Is
the privilege right just an admin user who logs in first with lots of rights
? 

 

Anyway I need to think on this for a while
 especially the AD integration. 

 

Regards, 

 

Ben   

 

________________________

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/20091218/4e05150b/attachment-0001.html