[csw-maintainers] ideas

[Ben Walton]

Excerpts from Maciej Bliziński's message of Fri Jul 08 13:06:39 -0400 2011:

Hi Maciej,

> Another thought: perhaps it would not be that hard to implement a
> POC of automatic catalog signing. For example: a machine in a
> private network, controlled by a trusted person runs gpg agent with
> a timeout in the order of 3 days to a week. A cron job running on
> that machine pulls the catalog file, signs it and pushes it back for
> the rest of the automation to pick it up.

This is a good idea.  I've been contemplating the design of such a
system for a few days now.

> At this point, there is a problem, that there is no verification
> that the catalog pulled can be trusted. To fix that, we can

I think something more 'on demand' is better suited here as that lends
itself to better atomicity which will be important.  I'm thinking
something along the lines of:

Just before a mirror push is about to happen, something opens a socket
to a daemon and says "please sign catalog current/i386/5.9 having sha1
$sha1."  The daemon would then grab the catalog from a preset
location, ensure the sha1 matches and sign it.

The signature is then returned over the socket and the caller is
responsible for placing it appropriately with the files.

Having things designed like this removes some possible security
issues.

1. If the client can only request catalog signatures based on the
   tuple (catalog, arch, os release) and the daemon then goes and
   reads the file from a run-time specified or hard coded directory,
   the client cannot get 'just anything' signed.
2. Making the client responsible for placing the signature data means
   that, given 1, we don't need to protect the daemon with encryption,
   authentication, etc, as getting a catalog signature for a valid
   catalog is public data that will be available on the mirrors
   anyway.  It also removes privilege from the daemon so that it needs
   read-only access to the data it will sign.

If the client has enough access to manipulate the directory structure
that the daemon will read, it can make the daemon sign a manipulated
catalog.  This level of compromise means things are already in bad
shape though, so it shouldn't be worse than the risks we have today.

The daemon would, as you suggest, need a timeout so that a human needs
to re-initialize the agent storing the pass phrase periodically and it
could tell the caller if it was unable to perform signatures.

I'm willing to code the daemon.

With such a signing daemon in place, we can have a cron job running as
a dedicated catalog/mirror maintenance uid that has the access needed
to place catalogs and signatures and push to the live mirror area...It
will update catalogs, get them signed, etc.  If the release proposal
is accepted, this job could also be the one that moves things from
unstable to current.

As a side note, I'd like to mention to a wider audience than irc: I
think our signatures should be detached instead of clear signed.
These are nicer to work with all around.  It would require
coordinating a pkgutil update though.

> introduce signing of individual .pkg and .pkg.gz files. The script
> pulls not only the catalog file, but also the data files. It
> verifies that all files referenced in the index (the catalog file)
> are properly signed. If not, it complaints loudly.  If yes, it
> proceeds with signing.

This can be a separate topic, but I think it is something to look at.
The biggest hurdle here is ensuring that everyone gets a gpg key
created for this purpose and that we distribute the public portions of
the keys to client systems for verification.  This could be tied into
CSWcswpki that I've already laid groundwork for.

> The signatures could be uploaded with csw-upload-pkg.

Detached signatures for this would be best too.

> I do not have a good idea where to store the signatures. I can
> imagine an appendix to the catalog that lives in a parallel
> directory, or a subdirectory of e.g. unstable/sparc/5.9

CSWcswpki should pull them down and install them in a private keyring.

> There also is the (independent) problem of key revocation, presented
> in detail by William in Dublin.

Revoking a catalog signing key is different from revoking a maintainer
signing key.  If we revoke a catalog key, we can regenerate a new
catalog with the new key.  We may not be able to easily regenerate
signatures for all packages if the need arises.  If we sign packages
individually, we may want to use a generic (but different than the
catalog signer) key for this purpose too.

> The two stage implementation outlined above gives us the advantage
> that we can be back quickly and we can we have a plan how to improve
> the security chain between an individual maintainer and the user.

Agreed.

Thoughts?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302