On Sat, 2006-01-28 at 11:46 +0100, David Härdeman wrote:Not necessarily, if you have your ssh-keys in ssh-agent, a compromise of your account (forgot to lock the screen while going to the bathroom? did the OOM-condition occur which killed the program which locks the
screen? remote compromise of the system? local compromise?) means that a large array of attacks are possible against the daemon.
In addition, as stated before, the "backup" account, or whatever user the daemon which wants to sign stuff with your key is running as, might be compromised.
Currently, if you want to give the daemon access to the keys via ssh-agent (or something similar), you have to change the permissions on the ssh-agent socket to be much less restricted (especially since it's unlikely that you have permission to change the uid or gid of the socket to that of the daemon). Alternatively you can provide the backup daemon with the key directly (via fs, or loaded somehow at startup...etc), but then a compromise of the daemon means that the attacker has the private key.
Finally, the in-kernel system also provides a mechanism for the daemon to request the key when it is needed should it realize that the proper key is missing/has changed/whatever.
Then fix ssh, not the kernel. As I said before, this is a problem that
has been solved entirely in userspace by means of proxy certificates:
they allow the user to issue time-limited certificates that are signed
by the original certificate (hence can be authenticated as such), and
that authorise a service to do a specific thing.