Setting up shared access to gpg on a UNIX server
johannes at zarl.at
Thu Jan 30 17:54:06 CET 2014
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. Look at the following session I just did:
> 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
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.
More information about the Gnupg-users