Date: Mon, 20 Jul 1998 22:34:59 -0500 From: Jon Hamilton <hamilton@pobox.com> To: Brett Glass <brett@lariat.org> Cc: "Matthew N. Dodd" <winter@jurai.net>, "Christopher G. Petrilli" <petrilli@dworkin.amber.org>, "Gentry A. Bieker" <gbieker@crown.NET>, security@FreeBSD.ORG Subject: Re: Why is there no info on the QPOPPER hack? Message-ID: <199807210332.UAA29219@hub.freebsd.org> In-Reply-To: Your message of "Mon, 20 Jul 1998 21:11:01 MDT." <199807210311.VAA00475@lariat.lariat.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199807210311.VAA00475@lariat.lariat.org>, Brett Glass wrote: } At 09:40 PM 7/20/98 -0500, Jon Hamilton wrote: } } >I still think you're just ranting. What does it mean to "have been } >potentially compromised" anyway? } } It means that many of these systems are still just WAITING to be broken } into. There could be a lot more damage done -- we're talking millions } of dollars' worth. The sky is falling! Where is that warranty? Oh, that's right, there isn't one. The people who are responsible for keeping those machines safe are just going to have to be responsible for keeping them safe, I guess. } >Maybe you've been working too long and too hard cleaning up after your } >breakin. CVSup would work fine for what you're talking about, you'd just } >have to have a different tag which only got "known good patches for } >significant problems". Of course, this would still have the problem of } >being a "pull" model, so you'd have to check "often enough". } } Which means, given the typical e-mail volume an administrator must handle, } many people would not "pull" in time. I'd rather have a "push" model with the } ability to back out or opt out. *shrug* fine with me. } >You'd also have to be damn sure you trusted the person doing the checkins, } } Anyone who runs FreeBSD already places a lot of trust in the maintainers. True, but how often do we see problems where "-current won't compile" or where patches went in which were unchecked or otherwise caused problems? You're talking about a volunteer effort, and I just don't see you getting the kind of rigor out of it that you'd need for something like you're suggesting. This is not meant to denigrate the effort any of the maintainers put in - I am arguing that it's not reasonable to expect such a level of effort from them, and if not them, then who? } >and } >you'd have to be sure that you were in fact talking to the server you } >decided to trust. } } Easily accomplished via cryptography. Wave your hands some more. Are you _really_ sure that you trust your local copy of pgp (or whatever other method you want to use)? You'd have to be 100% certain that no undesirable person had been able to get to your "master" machine to replace the kernel, your compiler, your crypto software, and the list goes on. Are you 100% sure? } >And you'd have to be certain that you trusted the patch } >as applied, both that it solved the problem it was meant to solve, and } >that it didn't introduce some other bogosity. Most of these should be } >red flags shouting out that you don't really want to automate this } >process, but I don't imagine that'll slow you down much. } } I would rather automate it than see delays, break-ins, and duplicated } effort. But automating it doesn't solve the problem, and it's not even clear to me that it improves the situation in a way useful to people who care about their security. You're proposing a non-solution which closes some of the holes some of the time, and in the process introduces another layer of complexity to managing your systems. You may think that's a big win, but I don't. There are way too many questions you claim are "easy" to solve that really aren't. -- Jon Hamilton hamilton@pobox.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807210332.UAA29219>