Re: ConfirmPassword

[Bas Wijnen]

On Tue, Oct 25, 2005 at 07:50:14PM +0200, Martin Schaffner wrote:
> Hi, I have two questions concerning agents such as ConfirmPassword and 
> OpenFile/SaveFile:
> 
> * would it be possible to avoid the *requirement* that instantiators 
> can not inspect instantiateds in the following way: If an application 
> (A) wants to ask get a password-protected capability or a file system 
> capability (which you suggest should be done with a trusted utility U 
> such as ConfirmPassword), it has to contact a server S. So instead of 
> giving A a capability to the constructor of U, we just give it a 
> capability to S, which is trusted, and can't be inspected by A.

The requirement that the instantiator should not be allowed to inspect the
instantiated is only needed for programs which receive capabilities that the
instantiater doesn't have.  In other cases it doesn't usually harm to allow
the inspection, but there isn't really a reason to try to allow it.  It's more
a matter of not spending performance on trying to enforce it.

The reason ConfirmPassword is different from any other server is the trusted
path that it needs.  Not only should it be allowed to read the shadow file,
but it also needs to know that the input you type cannot be read by some other
process.  For the rest, consider ConfirePassword to be equal to S.

> I do agree with the principle of least authority, but if violating it 
> in this instance gives us some other great benefits, then we should not 
> forget the fact that it might not be necessary.

Do you have any specific benefits in mind, or is this just hypothetical?  In
the latter case, I agree that it should be considered, but I can't imagine
what the benefits would be, since the scenarios aren't really different.

> Bas Wijnen wrote:
> >After thinking about it a bit, I do see an other option, though.  We could
> >reserve some hardware for this purpose, and use that.  It would not be
> >possible to simulate this, since the hardware can only be controlled by a
> >capability which they don't hold.  The hardware could for example be the
> >caps lock LED: When it's on, the screen is grabbed and whatever you type
> >goes only to the authentic password reading program.  When it it's off,
> >don't type in your password.
> 
> Would it be a good idea to use the ctrl-alt-del-mechanisms of
> "IBM-compatible" PCs on these machines?

That is a different version of the same idea: the trusted hardware in that
case being a certain combination of keys which cannot be handled by
applications.  I very much dislike the idea of reserving key combinations
though, and I think it was a _very_ bad idea from them to use a combination
with an existing, very different, meaning.

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