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

[Ben Kloosterman]

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.

 

Clickjacking requires the attacker be able to overlay a powerful UI view
rendered transparent over a view of the attacker's choosing.  That means the
attacker needs a way to name and display the powerful view.  If displaying
that page requires a capability the attacker doesn't have, the attack fails.
Of course, if the attacker has the capability to the page, the attack is
unnecessary.

 

For a standard browser I can agree with you but im not user here.. since we
are displaying rendered windows in a browser  though I suppose if there are
no security pop ups then click jacking becomes useless. 

 

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

 

I think CapDesk manages to do what you want.  I'd start there.

 

Yeah im getting more confident here whether you store all the ACLs in the
tree or provide a power box to map cap lists to groups is something that can
be decide later. 

 

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

 

I don't know what you mean by "another user."  There are many mechanisms to
enforce VOC.  For example, the user's capability can point to a proxy for
the resource, and the proxy will block "mistakes," i.e., delegations that
would violate policy.

 

Ah yes  I was thinking  too literately from the example here but it does
appear there is a good place to put policy. 

 

Regards, 

 

Ben Kloosterman 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20091221/752ea304/attachment-0001.html