| 1 |
Disclaimer: I'll only targeting technical aspects here, I won't go into |
| 2 |
any security analysis. |
| 3 |
|
| 4 |
On Thu, 18 May 2006 23:45:17 +0200 |
| 5 |
Patrick Lauer <patrick@g.o> wrote: |
| 6 |
|
| 7 |
> 3) Manifest / Manifest2 |
| 8 |
> |
| 9 |
> This is an implementation of a checksum / signature scheme. It is |
| 10 |
> described in GLEP 44: |
| 11 |
> |
| 12 |
> http://www.gentoo.org/proj/en/glep/glep-0044.html |
| 13 |
> |
| 14 |
> Right now SHA1, SHA256, RMD160 are the default checksum algorithms |
| 15 |
|
| 16 |
> |
| 17 |
> While manifest2 should take care of all executable bits in the tree it |
| 18 |
> does not yet cover eclasses and profiles. As long as this is not taken |
| 19 |
> care off any attacker can just override an eclass on the rsync mirror |
| 20 |
> or modify the profiles. This has a severe negative impact on signing |
| 21 |
> effectivity. |
| 22 |
> |
| 23 |
> Any "good" solution should sign all data files in the tree, so I ask |
| 24 |
> for an extension of the Manifest2 protocol to include _every_ data |
| 25 |
> file with no exception. |
| 26 |
|
| 27 |
partially covered with glep 33, definitely needs a repoman rewrite. |
| 28 |
|
| 29 |
> Key policies |
| 30 |
> ============ |
| 31 |
> |
| 32 |
> To make signing relevant and verifiable all devs should use the same |
| 33 |
> parameters - key length, key type, validity. |
| 34 |
> Once that is agreed upon a key distribution strategy is needed so that |
| 35 |
> users can get the key(s) on a verifiable path. |
| 36 |
|
| 37 |
From an implementation point of view the main questions here are: |
| 38 |
- how do we get the keys? (keyserver, stored in tree, ...) |
| 39 |
- how do we validate a key? |
| 40 |
|
| 41 |
> Signing strategies |
| 42 |
> ================== |
| 43 |
> |
| 44 |
> Once there is an agreement on what files to sign with what kind of |
| 45 |
> keys there remains the question how to sign it. There are at least |
| 46 |
> three strategies: |
| 47 |
> |
| 48 |
> Method "simple": |
| 49 |
> ---------------- |
| 50 |
> |
| 51 |
> Use one central key that is kept on a secure box. Signing is done |
| 52 |
> automatically after a commit. The key distribution is simple since |
| 53 |
> there |
| 54 |
> is only one key that has to be pushed. |
| 55 |
> Problems are security (single point of failure, single target for |
| 56 |
> compromising) |
| 57 |
> |
| 58 |
> Method "complex": |
| 59 |
> ----------------- |
| 60 |
> |
| 61 |
> Let every dev sign the files he adds or modifies. A keyring is |
| 62 |
> maintained on gentoo infrastructure and is distributed over multiple |
| 63 |
> paths. |
| 64 |
> Problems: Need support for multi-signing. If one file is added the |
| 65 |
> manifest should not be only signed by the last editor, only the |
| 66 |
> change should be signed. At the same time it needs to be kept simple |
| 67 |
> and fast, ssigning each file on its own or keeping infinite history |
| 68 |
> must be avoided. Keyring managment needs to be defined. Key |
| 69 |
> revocation etc. needs to be defined. |
| 70 |
> |
| 71 |
> Method "hybrid": |
| 72 |
> ---------------- |
| 73 |
> |
| 74 |
> Let every dev sign, add automatic server-side signing with a master |
| 75 |
> key. Gives you bits of both. Normal users can trust the master key. |
| 76 |
> Paranoid users can trust the dev keys. |
| 77 |
|
| 78 |
You're missing one option, the one currently in use: |
| 79 |
Any change to a package dir requires the package Manifest to be signed |
| 80 |
by the committing dev, including all files even if not changed by the |
| 81 |
commit. |
| 82 |
|
| 83 |
From an implementation POV it's desirable to only have one signature |
| 84 |
in a file, multiple signatures are problemtatic for parsing (for |
| 85 |
partial signatures) and verification (for both partial signatures and |
| 86 |
multiple full signatures). Detached signatures would make that easier, |
| 87 |
but are not an option due to overhead (>20k new files in the tree). |
| 88 |
|
| 89 |
Therefore I'd avoid the "complex" and "hybrid" solutions. |
| 90 |
|
| 91 |
> Some selected problems from there: |
| 92 |
> |
| 93 |
> * Access Control Lists could be used so that only toolchain people can |
| 94 |
> commit to glibc. Do we want that level of micromanagment? Does it |
| 95 |
> offer any security benefits? |
| 96 |
|
| 97 |
More a QA thing IMO, I don't see any security benefits. We've explicitly |
| 98 |
not done this in the past (technically it's not a problem, ACLs are |
| 99 |
used in other cvs modules). |
| 100 |
|
| 101 |
> * key revocation may be impractical - what methods for handling |
| 102 |
> retired devs and rogue devs are there? |
| 103 |
|
| 104 |
Part of the key policy. |
| 105 |
|
| 106 |
> * how to verify from an install CD ? |
| 107 |
|
| 108 |
key policy. |
| 109 |
|
| 110 |
> * in tree or out of band? Storing the keys in the tree is easy, but a |
| 111 |
> potential security problem |
| 112 |
|
| 113 |
key policy again. |
| 114 |
|
| 115 |
Marius |
| 116 |
|
| 117 |
-- |
| 118 |
Public Key at http://www.genone.de/info/gpg-key.pub |
| 119 |
|
| 120 |
In the beginning, there was nothing. And God said, 'Let there be |
| 121 |
Light.' And there was still nothing, but you could see a bit better. |
Archives