On Mon, 2002-12-30 at 03:13, E.B. Dreger wrote: > JL> However, I'm one of those people who thought that bind could > JL> take care if this itself. > JL> > JL> Do you see this as a problem that came about with running > JL> bind as non-root user? > > I agree that BIND can take care of it on its own. That way is > simpler, no doubt. > > The main reason I have named.conf, $INCLUDE files (not standard > Cobalt), and root-zone cache owned by root:root is paranoia. If > there's a zero-day or negative-day exploit that falls into the > wrong hands, I don't want BIND able to overwrite certain files. > It's an attempt to minimize potential damage. > > Granted, there probably are bigger problems if BIND gets cracked. > However, I'm one of those paranoid minimalists; if BIND can run > with a file owned by root:root, that's how I run it. Whether or > not it's worthwhile certainly is open to debate. > > By contrast, I use default permissions on djbdns. On the DNS > server daemon I'm writing, I have several automated updates and > functions of my own. I'm less paranoid in these situations. > > Bottom line: BIND makes me nervous. I think my way is a correct > way, but not _the_ correct way. IMHO, letting BIND update the > root cache is equally valid... it just is not my personal > preference.
Actually, your solution looks insufficiantly paranoid to me. Imagine you are somehow tricked to dowload a bogus root cache... I would prefer to obtain the file by independant means (e.g. http[s]) and check its cryptograpic signature before replacing. The impact of getting a fake is too high. Eugene _______________________________________________ cobalt-security mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-security
