1 |
On Sat, 20 May 2006 15:37:54 +0100, Chris Bainbridge wrote: |
2 |
|
3 |
> On 20/05/06, Peter <pete4abw@×××××××.net> wrote: |
4 |
>> PMFJI, but as a user, not a security expert, I had a few thoughts that I'd |
5 |
>> like to throw in. Thanks to Patrick, he helped me to drill down some of |
6 |
>> the ideas and I present them for consideration. It's just a framework, so |
7 |
>> I will be brief |
8 |
> |
9 |
Thanks for not throwing me overboard to the sharks! I had a few comments. |
10 |
|
11 |
> Thanks for your input. From a security point of view your scheme is |
12 |
> fine, but as pointed out by others you won't be able to selectively |
13 |
> rsync parts of the tree. That will require a signature for each |
14 |
> manifest, and a manifest for every directory. The problem I see is that |
15 |
> the manifest is going to have to include a hash for each subdirectory - |
16 |
> otherwise you open the possibility of someone replacing a directory with |
17 |
> one from the past that contains some known insecurity, or corrupting the |
18 |
> tree by swapping random directories, and yet the signatures remain |
19 |
> valid. Of course, that hash changes if you allow people to rsync_exclude |
20 |
> directories, and hence the signature changes. So you can either accept |
21 |
> that if you selectively rsync then you won't be able to verify the |
22 |
> signed tree, or accept that there is a known security problem with |
23 |
> having no signed link between parent and child directories, or come up |
24 |
> with a different scheme. |
25 |
|
26 |
I'm not sure this is so. Yes, the Manifest file will have to include all |
27 |
files in it's current and child[ren] directories. However, this is done |
28 |
now. You would have to include eclass and profiles to have Manifests also. |
29 |
|
30 |
I do not see how using rsync exclude would affect this scheme. If someone |
31 |
wants to emerge samba and exclude KDE, the hash of the samba Manifest |
32 |
will be there to check against. I'm not interested in signing the entire |
33 |
tree. I am interested in signing the hashes of all Manifests in the tree |
34 |
as a list. So, during the emerge process, as each package is emerged, the |
35 |
first thing that occurs is to check the hash of the package Manifest file |
36 |
against the stored hash in the signed Master Manifest file. Sort of like: |
37 |
|
38 |
In pigeon bash and pseudo code, here's how I envision the check. |
39 |
gpg --verify MasterManifestFile |
40 |
# if error then abort |
41 |
M_HASH=${grep "samba/Manifest" MasterManifestFile) |
42 |
# probably need to use cut or something here... |
43 |
C_HASH=$(md5sum samba/Manifest) |
44 |
if M_HASH -ne C_HASH then abort |
45 |
|
46 |
> Obviously the manifests also have to be checked to make sure they're |
47 |
> valid - this is currently done for package directories at emerge time, |
48 |
> it would need to be extended to all other directories. I'd prefer the |
49 |
> checks done at sync time since that's a one time cost and you don't have |
50 |
> to figure out exactly what files will be used by each emerge operation. |
51 |
|
52 |
My thought was, that even if someone inserted a rogue package onto one of |
53 |
the mirrors, a) altering the MasterManifest file would be difficult since |
54 |
the signed part would not match, b) The Manifest hash would not match, or |
55 |
if the bad guy did not alter the Manifest, the hash of its files would not |
56 |
match (such as replacing a source dl location). |
57 |
|
58 |
Anyway, thanks for taking a look. |
59 |
|
60 |
-- |
61 |
Peter |
62 |
|
63 |
|
64 |
-- |
65 |
gentoo-dev@g.o mailing list |