Setting up chroot on Solaris 9 with BIND 9 -t switch

[Bill Larson]

On Jan 5, 2005, at 9:02 PM, CERNINO CERNINO wrote:

> But i have a question, what gain with jailed the process?
> & if you kown then how can i jailed a user to only see a carpet as his 
> root,
> to then put the process & its dependecies into, as a new politic of 
> security
> for the user.
> can i do a user that cant get out of a carpet in other words, jailed 
> in a
> carpet as his home directory?

Think of similar questions, "why have passwords", "why use a firewall", 
"why worry about security"?  The simple answer is that you need to 
protect your system from attackers.

"chroot", not just for BIND but in general, protects your server from 
an increase risk of compromise when your system is attacked through the 
process that is running in the chroot environment.  "chroot" limits the 
scope of what can be seen on the system to the "chroot" environment and 
makes the rest of your system, such as your passwd file, off limits.

There is another side of running a BIND DNS server in a "secure" 
environment.  This is to run "named" as an unprivileged user.  This is 
simply to further limit the amount of damage an attacker can perform 
when the process is broken out of.  When the process is broken, the 
attacker will have the same privileges as the process had.  If the 
process was running as "root", then the attacker will then have "root" 
access to the system.  If the process is not running as "root", then 
the attacker will be limited to whatever the the process as.  In the 
case of "named", the attacker would be limited to trashing the files 
and directories that the "named" process can write to.  But, the 
attacker will be unable to compromise the system further because they 
still lack the ability to write to anything else.  (If the "named" 
process logs to "syslog", then the attacker can also write to the 
"syslogd" process and now you have to worry if the syslogd process can 
be compromised!  The security aspects simply cascade.)

 From the BIND-ARM the following statement is made: "We suggest running 
as an unprivileged user when using the chroot feature."  The authors of 
BIND recognize the additional security provided by running "named" in a 
chroot environment with the "-t" option, and also the desire to further 
protect the system by limiting the access available by running as an 
unprivileged user using the "-u" option.

For further information about running "named" in a secure fashion, 
please refer to "The Secure BIND Template" at 
http://www.cymru.com/Documents/secure-bind-template.html.  This also 
identifies a also a good procedure to configure a chroot environment 
for "named" when running under Solaris, FreeBSD, and Linux.

Further information about "chroot" in general can be found at:

	http://www.unixwiz.net/techtips/chroot-practices.html
	http://www.l0t3k.org/security/docs/chrooting/
	http://www.nuclearelephant.com/papers/chroot.html
	http://www.linuxsecurity.com/content/view/117632/49/
	http://www.onlamp.com/pub/a/bsd/2003/01/23/chroot.html
	http://www.bpfh.net/simes/computing/chroot-break.html

The last reference is "Breaking out of a chroot() padded cell" and 
simply discusses the consequences of the failure of running a process 
in a chroot environment and why the protected process shouldn't be run 
as the "root" user.  I particularly like this document.

Security is not a single thing.  One aspect of security in "protection 
in depth", having multiple security layers that need to be broken in 
sequence before the system is completely compromised.  Software 
development with an eye for security is one layer.  Using good 
passwords is another security layer.  Running the application in a 
chroot environment is still another.  Running in a chroot environment 
is an inexpensive way to provide an additional layer of security to 
running a process that is accessible over the Internet.  BIND is not 
the only application that does this.  Apache is another network process 
which used a chroot environment to protect itself.

Now, as to your other implied question, "how do I test named running in 
a chroot environment", I really don't have a good answer.  The only way 
that I can think of is to break out of the "named" process in some 
manner, such as with a buffer overflow attack, and see what will 
happen.  I'm not that good, and if you succeed then you should inform 
the BIND developers of your exploit and they can protect the process 
even further.

Bill Larson