[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cobalt-security] Anyone else get this error?



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