|
From: | Martin Schaffner |
Subject: | ConfirmPassword |
Date: | Tue, 25 Oct 2005 19:50:14 +0200 |
* 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.
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.
Bas Wijnen wrote:
After thinking about it a bit, I do see an other option, though. We couldreserve some hardware for this purpose, and use that. It would not bepossible 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 inyour password.
(This LED should sit right next to the DRM-owner-override button suggested by RMS :-)
Would it be a good idea to use the ctrl-alt-del-mechanisms of "IBM-compatible" PCs on these machines?
Thanks, Martin
[Prev in Thread] | Current Thread | [Next in Thread] |