[cap-talk] Concrete application, WebCVOS (was: Selling capabilities programming)
jed at nersc.gov
Thu Jul 19 19:35:48 EDT 2007
Jed Donnelley wrote:
One thing I should have mentioned is that in this (sort of 'X-Terminal')
> 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.
> 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
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.
More information about the cap-talk