1 |
On Thursday 25 March 2004 12:14, Paul de Vrieze wrote: |
2 |
> |
3 |
> What if the old ACL on the system is so old that the people signing the |
4 |
> new ACL were not in the old ACL. I don't think forward signing is a good |
5 |
> (or secure idea). The parent dir system would require all devs to be in |
6 |
> the /usr/portage ACL anyway so still complicating things. |
7 |
|
8 |
Yes, this system requires regular updates, as does any security system. |
9 |
Does every dev to be able to create/modify any package? |
10 |
|
11 |
> We want to be able to implement ebuild signing fast (mainly to combat |
12 |
> rsync mirror compromise). Changing procedures beyond what is absolutely |
13 |
> necessary (entering your passphrase) would be a big impediment to doing |
14 |
> so. |
15 |
|
16 |
There is no difference from a normal developers viewpoint between this and |
17 |
your signing proposal. For the vast majority of packages it is not necessary |
18 |
to have more than one trusted developer! |
19 |
|
20 |
> The problem is that a manifest changes for any change in ebuilds or |
21 |
> patches. That means that for adding a keyword to a package one needs to |
22 |
> resign the manifest. |
23 |
|
24 |
Yes, a new release requires resigning. How does this differ from your |
25 |
proposal? |
26 |
|
27 |
> > > ps. Based on one public key on a single trusted source (A CD), how |
28 |
> > > do you ensure that the whole tree is uncompromised. |
29 |
> > |
30 |
> > You can't. Its an old tree which has already been signed. Trust it, or |
31 |
> > update to a new tree. |
32 |
> |
33 |
> As it is possible to have an approach that does offer such security, this |
34 |
> solution is inferior. |
35 |
|
36 |
You have an old copy of a signed tree. Without updating it is impossible to |
37 |
ensure that a compromise has not been discovered since then. Your solution is |
38 |
the same in this respect. |
39 |
|
40 |
> > > pps. How do you ensure that at a compromise of a key / or a rogue |
41 |
> > > developer this key is invalidated even when revocation is not |
42 |
> > > possible (like with a rogue developer) |
43 |
> > |
44 |
> > Remove the key from the ACL. |
45 |
> |
46 |
> Ok, how do you ensure that the ACL is updated? From what I understand it |
47 |
> would be easy to prevent the ACL from being updated just by generating |
48 |
> an invalid ACL. |
49 |
|
50 |
Thats the whole point. If the new ACL is invalid it won't be updated. If the |
51 |
new key is valid it will be updated. |
52 |
|
53 |
|
54 |
Some criticisms of your proposal: |
55 |
|
56 |
You are making the assumption that rsync servers are unsecure, whilst the |
57 |
computers of all gentoo developers are implicitly trusted. This is a basic |
58 |
security flaw, and probably an invalid assumption. There are more gentoo |
59 |
developers than rsync servers. Rsync servers are less vulnerable - they |
60 |
perform only one function, they don't read email, they don't browse the web. |
61 |
Why do you assume that rsync servers are more vulnerable, and that this |
62 |
problem needs to be addressed more urgently than the compromised developer |
63 |
problem? |
64 |
|
65 |
What do you do if the master key is compromised? |
66 |
|
67 |
Signing of daily keys by the master key will be automated. Once an attacker |
68 |
has compromised the gentoo server he can submit a rogue daily key to be |
69 |
signed. An attacker compromising this system could generate daily keys for |
70 |
every day in the next 100 years, thus totally compromising the system. |
71 |
|
72 |
Points of weakness in my proposal: |
73 |
|
74 |
You have to trust that an initial fetch of the tree hasn't been compromised. |
75 |
Single packages can be altered by >n devs compromised |
76 |
New packages can be created by >n devs compromised |
77 |
n==1 is possible, a single point of compromise |
78 |
If you don't update the tree regularly you may find that the new ACL hasn't |
79 |
been signed by enough people on the old ACL, if the ACL has changed enough. |
80 |
Compromised keys are only removed when user updates |
81 |
|
82 |
Points of weakness in your proposal: |
83 |
|
84 |
You have to trust that an initial fetch of the tree hasn't been compromised. |
85 |
You have to trust that every developer hasn't been compromised |
86 |
Single point of global failure - if gentoo server is compromised, master key |
87 |
is compromised, and attacker can do anything to any gentoo system. |
88 |
If signing server goes down it affects everybody |
89 |
Compromised keys are only removed when user updates |
90 |
|
91 |
Points of resilience in my proposal: |
92 |
|
93 |
Compromise of n devs is unlikely |
94 |
Distributed failure - compromise only effects small bits of the portage tree |
95 |
Distributed system - failure of one server doesn't affect operation of the |
96 |
rest of the system |
97 |
|
98 |
Points of resilience in your proposal: |
99 |
|
100 |
Master key can be held offline in a safe. But any signing key used day to day |
101 |
is vulnerable. |
102 |
|
103 |
Implementation details of my proposal: |
104 |
|
105 |
Requires simple post-check of emerge sync changes |
106 |
Developers must sign manifests |
107 |
Requires one file to be created in each directory saying which devs have |
108 |
access to that dir, and how many are required to agree on changes |
109 |
|
110 |
Implementation details of your proposal: |
111 |
|
112 |
Requires simple post-check of emerge sync changes |
113 |
Developers must sign manifests |
114 |
Requires establishment of secure infrastructure for global key, daily key |
115 |
signing, and submission of updates to developer list to this infrastructure |
116 |
|
117 |
My proposal does try to fix two problems at once. If the basic assumption that |
118 |
rsync servers are less secure than developers can't be trusted, then there is |
119 |
no point in fixing the former and not the latter. When the two subjects are |
120 |
so closely linked what is wrong with trying to create a combined solution? |
121 |
|
122 |
Regards, |
123 |
Chris |
124 |
|
125 |
-- |
126 |
gentoo-dev@g.o mailing list |