[cap-talk] Concrete application, WebCVOS (was: Selling capabilities programming)
jed at nersc.gov
Thu Jul 19 17:12:45 EDT 2007
David Wagner wrote:
> Jonathan Shapiro writes:
>> Mark Miller wrote:
>>> If you still think it doesn't seem that hard, how are you going to
>>> intercept all OS traps on Windows without cooperation from Microsoft?
>>> AFAIK, there's no ptrace equivalent exposed to Windows programmers.
>> No, but there are plenty of ways to hook that API. Rootkits often do
> Yes, but I don't think they're useful for what James wants, namely,
> for sandboxing. There are thousands of OS traps on Windows. It is not
> feasible to build a high- or even medium-assurance jail when you must
> mediate all thousands of those entry points. Also they are undocumented
> and subject to change with every Windows version. That's a complexity
> nightmare. What are the chances that your mediation logic does not
> have a single hole? Second, my understanding is that many of the
> mechanisms that are ordinarily used to hook that API are bypassable:
> if the application is malicious, it can bypass the hook.
> MarkM's criticism sounded pretty persuasive to me.
It was Jed who was looking for the WebCVOS sandbox, not James (unless
I missed something) - though my given name is James. Better stick
to my nickname, Jed (J.ames E.llis D.onnelley), to avoid confusion (why
I picked up that nickname to begin with - two many heads looked
up when a teacher asked for Jim or James). At least we don't have to
worry about confusing Jamacks and the like... ;-)
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.
I'm not very familiar with the Windows trap interface,
so I could be off on this, but I don't believe the specifics
of that interface are relevant to this topic.
Naturally the moving target for the Windows API effects
the compatibility library (e.g. Wine derivative), but I don't
see that as stopper for an approach like WebCVOS.
It's only a relatively few applications supported
by Microsoft that are likely to be so dynamic as to
cause issues in this area, and those won't be important
unless something like WebCVOS becomes widespread
enough that it's success is already assured.
I wonder if I should start being careful with an
offhand name like "WebCVOS". If I use it many
more times I better come up with something better.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk