On Tue, May 23, 2006 at 10:46:34AM +0200, Tom Bachmann wrote: > Bas Wijnen wrote: > >> I'd like to encourage everyone to consider this. It sounds like a viable > >> compromise > > > > What exactly is "this"? > > > > The proposal by jonathan: > > > There are opaque and translucent banks. The difference is that > > the opaque bank will not issue a given page more than once. A > > translucent bank will, which is how the user gains access to > > the content. > > > > An opaque bank can be a child of a translucent bank (or the > > other way around). > > > > There is a permission restriction on banks that prohibits formation > > of opaque sub-banks. If this bit is set, only translucent sub-banks > > can be allocated (this preserves recursive translucency). > > > > If an object is allocated from an opaque bank, it is marked (within > > the allocator) as opaque, and no parent bank will disclose it.
No, I do not think this is acceptable. This means a program can protect against the machine owner (or the user running a sub-Hurd) by creating refusing to run on anything but an opaque bank. You would need to write your own implementation of the space bank (if that can be virtualized at all) to get around this. That is much too high a price to pay for being able to debug a program which you own (that is, for which you have the binary image). Protection for programs which are about to get capabilities which must not be disclosed to the wrong parties is fine. That is not what this is about. This is about protection from the user who owns everything that's known to the program. That must not be possible. The user must be in complete control in such a case. In particular, that means that when starting a sub-Hurd on a transparent space bank, it must not be possible that - A part of the sub-Hurd becomes opaque - A part of the sub-Hurd can see that it is running on a transparent (to the parent Hurd) space bank. At least one of these conditions is not satisfied in the proposal (the user may choose which, but can't choose to satisfy both without considerable effort, namely hacking the space bank). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
