Storing keys under a different user...

[Neil Williams]

On Wed, Feb 11, 2004 at 04:30:22PM -0500, Nicholas Paul Johnson wrote:
> Hello,
> 
> This post is meant as an informal feature request; I want to hear people's 
> feedback before I make it a formal request.
> 
> Then, when user nick wants to do any gnupg operation, he would
> setuid(f(uid(nick))), read the key, restore user id, and procede.  

Copying the secret key file still requires knowledge of the password
that protects the secret key. How is this different to adding a
requirement to either know/crack the root or new user password?

> I would generally cringe on adding an setuid() call, but under certain

With good reason.

> This way, the key is secure, because no trojan running as a user would be

No more or less secure than at present? A trojan:
a) isn't particularly useful if it only operates in user space (so isn't
particularly attractive to write)
b) would have to be uncommonly specific to go after secret keys - there
are a vast number of Linux/Unix boxes out there with no secret keys at
all. There's no real way of telling a workstation from a server until
you've at least got some kind of compromising access.

> able to read the key, unless it somehow had (A) compromized root, which is

Compromising root is probably the only purpose of any *nix exploit. If
someone really is after secret keys, some kind of keyboard logging would
also be required. If the attacker can fit a keyboard logger then s/he has 
some kind of physical access to the box - and you have more than your
secret key to worry about.

> problem in itself, or (B) successfully logged in as nick_key, which is
> (theoretically) not going to happen either.

Is obtaining secret keys en-masse really that attractive?
First you have to find a *nix exploit.
Then you have to disregard most boxes that don't have secret keys.
Then you have a limited window to use all those secret keys to
compromise what? What good is the secret key of someone you don't know?
What can you realistically do in the time before the key is revoked,
given that you obtain the key more or less at random and have no
knowledge of where or when encrypted content may be compromised?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : /pipermail/attachments/20040211/fbb9548d/attachment.bin