Date: Sat, 12 Jun 2004 13:50:49 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Robert Downes <nullentropy@lineone.net> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: chroot versus jail for the name daemon Message-ID: <20040612125049.GA62427@happy-idiot-talk.infracaninophile.co.uk> In-Reply-To: <40CAEEC5.5070108@lineone.net> References: <40CAEEC5.5070108@lineone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--XsQoSWH+UP9D9v3l
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jun 12, 2004 at 12:53:41PM +0100, Robert Downes wrote:
> Questions (for the old and wise):
> So, are there any FreeBSD-internals masters who can answer the following:
>=20
> 1) What happens if named is broken with neither chroot nor jail,=20
> assuming named is running as user and group bind (rather than as root)?
>=20
> 2) What happens if named is broken while using chroot?
>=20
> 3) What happens if named is broken while in a jail, and how is this=20
> less dangerous than using chroot?
Without the restriction of the named process either by using jail(8)
or chroot(2) anyone that can subvert the BIND process (presumably by
some sort of buffer overflow exploit) would be able to write files
anywhere on the system. That means an attacker can set things up so
that they can log in remotely as the bind UID, and once an attacker
has local access to your system, breaking root is a lot easier for
them.
Now, that assumes that there is a buffer overflow or some such in
named(8) that a remote user can exploit. Unfortunately it has been
shown again and again that in any project of the scale of BIND, such
things are almost impossible to avoid.
chroot'ing named does limit the damage that an attacker can do if they
break in via named -- there won't be any tools within the chroot'ed
area that an attacker can use, or any simple means whereby they can
copy those tools onto the system via the network. The same thing goes
for "thin" jails, but the tendency does seem to be for many jails to
be set up as "fat" -- ie. essentially complete BSD environments.
People will say, quite accurately, that even if an attacker can break
root in the jail, they don't automatically get to break root in the
host system. However, you should ask yourself if breaking root in the
host system is something an attacker would necessarily need to do,
given that they have managed to take over the almost equivalent
resources of the fat jail.
The thing about these sort of security measures is not that they offer
an absolute guarrantee that your system is unhackable -- no one can
promise that. The idea is to make attacking your system so difficult
and unrewarding that the black-hats go away and attack someone else
instead. However, all of those measures take up system resources and
management effort: it's a matter of judgement as to whether the costs
of imposing such things pay off the benefits of the increased
security.
My personal judgement is that the chroot(2) function built into
named(8) is easy to implement, costs virtually nothing to manage
compared to not doing it, and is well worth the bother and suficient
for the sort of low impact domains I'm running.
Even so, the prime security danger with named is not subversion of the
named process, but poisoning the actual DNS database itself. Securing
against that sort of thing is another kettle of fish -- there's a good
article or two at:
http://www.boran.com/security/sp/bind9_20010430.html
> Also, can FreeBSD run as a gateway with NAT while using a jail? A jail=20
> needs its own IP address, and that seems to intefere with the way other=
=20
> services need to be configured.
It can, but it is quite a bit more complex to manage, and there's the
whole 'split horizon' problem to deal with. (ie. you can create a
jail to contain a webserver on your NAT gateway, and you can make it
accessible either to your internal networks or to the Internet at
large, but making it accessible to both is rather harder.) If you are
particularly concerned about security, then it's a good idea to keep
your NAT gateway/firewall machine as simple as possible. Ideally, it
should run *only* the NAT/firewalling service.
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks
Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614 Bucks., SL7 1TH UK
--XsQoSWH+UP9D9v3l
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (FreeBSD)
iD8DBQFAyvwpiD657aJF7eIRAi4CAJ4sw+ra6SQUJ39Ifn6Im0rEL4DNEACfaeRE
DV3C0RK8yXWyQJaOA9Q3uzw=
=vJqy
-----END PGP SIGNATURE-----
--XsQoSWH+UP9D9v3l--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040612125049.GA62427>