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 -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
