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

[David-Sarah Hopwood]

Ben Kloosterman wrote:
> 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

I'm confused as to why you think the browser doesn't have r/w authority to
the file.

If the browser is able to launch an app instance that will have r/w
access to the file, then the browser *must* effectively have r/w authority
to the file, since it could just make up an app that it controls and then
pass the r/w capability to it.

(It would be possible for the browser to use file capabilities that are
sealed up to the point at which they are passed to the app instance.
This would reduce the size of the part of the browser code that needs to
be reviewed in order to conclude that it only passes r/w file caps to
applications that it launches, and doesn't use them itself. However, in
principle this does not reduce the browser's overall authority.)

There is no escalation mechanism in typical capability systems. None at all.
This is a feature: escalation, elevation, impersonation, setuid, etc.
are almost impossible to reason about or use correctly.

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

No it can't. If a subject can move and unlink arbitrary directory entries
in the user's namespace, then it can effectively write the file at any
such directory entry (even if it can't write a particular file object).
"Don't prohibit what you can't prevent."

> 2 things I don’t think CapDesk covers very well 

Bear in mind that CapDesk is a prototype.

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

Admins may think that they need centralized control of rights. This is
very rarely in the interests of users. Indeed it just results in users
spending a significant amount of time figuring out how to bypass this
apparent control, and usually succeeding.

(Note that if capability advocates often express opinions like that in
the above paragraph, it's not because capability systems are less able
than non-cap systems to provide the appearance of centralized control;
just because we realise that it's futile.)

> -          Non file type endowments like port/network /service/3D/Audio
> access etc

These are no different to files. In some cases we might want to statically
configure all instances of an app to be able to access a given object, but
the same is true of files.

> All we are doing is limiting what rights the user (Actor) can delegate and
> provide flexibility  in terms of the security model .

How are you limiting what rights the user can delegate?

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

I'm skeptical as to the value of doing that. However, that's just my
opinion; capability systems are certainly able to support users without
admin rights, and even without installation rights (although note that if
they can install any app that acts as an interpreter, including any app
that supports scripting, then they can still effectively run their own
code). This does not require any escalation mechanism.

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

A secure operating system needs a secure windowing system. The trusted
controls need to render themselves correctly, but a secure windowing system
will draw the "chrome" of a trusted dialog (distinguishable from other
windows), and ensure that the window is fully opaque and free of unredrawn
content of other windows, even without assuming that the window renders
its contents correctly. There should be no trusted controls that appear
directly in windows controlled by an untrusted subject; that's an unsafe
pattern.

-- 
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/20091217/18dd83ce/attachment.bin