chroot versus jail for the name daemon

2004-06-12 Thread Robert Downes
Newbie Fodder (skip down the page if old and wise):
The FreeBSD Handbook describes running BIND (named) in a sandbox, i.e. 
using chroot to force the named to think that its place in the 
filesystem is actually the filesystem root when it's not, so it sees 
/somewhere/deep/inthe/file/jungle as /. So if hackers break named they 
theoretically cannot attack the real root of the filesystem, only what 
is within the chroot path.

Then the Handbook rather offhandedly mentions that some people would 
recommend putting named into a jail instead. So I've been looking into 
the jail system in FreeBSD, and comments suggest that it offers better 
security. On the surface, jail seems to do the same thing: deceive a 
process into believing that its place in the filesystem is root, and 
stopping access to directories outside that path.

Questions (for the old and wise):
So, are there any FreeBSD-internals masters who can answer the following:
   1) What happens if named is broken with neither chroot nor jail, 
assuming named is running as user and group bind (rather than as root)?

   2) What happens if named is broken while using chroot?
   3) What happens if named is broken while in a jail, and how is this 
less dangerous than using chroot?

Also, can FreeBSD run as a gateway with NAT while using a jail? A jail 
needs its own IP address, and that seems to intefere with the way other 
services need to be configured.
--
Bob
London, UK
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: chroot versus jail for the name daemon

2004-06-12 Thread Matthew Seaman
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:
 
1) What happens if named is broken with neither chroot nor jail, 
 assuming named is running as user and group bind (rather than as root)?
 
2) What happens if named is broken while using chroot?
 
3) What happens if named is broken while in a jail, and how is this 
 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 
 needs its own IP address, and that seems to intefere with the way other 
 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

-- 
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


pgpqeHT4E5PFZ.pgp
Description: PGP signature