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

[David Wagner]

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.

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.

Is there a compelling use case that would demand such an architecture?
I don't know that, either.