[cap-talk] Reducing the authority of a file browser in a capability OS.

[Ben Kloosterman]

>
 >What I am advocating however is the object private member variable as
 >being the least authority solution, also after transposing it to the
 >relevant level of granularity where apps are the classes, pseudo
 >persistent processes are the objects and file chooser powerboxes are the
 >singletons.

While I agree with David and Alan for UI based designs a few  power boxes of
user rights have some advantages ( in terms of minimum UI prompts , simple
from the users point of view  , and you can make the trusted code small ) it
works best with a certain class of problem.  

There are some classes of problems having semi persistent processes which
contain the rights as superior 
eg 
1. Configuration data  ( including log files , account files etc) , painful
to configure so you do it once. 
2. Automated batches where selecting all the files is a non trivial exercise
, hence you want to do it infrequently. 
3. cases where I want  programs the user runs to have rights but I don't
want that user accessing it with different programs. Consider the Make file
/ batch example I may want a user to be able to build a project ,but not
even have read access to some ( but not all)  of the source files ( I live
in China now and there is no better way to get your code sold)  , now I can
create a persistent MakeFile process which contains all the rights needed (
eg Read for all the source , write for the outputs ) the user can then
execute it at will and note the compiler here would be an instance.
Backup/Restore are also in the same class. I note these tend to look like a
Capability List(Group)  but don't necessarily pass the rights to the user. 


>If in OOP you had to choose the least authority solution and had to choose
between putting data into private member vars, or >instead using the manager
singleton to store your data, I'm pretty sure you would opt for using the
private member vars over the >manager singleton. So either I am making some
major mistake in transposing the OOP granularity concepts to the relevant
level of >granularity, or you are simply failing to recognize the
equivalence.

This is exactly why I wanted the browser to have just browse rights and semi
persistent processes.  However good OO also relies on this private variable
being injected ( note no security on IOC) into it either via passing or
persistence both of which mean it's not strictly private. Obviously self
created files are private by nature and hence a trivial problem but what
about downloaded files?

>From the above it seems to me that the rule is if you can get the user to
easily select what he wants use a powerbox to handle this , in cases you
can't try to persist the capabilities ( eg configuration) . Both methods are
better than Ambient authority. 

1. The powerbox with instance apps conveys the users intentions but the code
is trusted and needs to be treated as such ( ie bigger TCB) .   In OO speak
this is a static/Shared singleton which calls instance objects and pass in
the data via the constructor . 

2. An app can be used with persistent capabilities in an application where
the user can convey information  but it is not easy to do so or the user may
not have rights. eg  Setup/Configuration. The user does not need to be the
user who setup or configures the application so it can also allow the user
rights to do things he cannot do with his normal authority.  In this case
you can also grant the user rights to things the user does not have. In OO
these are static/Shared with private data though data can be passed in via
trusted program to a property.  

Note both use a powerbox , the second one needs one to pass in capabilities
which were not created by the application.