Public SourceMage Discussion List

[Seth Woolley <seth AT tautology.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for your input.  replies below:

Seth

On Fri, 19 Sep 2003, elaine wrote:

>
> Looks good.
>
> I just have some comments on the chroot part. Obviously I can't cast
> this to test so I may be missing some things.
>
>
> 1. at least on OpenBSD running named in chroot() requires syslogd to have
> priorly created dev/log socket inside the chroot. e.g.:
>
> syslogd -a /var/named/dev/log
>

I'll look into this. named does usually report to syslog, and I think it
was working without my having to do anything.  I think it used the
standard logging system call, which would bypass the socket.

Last I checked, OpenBSD used version 4 though.

>
> 2.  chown  -R  bind:bind  /etc/bind
>
> This probably gives write permission to the daemon on files it should *not*
> be able to such as etc/rndc.key, etc/named.conf

That's true, and I should change that to root:bind or remove that line
altogether, and if I leave it, make sure to chmod it recursively so that
group doesn't have write access in any case.  I do chmod those other files
back later (possible race to be avoied), and it does need write access to
/etc/bind to create/write the named.pid file.  It also needs access to
/etc/bind/s as well, so anybody could write into that directory if they
did get in.

>
>
> 3. mknod creation of dev/random inside the chroot.
>
> Unless your named is actually making use of the entropy pool I would
> call this a bad idea.

It does, since it complains in syslog if it can't read this and I believe
it uses it to initiate its own queries to the upstream DNS to avoid an
attacker being able to guess the proper sequence and thus spoil the cache.
This only important for UDP packets, of course, I would think.

>
> If the daemon were compromised, this would permit the attacker to target
> the entropy pool, that is at least a DOS potential and at worst could
> degrade the security of say sshd.

Understood.

>
> (I'm not sure it would even be desirable to create dev/urandom as the last
> I looked that device will also deplete the pool, but provides pseudo-random
> bits after /dev/random blocks for reading.)
>

Exactly.  Unless there were a device that could have a restricted entropy
pool, I'm not sure I can help this.

>
> elaine
>
> On Fri, 19 Sep 2003 03:51:57 -0700 (PDT) (unchecked - local sync NTPstrat4)
> Seth Woolley <seth AT tautology.org> did inscribe thusly:
>
> >
> > Please test it.  To prevent DOS attacks on /etc/ I had it move the config
> > and the chroot dir over to /var/chroot/bind which has a symlink
> > from /etc/bind.  there's a symlink from /etc/bind/etc/bind back to / so
> > that chrooting doesn't require a modification to the config (just remove
> > the -t /etc/bind from the init script to make it not chroot).
>

- --
Seth Alan Woolley <seth at tautology.org>, SPAM/UCE is unauthorized
Key id 7BEACC7D = 2978 0BD1 BA48 B671 C1EB 93F7 EDF4 3CDF 7BEA CC7D
Full Key at seth.tautology.org and pgp.mit.edu. info: www.gnupg.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/a0GX7fQ833vqzH0RApo1AJ9w7/yoSPH7BFgSG4mk5g2fIgL7fgCgsyF8
9wvvz/LEwktDjWYfxMLT67w=
=pq8R
-----END PGP SIGNATURE-----