[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-security] Anyone else get this error?
- Subject: Re: [cobalt-security] Anyone else get this error?
- From: Eugene Crosser <crosser@xxxxxxxxxxx>
- Date: 30 Dec 2002 08:35:31 +0300
- Organization:
- List-id: Mailing list for users to address network security on Cobalt products. <cobalt-security.list.cobalt.com>
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