Setting up shared access to gpg on a UNIX server

[Johannes Zarl]

On Thursday 30 January 2014 11:49:47 Peter Lebbing wrote:
> If you're trying to achieve by the 744 what I think you're trying to
> achieve, namely that users can't change the files, I think you're
> mistaken[1]. Look at the following session I just did[2]:

> The thing is, you're not allowed to change any files, but you are allowed to
> replace those files by your own.

Just in case this isn't clear to everybody already: The write-permission on 
the directory are the problem here, not the 744 on the file.

> gpg does stuff with a bunch of files in the homedir, and I suspect
> that some might need the permission to overwrite files one of your other
> users created.

If one really wanted to use a shared secret key in this way (as opposed to a 
token), I would only share the keyrings, not the home directory.

Like that (only a mockup):

ls -la /opt/app/apps/dbmprod/gpg
-rwxr-x--- 1 root gpgusers  .
-rw-r----- 1 root gpgusers  secring.gpg
-rw-r----- 1 root gpgusers  pubring.gpg

Limiting readability to a user group would at least limit the access to the 
key material w.r.t. unprivileged processes running on the same machine.

gpg --secret-keyring /opt/app/apps/dbmprod/gpg/secring.gpg 
  --keyring /opt/app/apps/dbmprod/gpg/pubring.gpg 
  ...


As to what Bob wrote in the original message:
> I suppose that my use of a private key without a passphrase might be of some
> concern, but I never figured out a better way to do this.  In other words,
> if the single key required a passphrase, I'd have to give out that
> passphrase to everyone, so what would be the point?

It might not make much of a difference, but having a strong passphrase would 
still protect copies of your key lying on some backup.

Other than that, I guess Diego's advice is sound -- limiting the potential 
damage by using a token/smartcard.

  Johannes