| 1 |
On 19/05/06, Patrick Lauer <patrick@g.o> wrote: |
| 2 |
> On Fri, 2006-05-19 at 15:13 +0100, Chris Bainbridge wrote: |
| 3 |
> > There are now several hundred gentoo developers. It is more likely |
| 4 |
> > that one of them has a security lapse than cvs.gentoo.org. |
| 5 |
> One is a "local" bug, the other one "global". |
| 6 |
> I'd prefer a system that is resilient against two devs going crazy - |
| 7 |
> right now the "right" persons could stage a manipulation that would be |
| 8 |
> hard to detect and where your (single central) signature fails quite |
| 9 |
> nicely. |
| 10 |
|
| 11 |
Realistically, you have to trust the gentoo devs. The only system that |
| 12 |
won't fail against the rogue developer threat is to have multiple |
| 13 |
sign-off on commits. Most developers don't want that. Even if it were |
| 14 |
required, it would only raise the bar slightly - all a rogue developer |
| 15 |
would have to do is to establish a new id, fix some bugs, and |
| 16 |
"recruit" themselves. |
| 17 |
|
| 18 |
> It's very coarse - Yes / No |
| 19 |
|
| 20 |
> Doesn't tell you what failed how ... so I DoS it by inserting one bit on |
| 21 |
> any rsync mirror and it will "fail". You don't know what fails where ... |
| 22 |
|
| 23 |
> You can't upgrade and you don't know what fails where ... |
| 24 |
> Right, but ... what caused the error? |
| 25 |
|
| 26 |
It doesn't matter which bit in which file was changed - if an attacker |
| 27 |
has access to corrupt the tree, then the whole tree is suspect and |
| 28 |
can't be trusted. From a users point of view - they don't care what |
| 29 |
caused the error, they just sync again with a different server.. From |
| 30 |
a developers point of view - you can just diff the corrupt server |
| 31 |
against your local tree and look for exploit code. |
| 32 |
|
| 33 |
> > It could be done in stages. Start with the (easier) central key, then |
| 34 |
> > later add distributed keys. I think a hybrid system would be the ideal |
| 35 |
> > system, but realistically, bug #5902 has been around since March 2003 |
| 36 |
> > and no real progress has been made. |
| 37 |
> That bug appears quite unrelated to me ... how does FEATURES="userpriv" |
| 38 |
> relate to signing? |
| 39 |
|
| 40 |
#5902 is "emerge security - running as root and digital signatures". |
| 41 |
Digital signatures have something to do with signing ;-) Actually, the |
| 42 |
bug has been open since August 2002... |
| 43 |
|
| 44 |
> > The main sticking point seems to |
| 45 |
> > be disagreements over key management and policies. I would hope that |
| 46 |
> > most people could agree that a single key with a post-commit signing |
| 47 |
> > is better than what we have now, |
| 48 |
> debatable |
| 49 |
|
| 50 |
It's debatable that a centralised signing the tree is better than not |
| 51 |
having any security at all? |
| 52 |
|
| 53 |
> > and could be easily implemented, |
| 54 |
> yes |
| 55 |
> > whilst leaving open the option of a hybrid system implementation at a |
| 56 |
> > later date. |
| 57 |
> yes |
| 58 |
> |
| 59 |
> but that's not a cure. You'd have to sign _each file_ to get a |
| 60 |
> reasonable tampering detection, or at least per-directory. You add a |
| 61 |
> single point of failure and give attackers a high-profile target. |
| 62 |
|
| 63 |
It depends... what is the purpose of signing individual files? If it's |
| 64 |
to find the point of corruption, then you can just diff the corrupt |
| 65 |
tree against a good one and look for any exploit like code. Look at it |
| 66 |
this way - when emerge detects a corrupt tar.gz in distfiles, it |
| 67 |
doesn't tell you exactly what file in the package is corrupt. It just |
| 68 |
downloads it from someplace else. The same principle can be applied to |
| 69 |
the portage tree. |
| 70 |
|
| 71 |
I'm open to the possibility of signing every file/directory |
| 72 |
individually if there's a good reason, but I don't see one at the |
| 73 |
moment. |
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-dev@g.o mailing list |
Archives