l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Restricted storage


From: Bas Wijnen
Subject: Re: Restricted storage
Date: Mon, 29 May 2006 11:27:55 +0200
User-agent: Mutt/1.5.11+cvs20060403

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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]