[cap-talk] Understanding capabilities in a web-desktop setting

[Kevin Reid]

On Aug 8, 2008, at 10:56, Luke A. Guest wrote:

> If an capability URL has a large random string in there, you'll never
> get users to use capability systems; I know I wouldn't want to try and
> type in one of these URL's, or am I missing something?

Basically: You put the URL in your bookmarks.

If you can't do that (let's say you're using a reliable-but-not-yours  
computer), then use a password to access a web site which stores the  
bookmarks for you -- possibly, but not necessarily, the same site as  
generated the original URLs.

>> For example, when you double-click on a text-file file to open it  
>> in a
>> text editor in CapDesk, the text editor is given the authority only  
>> to
>> read that one file, and nothing else! Any vulnerabilities in the text
>> editor do not make the rest of the system vulnerable!
>
> What if I wanted to edit the text file rather than just read it?

There are many ways this can be handled. I don't recall exactly which  
one of the first three CapDesk uses.

1. You specified you want to edit the file [with MyEditor], not just  
view it, when you opened the file.

2. When you installed the text editor and its association with text  
files, you specified that it should be allowed to write to them, when  
you double-click a text file.

3. The editor does get access to write to the file -- all open-by- 
double-clicking means to give write access (to that one file).

4. The editor's window's "save" command is managed by its powerbox (a  
component  provided by the capability desktop system) -- the editor  
gets write authority when you use that command, and at no other time.

> My interest lies in OSes and providing a better security mechanism  
> within one. So a few related questions here would be:
>
> 1) What would be the process of logging on to a capability OS  
> (assuming
> desktop or multi-user system rather than embedded)?

You supply a password. This gives you access to your shell, which is  
just a collection of capabilities stored for you, held by a program  
providing the UI for you to interact with them.

You might notice that this is similar to the bookmark-storing tool  
above. They are exactly the same thing, in different media.

> 2) How does a user get these capabilities? I can only assume there  
> would
> be the concept of a user and they would have a list of capabilities.

It's sort of the other way around. You log in, which gives you access  
to the shell, which stores a list (more likely, a directory tree) of  
capabilities. There is no fundamental concept of a user; it is just a  
convenient-for-humans arrangement of capabilities.

> 3) What would happen if you tried to access a website, would it  
> bring up
> a ton of dialog boxes asking for permission, i.e. the Vista problem?

Yes/no dialog boxes, besides being a usability problem, are against  
the capability spirit, which as I put it is: do not have special  
checks, make disallowed actions *impossible to express*.

Don't take a request for X and put up a dialog box asking the user to  
grant X; *don't let the requester know X exists*. Don't put it in the  
requester's namespace, until the user does.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>