Re: [Keyrings] Re: [PATCH 01/04] Add multi-precision-integer maths library

["David Härdeman" <david@2gen.com>]

On Sat, Jan 28, 2006 at 11:37:51AM -0500, Trond Myklebust wrote:
>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.

What about the first paragraph of what I wrote? You are going to want to 
keep often-used keys around somehow, proxy certificates is not a 
solution for your own use of your personal keys and with the exception 
of hardware solutions such as smart cards, the keys will be safer in the 
kernel than in a user-space daemon...

Further, the mpi and dsa code can also be used for supporting signed 
modules and binaries...the "store dsa-keys in kernel" part adds 376 
lines of code (counted with wc so comments and includes etc are also 
counted)...

Regards,
David