httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: [PROPOSAL] Move httpd to the subversion repository
Date Tue, 16 Mar 2004 20:19:31 GMT
Justin Erenkrantz wrote:

> --On Tuesday, March 16, 2004 5:27 PM +0000 Ben Laurie 
> <ben@algroup.co.uk> wrote:
> 
>> I don't see how this defends against a malicious user that has owned the
>> server for long enough for his changes to have been rsynced to the 
>> "secure"
>> server?
> 
> Because it'd be read-only?  That is, the changes won't be on the 
> 'secure' server (i.e. they can't modify things *before* the box was 
> compromised).  Once it's compromised, sure, the malicious user can do 
> 'bad' things, but, that's true with any system.  Digital signatures by a 
> committer don't add any protection here, either.  Those compromised 
> committers can do bad commits, too.  However, once the malicious commits 
> are identified, they can be easily rolled back and/or removed from the 
> repository...

Hang on. I'm not suggesting that I have some kind of magic bullet that 
will fix this problem, but there are some fundamental problems with what 
you say here:

a) A compromised server _cannot_ fake user signatures

b) Server signatures do _not_ help with compromised users

c) You appear to be assuming daily snapshots maintained forever in your 
story - if so, how do you deal with network problems and the like? How 
can you tell a commit that didn't make it to the "secure" server because 
of a network problem from one that the attacker injected?

> Do you have a suggestion here?
> 
>> I have yet to be convinced of this.
> 
> I'm just not sure what you're looking for here.  CVS offers *nothing* in 
> the way of integrity checking.  Subversion at least gets us moving in 
> the right direction.  I think you're underestimating the issues we have 
> auditing our CVS repository.  *shrug*

No, I'm saying that if you want to move in the right direction, applying 
PKI magic pixie dust isn't the way to do it - you have to define your 
threat model and construct a plausible defence against it.

In the solution you've rather vaguely outlined, after a server 
compromise I find myself checking a bunch of commits signed by the 
compromised server and then making some other vague assumptions I'm not 
sure I understand to convince myself that they were pre-compromise 
signatures. I don't feel like my security has been improved. Possibly a 
clearer explanation is all that is required, or maybe a rethink. I can't 
tell at this stage.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

Mime
View raw message