Rawhide signatures

[Russell Coker]

On Wed, 23 Jun 2004 18:50, Rui Miguel Seabra <rms at 1407.org> 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