[cap-talk] Google's Native Client (NaCl)

[David-Sarah Hopwood]

James A. Donald wrote:
> Mark Seaborn wrote:
>> I am having a go at porting glibc to NaCl [2] in order to make it
>> easier to port software from GNU/Linux to NaCl.  I have got as far as
>> running a "hello world" test program with dynamic linking with some of
>> NaCl's checks switched off.
> 
> Portability seems to me likely to be a lost cause - if it looks enough 
> like glibc, probably unsafe.  If unsafe, will not compile.

Why the negativity? Mark already has a bunch of useful stuff running
under Plash, and is looking to make it easier to port more stuff, which
seems like a very constructive thing to attempt.

In any case, I think you may be labouring under a misapprehension about
how both Plash and NaCl (and most kinds of native sandbox) work. The
modified libc is not in the sandboxing system's TCB. Each instance of
it runs within a sandboxed process, and cannot do anything that the
sandboxed application couldn't do on its own. That is, we're not "taming"
libc, we're only modifying it to make use of the communication channel
out of the sandbox. So the objection "if it looks enough like glibc,
probably unsafe" is misplaced -- security depends primarily on the
interface between the sandboxed process and the sandboxing system, not
on the interface between the sandboxed application and libc. (The latter
might contribute to application-level bugs, but not to a breach of the
sandbox.)

Of course there may be flaws in the sandboxing system, but if there are,
then they are flaws that are exploitable (or not) regardless of what the
modified libc "looks like", either to the application or internally.

> We would be 
> better off breaking compatibility and creating message queue oriented 
> very high level library of C++ templates, which library will be much 
> easier to port in the future.

"We would be better off ..." doesn't apply here. Mark is working on
native sandboxing; others are working on different stuff, including
systems based on message queues in programming languages. Everyone can
work in parallel, and no-one is impeded by others' work. In fact, there
is plenty of cross-fertilization of design ideas between capability
projects that take quite different approaches to implementation.

If you want to promote the idea of a C++ template-based message queue
library, then you're free to do so without knocking other projects
(although I suspect that you will encounter some skepticism about the
suitability of C++ for this purpose).

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com