On Wed, 23 Jun 2004 18:50, Rui Miguel Seabra <rms(a)1407.org> wrote:
On Tue, 2004-06-22 at 23:40 +0100, Luciano Miguel Ferreira Rocha
> gpg --passphrase-fd=0 ... <<EOF
> my passphrase
> Or why not just remove the passphrase all together? Sure, the private key
> would end up unprotected, but having the passphrase on a script doesn't
> give that much protection either.
Because that would unprotect the key.
We have a script running as UID 1000 that wants to do GPG signing (for the
sake of discussion). Running the standard Unix security model any data that
this script can access can be accessed by all other programs running as UID
1000 (via ptrace, accessing the file containing the password, and probably
Using the standard Unix security mechanisms we could have ~/bin first in the
path and ~/bin/gpg be a script that calls a SETUID binary that launches gpg
and passes in the pass-phrase. The pass-phrase could be hard-coded into the
SETUID binary provided that it had mode 4711, or put into a file that only
the other UID could read. But what's the difference? You still have a key
stored with a pass-phrase.
However, restricting access both to the script or to the file
the password is important AND POSSIBLE TO DO (at least partially) with
There is no benefit to restricting access to the password when restricting
access to the secret key is sufficient. If they can get the secret key then
they can almost certainly get the pass-phrase.
The default policy for GPG in SE Linux restricts access to all files under
~/.gnupg . However it is possible to GPG encrypt the secret key with a
password and have the encrypted file written to somewhere that's readable.
But patching gpg to prevent that should not be difficult.
Finally for a build server we don't only have to be concerned about the secret
key being stolen. We also have to be concerned with someone exploiting the
build system and making it build and sign something that is not intended.
Preventing this is a thousand times more difficult than merely preventing the
secret key from being stolen.
We just have to use a key that's not overly important for the auto-builder and
make sure that we have good procedures for revoking it if necessary.
PS One thing you don't want to do in SE Linux is have a domain_auto_trans()
rule where the executable type is applied to a script and the target domain
has more access than the source domain. That gives you all the same issues
as SETUID scripts. If you want to do such things then the right thing to do
is to have a ELF executable trigger the domain_auto_trans() and then have it
hard-coded to execute a script in a path that does not allow write access to
untrusted users (EG /usr/bin).
My NSA Security Enhanced Linux packages
Bonnie++ hard drive benchmark
Postal SMTP/POP benchmark
My home page