Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack

[Pierre THIERRY]

Scribit Marcus Brinkmann dies 06/01/2007 hora 20:38:
> Or do you have something else in mind?  What prevents in your idea the
> browser from simply allocating opaque memory?

Maybe we don't agree with what can be done with opaque memory. If the
browser somehow ask some other process opaque memory in order to use it,
that memory won't be globally opaque. It will only be opaque if you try
to access it with a capability from the side from where memory came.

The way I see it, if process A gives opaque memory to process B (the
rogue browser trying to hide something from me), that memory region will
become unreadable if I try to see it in A's address space, or in any of
A's parent address space.

But to process B, the memory is perfectly readable and writable. If my
shell spawned A and B, now if it tries to read that memory in it's own
original space bank, it would fail. If it tries to lurk in A's sub space
bank, it'll fail also. But if it goes to B's sub space bank and there
tries to see the memory, it will be able to read and write to it.

If any process I spawned acquire memory that is opaque to it's
originating process, I will just have at least as much authority on it
than my process.

The only way a process could try to hide something from me is to give
opaque memory to a helper process I cannot monitor, for this helper to
write dangerous code that would be executed when memory is given back.
But that's not very different than the process writing itself dangerous
code in it's own memory. Strategies used to prevent the latter will work
against the former (you have to stop the process each time it's
executable memory is altered, and check the new code before it can be
executed).

Note also that in a capability-based system, my own rogue process just
won't have authority to communicate with the rogue helper I can't debug.
But even if I feel it necessary to give authority to my process to
communicate to that process I can't debug, I can monitor what will come
back.

The attack with the helper process described above may even be
impossible: there has to be a mechanism to prevent opaque memory to be
read when reclaimed, so probably the space bank could have an option
that memory given with opacity cannot be read when reclaimed even if the
recipient process doesn't ask for this protection.

That added protection would not be needed in most cases where opaque
memory is used, because in many cases, opacity will in fact just be used
to prevent writes, not reads (that's the case in the network stack and
similar components). In those cases, you keep the ability to monitor and
debug.

Securely,
Pierre
-- 
address@hidden
OpenPGP 0xD9D50D8A

signature.asc
Description: Digital signature