[arch-projects] [dbscripts][PATCH] Prepare to sign repo databases

Pierre Schmitz pierre at archlinux.de
Sun Nov 3 04:29:44 EST 2013


Am 03.11.2013 10:11, schrieb Thomas Bächler:
> Am 03.11.2013 02:32, schrieb Allan McRae:
>> On 03/11/13 11:19, Allan McRae wrote:
>>> Add function to sign repo database.  Enabling signing requires setting
>>> SIGN_DB to true and adding the key ID to DB_KEY. The DB_KEY is restricted
>>> from signing package files.
>>>
>>> Signed-off-by: Allan McRae <allan at archlinux.org>
>>> ---
>>
>> GPG does not have a concept of some keys being valid for some tasks.
>> So pacman can not have this concept without implementing a complete hack
>> or requiring two separate keyrings (one for databases and one for
>> packages).  Both of these are not going to happen, so we need to deal
>> with restricting key usage in dbscripts.
>>
>> The idea here is that someone creates a repo signing key and all master
>> keys sign it.  Then a subkey is created and put on nymeria.  If we have
>> issues, the subkey is revoked and a new subkey is created.
>>
>> Note that the patch assumes the db key will be added to nymeria's pacman
>> keyring which is located in the default location.
> 
> With this implementation, anyone with access to nymeria can simply steal
> the private key and use it elsewhere.
> 
> Users shouldn't have access to the private key, they should only have
> access to a black-box script that signs the database (and only the
> database) using sudo.
> 
> However, a clever asshole might then move a file to the database
> location, run the script and get a valid signature.
> 
> So, in order for this to happen, the whole /srv/ftp path for repos and
> pool must be read-only to packagers. Then, a dedicated script must be
> called using sudo that verifies the signatures of the submitted
> packages, adjusts the database and then signs it.
> 
> I was thinking about this for a while (independently of db signatures),
> but was always too lazy to do it. It's a nice feature to not have
> packagers mess around with the ftp path manually.

I wouldn't really trust such a setup. There might always be ways to get
root via kernel exploits are issues with suid binaries. It is safer to
assume tht nymeria cannot be trusted. Also keep in mind that it is
usually hard to tell if a server was not compromised. E.g. someone could
obtrain the key but only use it elsewhere (on mirrors or mitm attacks).

If nymeria has a valid packager key we could as well sign all packages
using that key.

I only see two possible solutions here that are safe:
* client side db signing (has lots of problems)
* pacman has different keyrings/keys for verifing packages and dbs.

-- 
Pierre Schmitz, https://pierre-schmitz.com


More information about the arch-projects mailing list