On Mon, May 29, 2006 at 11:16:10AM +0200, Bas Wijnen wrote: > There is one very important point though. I think those restrictions can > easily be implemented in the user session. This means that we can just build > a system with no support for restricted storage, and add it if we find that we > did need it after all. However, Jonathan doesn't seem to agree. At the > moment I still think he doesn't quite understand what I mean. However, if he > does and is correct that it cannot be added later, we would need to decide > this before building the system.
Oh, and I forgot one thing. I'm very sure that I do indeed want the user to be able to run his own programs on fully opaque storage. This is very useful for programs handling encryption keys. Even if the shell is compromised, these keys must not be. What I would prefer to avoid is the ability to use this method for other user's programs in a way that they can verify. So in fact we would need the opaque storage anyway, but we can leave out the verification (and, of course, the program must not be able to tell if it's running on opaque storage or not, this is a decision the user makes, not the program). If we later need "remote" opaqueness as well, we can add the verification. 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
