On Wed, 23 Jun 2004 18:50, Rui Miguel Seabra <rms@xxxxxxxx> wrote: > On Tue, 2004-06-22 at 23:40 +0100, Luciano Miguel Ferreira Rocha wrote: > > gpg --passphrase-fd=0 ... <<EOF > > my passphrase > > EOF > > ? > > > > 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 other mechanisms). 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 containing > the password is important AND POSSIBLE TO DO (at least partially) with > SELinux. 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). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
