--On Tuesday, March 16, 2004 5:27 PM +0000 Ben Laurie <[EMAIL PROTECTED]> 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
