[cap-talk] Concrete application, WebCVOS (was: Selling capabilities programming)

[Jed Donnelley]

Jed Donnelley wrote:

One thing I should have mentioned is that in this (sort of 'X-Terminal') 
case:
> One approach to implementing such a WebCVOS would be to have the WebCVOS
> support no local capabilities except for the keyboard/mouse and 
> display.  All it
> would do would be to provide the "Invoke" call support and then have 
> all the
> other capabilities (e.g. files/directories for initialization, other 
> Windows or
> Unix compatibility capabilities, etc.) supported remotely.  Of course 
> this approach
> would probably have rather poor performance for file access in any but
> a very high speed LAN situation, but I consider that about the ultimate
> in opportunities for 'high assurance.'  I really don't see how you can do
> much better.  Granted there may be some potential for simple instruction
> execution (non "Invoke" calls) to cause a problem, but this interface is
> so 'thin' that I think it can fairly easily be adequately protected.  
> Beyond
> that the "Invoke" call itself is also rather thin.  It's only 
> concerned with
> determining validity of capabilities for communication and then moving
> data to and from safely.  Beyond that the only vectors for attack are
> through the service capabilities that might be serviced locally (e.g.
> the keyboard/mouse and display capabilities definitely, perhaps
> for local devices such as audio, optical media, etc., and perhaps
> through the file/directory capabilities).
>
even the Power Box could be supported remotely.  The call to
the Power Box capability would have to be given access to
the keyboard/mouse and a window display, but it could access
what amounts to the user's "/home" directory remotely.  This would
provide further assurance.

In such a case, of course, access to any local devices (e.g. audio,
optical drives, USB stuff, etc.) would have to be made available
to the Power Box (e.g. through the users /home directory) if it
were to be able to make them dynamically available to running
applications.  That would expose access to such devices to remote
exploitation, so there is a trade-off there, though those device
capabilities could be temporary for the duration of an application
run.

I really don't see how you can do much better from an "assurance"
viewpoint.  I could easily imagine also breaking up any Windows
features (e.g. the ability to "fork" - I don't know how many others
Windows has) into separate capabilities that would be separately
justified for initialization or through a power box.  I guess it's time
for me to get off my high and to go into response to issues mode.

--Jed   http://www.webstart.com/jed/