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

[Jed Donnelley]

David Wagner wrote:
> Jed writes:
>   
>> It was Jed who was looking for the WebCVOS sandbox, not James
>>     
>
> Sorry; my confusion.
>
>   
>> Regardless, I don't believe this issue is nearly as complex as you suggest.
>> There is only one entry point needed (OK, leave room for flexibility
>> and allow a few) for the WebCVOS trap (system call), and it is
>> limited to change with WebCVOS specs, not with Windows.
>>
>> The whole Windows API will be provided through library
>> calls - along the lines of Wine - on top of that Web Capabilities
>> as data interface with it's "invoke" call (specify a capability
>> to invoke and message to send, including capabilities - with
>> return, etc.).  Of course we could have delightful debates about
>> the exact syntax and semantics of the WebCVOS call (YURLs,
>> etc.), but I think that is the topic of another discussion.  In
>> what I propose it simply has a virtual memory (e.g. up to a
>> size specified in its initialization block) process with the
>> "invoke" interface for Web capabilities as data.
>>     
>
> Okay, now I understand.  Sorry that I misunderstood.
>
> I agree that it seems plausible you can confine machine code so that
> all it can do is execute instructions, access its virtual memory, and
> execute the "invoke" system call.  I don't know enough about the x86
> architecture to know whether there are any subtle gotcha's, but it
> sounds believable to me.
>
> At that point security boils down to whatever is on the other side of the
> "invoke" syscall.  If the answer is that you're going to stick all of Wine
> on the other side of the "invoke", then you're exposing a pretty hefty
> attack surface to the downloaded code.  That sounds like a low-assurance
> approach and one that will be perpetually subject to vulnerabilities in
> that interface.
>   
No - sorry.  All the Wine code goes *inside* the protected WebCVOS 
environment.  It
provides a library that looks like Windows but translates into calling 
some number of
initialized capabilities - e.g. those from the initialized directory, 
likely one for
keyboard/mouse events, one for the window display, for Windows apps perhaps
something that provides some special Windows functions that can't all be
provided by the Wine/WebCVOS library, one for the power box, one for
local files/directories, and some for other local devices.
> Is such a low-assurance solution good enough for code downloaded via
> the Web?  An interesting question.  Our current web browsers are pretty
> low-assurance beasts, themselves.  It's hard to say whether your approach
> would turn out to be more or less secure than existing browsers.
>   
Sorry, but without further support I reject the "low assurance" label.  
I consider this
approach very "high assurance".  It is completely POLA with only one
system call, "Invoke".  Granted there may be any sort of integrity 
failure through
an invocation on a capability, but any such failure could be made unlikely
and could even even be moved off the machine for many (most?) capabilities.

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).

An approach like that above is much like the old X-Terminal days.
In organizations with high speed LANs, the assurance/integrity
could be nearly as good as that of the remote services - very good
indeed I think.

This whole mechanism seems about as tight as it can get to me.
Of course there are still potential vulnerabilities through device
drivers and such.  If some code can invoke a local device (e.g.
the keyboard/mouse or window display) and with something
like a buffer overflow attack take over the system, then of course
it would still be able to get at your Web/YURL capabilities
and the network and you'd be had.  Still, as I note, I don't think
you can do much better.  I still regard this situation as sooooo
much better than what we have now that it certainly provides a
concrete application of value.  I would be much, much less
'afraid' running applications in such an environment.  I'd be back
to the situation where I'd be quite willing to run that Christmas
card .exe...
> Is there a compelling use case that would demand such an architecture?
> I don't know that, either.
>
>   
Of course I believe so or I wouldn't have started the thread.  From my
perspective the compelling use case is being able to run applications
('Windows', 'Mac', 'Unix', or native or language as MarkM initially
suggested) with performance comparable to any local OS (this
in the case with local support for objects such as at least files) and
with the maximum possible "assurance" (protection/safety).  This is
the "Hurray!  I'm no longer afraid to run applications!" scenario.
Microsoft's first law no longer applies!  We have capability protection
and confinement (POLA) comparable to any capability OS such as DVH
or KeyKOS or EROS or Cyotos (subject to Jonathan's disagreement
and subsequent discussion), but with a rather modest  development
effort on top of today's base OS stable - which supplies the base "no call
or external interaction" virtual memory process facility, and we can
run all of today's applications if we get a little help loading them
to run over a compatibility library.

Most of the work I expect would be in getting the compatibility
libraries to be adequately compatible, but remember that those run
inside the protected environment, so they aren't part of any concern
with assurance (security/integrity).

--Jed   http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070719/96ba11d6/attachment-0001.html