[arch-projects] [dbscripts][PATCH] Prevent master keys signing packages
Signed-off-by: Allan McRae
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
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
---
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. Allan
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
--- 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.
Allan
I don't see how this could work. If you sign a package using that key pacman will happily accept it as valid. So if nymeria gets compromised the attacker obtains a valid packager key. Imho implementing db sigs this way is less secure than not implementing it at all. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
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
--- 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.
Am 03.11.2013 09:50, schrieb Pierre Schmitz:
I don't see how this could work. If you sign a package using that key pacman will happily accept it as valid. So if nymeria gets compromised the attacker obtains a valid packager key. Imho implementing db sigs this way is less secure than not implementing it at all.
We can use a subkey of a valid packager key. That way, revoking the subkey is very easy and doesn't need 5 people, but just one. If we secure the private key properly on nymeria (see my first mail), then compromising nymeria is not sufficient, you actually need to become root there (which hopefully shouldn't be too easy). Actually, other distributions have keys on their servers for signatures, too, even to sign packages (I remember seeing very unpersonal, repository-based PGP key on openSuSE).
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
--- 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
On 03/11/13 18:50, Pierre Schmitz wrote:
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
--- 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.
Allan
I don't see how this could work. If you sign a package using that key pacman will happily accept it as valid. So if nymeria gets compromised the attacker obtains a valid packager key. Imho implementing db sigs this way is less secure than not implementing it at all.
If an attacker obtains any of our packagers keys then they can sign a package. So by your logic we should not be signing packages. Also, this is the way every other distro signs their databases and packages. And they all use gpgv to verify packages which has no idea about a web of trust. This seems like something we should be able to achieve... Finally, I think signing databases is far more important than signing packages. The most practical attack on Arch is to become a mirror and hold back package updates with known vulnerabilities. Then you even know the IP addresses of people who have the vulnerable package. DB signing stops this as the entire database needs held back and people will notice the lack of updates. Allan
Am 03.11.2013 11:03, schrieb Allan McRae:
If an attacker obtains any of our packagers keys then they can sign a package. So by your logic we should not be signing packages.
Also, this is the way every other distro signs their databases and packages. And they all use gpgv to verify packages which has no idea about a web of trust. This seems like something we should be able to achieve...
Finally, I think signing databases is far more important than signing packages. The most practical attack on Arch is to become a mirror and hold back package updates with known vulnerabilities. Then you even know the IP addresses of people who have the vulnerable package. DB signing stops this as the entire database needs held back and people will notice the lack of updates.
I tend to fully agree with Allan here. We need to sign databases and the risk of having the signing key on nymeria is smaller than you make it look.
On Sun, 03 Nov 2013 20:03:41 +1000
Allan McRae
Finally, I think signing databases is far more important than signing packages. The most practical attack on Arch is to become a mirror and hold back package updates with known vulnerabilities. Then you even know the IP addresses of people who have the vulnerable package. DB signing stops this as the entire database needs held back and people will notice the lack of updates.
Imo it would also be useful to be able to test checksums of installed binaries to the packages available in the repos. One could possibly even verify the installed packages against another mirror. But in it's essence an improved -Qkk could be useful to verify system integrity. -- Joakim
participants (4)
-
Allan McRae
-
Joakim Hernberg
-
Pierre Schmitz
-
Thomas Bächler