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

Tue Dec 15 23:24:05 PST 2009

Very interesting thanks .Many good ideas.

The copy on write is very interesting as it covers many things such as a log
file , user specific configuration etc .

I note this powerbox is a form of App-> User escalation  and would be
limited by what the User ( actor) can do. 

I suppose there are really 4 forms of escalations here

-          When a explorer or folder invokes an app by calling the document
the app needs to convert a browse and execute by association capability to
a R/W . So this is escalating a given Capability to a higher one. 

-          Escalating from an app to a user whether this is via a prompt or
automatic. Obviously automatic is desirable. 

-          Escalating from user to group ,group with admin rights or Super
user.  The main thing here is groups may be cross machine. ( Obviously a
User (actor) is different form an admin (actor) . I don't think forcing
people to login as admin is a good idea either that was tried with
Windows/XP  in NT4/2000  and most home users became admins though the
separation was retained for servers in Corporate IT.  Even an admin here
would have greater user authority such as browsing system logs. 

-          Escalating to some sort of  global privilege you could create
this when the Capability is created but you would still need an escalation
system to handle changes.  Technically its easier here have an escalation
mechanism than propagating Capabilities to all applications. 

I have a number of concerns about the powerbox mainly that it only covers
files  and is hence a subset ( though obviously any automatic passing on of
capabilities should be good) . eg how do you grant access to the systemLog
file for some apps when can't even browse it as a user.  Escalating to admin
rights seems the best way . 

Anyway I think the primary goal everyone agrees to is to have minimal
starting privileges and the secondary goal is to infer as much security
automatically as possible while still being specific.

Consider Install popup 

Green Dialog - Word processor ( Escalate to user rights) 

This app  desires r/w access to your .doc files 

This app would like to be the default application for doc files. 

This app would like to share data with these apps 

               Xxx

                Yyy

This app would like to access the network 

This app would like to use 1G of memory.

Low Security        Medium Security          High Security

Orange Dialog Browser ( Escalate to non admin group rights eg
ServiceManager) 

This app  desires to receive on port 1213 

This app would like to  create /SystemCache  folder and allow 200 Meg of
files

This app would like to stop and start services

Medium Security          High Security

Red Dialog - Defrag , Indexing or Anti virus scanner (Escalate to admin
groups) 

This app  desires R/W access to all files on the system    // note you can
exempt some dirs

This app would like to stop and start services

This app would like to run at 9pm every day. 

High Security          

I don't think this is a big deal as these are normal installation options
anyway .  It is also obviously security overlaps configuration so a
configuration screen can grant approvals. This requires some sort of OS
installer and meta data from the app. To avoid apps requesting too much
authority ( which they will if it gets to hard some form of escalation
really helps eg start sharing data with another app , opening an additional
network port  or changing the address . By using the popup the application
will not have the access to do this , I would be very concerned about a
large amount of trusted systems called by an app eg FileDialog , PortDialog
etc etc and using some of these to eliminate frequent requests seems good
but by trying to cover all IMHO you make a lot of work for the
user/developer  and you have a much larger TCB.  A trusted
installer/configurer  and File dialog seems good would remove all to user
escalations though you still have to handle tasks that maybe restricted to
the user. 

Regards, 

Ben Kloosterman

From: tobycmurray at googlemail.com [mailto:tobycmurray at googlemail.com] On
Behalf Of Toby Murray
Sent: Tuesday, December 15, 2009 9:19 PM
To: bklooste at gmail.com; General discussions concerning capability systems.
Subject: Re: [cap-talk] Reducing Ambient user authority in a Type Safe
/Memory Safe OS.

2009/12/15 Ben Kloosterman <bklooste at gmail.com>

Note the escalations are a bit different from  Windows UAC and sudo due to
the fact that the granularity is application (per user) instead of user and
there is no su account. Because by default an application has no authority
everything needs to be added.

The idea with the escalations is that there is little Ambient authority from
the user and on a totally secure system   you can with a policy setting
disable it. However I would argue that without such an escalation most
initial install settings would need to be looser eg instead of saying only
word has r/w access to  .doc files in the home directory and only excel .xls
you get the situation that all applications have full access to the users
home directory. With escalation you can use very tight settings and then
escalate them as needed, after a short time all the settings would be in
place.

This sounds more like what would be referred to by some on this list as
"granting authority via a powerbox". The user has some authority that needs
to be granted to an application. The application asks for it via some
trusted UI and the user decides whether to grant it or not.

The classic example is the "File Open" dialog box where the chooser choosing
a file to be opened grants the application the authority (i.e. a capability)
to read the file. 

You might like to look at Ka-Ping Yee's paper on security by designation vs.
admonition, see
http://www.computer.org/portal/web/csdl/doi/10.1109/MSP.2004.64

as well as the work on CapDesk and Polaris, both of which looked at using a
powerbox system to grant authority to applications at install time.

Finally, you might also consider looking at Plash's CopyOnWrite facility.
You grant an installed appliation CopyOnWrite access to large parts of the
file system that it might think it needs to modify. Any modifications cause
a copy of the original to be made to which the write occurs, leaving the
original file unaffected.

Cheers

Toby

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20091216/56b36deb/attachment-0001.html 