Re: secured bind default?
Hi all,
Over the last few months I've been piecing together a security paper. I
have a small section on chroot jails which may apply. Comments and
suggestions very welcome!
--8<-- snip --
The convention of running potentialy high risk daemons within a chroot
environment is rapidly catching on and thus deserves our attention.
There are a couple of reasons chroot jails have become popular. Firstly,
many daemons run as root and accept user input. Since the daemon, for
arguments sake, is usually not filtered from the general public this
poses an enormous potential security threat. The purpose of running a
daemon in a chroot is to trap the attacker within the chroot should they
sucessfully exploit the daemon. Secondly, the chroot allows for a
pristine filesystem used only by one daemon which can be nice for admin
purposes.
So what's wrong with the chroot jail concept? Having a minimal copy of
the filesystem within a directory for chroot puposes makes updating the
system cumbersome. Binaries and configuration files can get out of sync
with the real system. What's worse is that if you host user pages they
will have to maintain their site within the chroot'd filesystem. Having
duplicates of all the binaries, directories, libraries etc. can take up
a lot of space. If you decide to go with a chroot jail you should set
quotas on the chroot directories in addition to the quotas you set for
users home directories. You will most likely want to modify your
`adduser' script to create not only `/home/user' but also
`/jail/home/user'. Since most daemons are not written with chroot in
mind using a chroot jail will require a lot of work on the part of the
admin.
One tool that can be used to keep the chroot current with the real file
system is `rsync'. Using `rsync' can save you considerable time once you
have some scripts setup to automate the maintainance tasks. Here's a
small example of what you might create. Since I'm crippled without net
access at the time of writing this I cannot make a proper script (My x86
has apache installed but not rsync and my ppc has rsync but no apache.
I'll have to keep sources handy in the future). Here's an example that
you can expand on:
--8<-- chroot_jail.sh --
#!/bin/sh
#
# Script to facilitate creating a chroot'd jail
# by core
echo "apache_chroot.sh by core"
echo "Updating apache jail. You may need to edit the files:"
echo " jail_excludes"
echo "to match your system."
## Comment out these two lines to not remove the entire chroot and
recreate it
# each time
echo "Comment the following line and next line out after testing is
done!"
rm -rf /path/to/jail/*
##
# I suggest the following parameters to rsync for creating a good
# and easily update jail with one script
#
# -v = verbose
# -r = recursive
# -u = update (no clobber)
# -l = preserve soft links
# -H = preserve hard links
# -p = preserve permissions
# -o = preserve owner
# -g = preserve group
# -D = preserve devices
# -t = preserve times
#
# --exclude="*" Perhaps easier to not copy any files and selectively add
# only files you need. Lots easier than excluding 90% of
# the filesystem >;)
# But this can be a bitch so using jail_excludes for now
#
# --include-from=jail_includes
# Add files you need in the chroot to this file >:)
#
# --progress Show the progress
/usr/bin/rsync -vrulHpogDt \
--exclude-from=jail_excludes \
--progress \
/ /path/to/jail
echo "Done updating apache jail."
--8<-- eof --
One nice feature of rsync is that you can combine the excludes and
includes file into one file by prepending +/- to rules. Use this in
combination with an `rsync' excludes file for best results. Here's an
example of an excludes file that only copies /bin/*, /sbin/*, an empty
/tmp, /home/user/public_html/*, excludes .mp3 files etc.:
--8<-- jail_excludes --
# "+ " denotes include
# "- " denotes exclude
# see rsync manual page for more details
- /proc/
- /boot/
- /initrd/
- /mnt/
- /root/
- /etc/
- /lib/
- /var/
- /usr/
- /dev/
- /tmp/*
+ /home/*/public_html/
- /home/*/*
- lost+found/
- *.mp3
- /devel/
- /vmlinux
- /dist
- /scratch/
--8<-- eof --
Is a chroot really secure or just another example of security through
obscurity? It's debatable, however, with chroot breaking shellcode
attackers can easily jump outside the chroot'd environment. Even if it
is not possible to break out of the chroot a savvy attacker will
download binaries to the chroot and `mknod' devices. Once devices have
been made the attacker can create directories and mount the real
filesystem and then `chroot' to the real filesystem.
In my opinion a chroot jail for daemons is more effort than it's worth.
Then again the alternative is not exactly cut and dry either. One would
need to setup users and groups so that the service can run as a non-root
user and still function correctly. Perhaps the most secure solution
would be a combination of running the service as an unpriveleged user
within a chroot.
--8<-- snip --
Best Regards,
Charles Stevenson
Alvin Oga wrote:
>
> hi ya
>
> or one could write a new script to re-install it into its own chroot jail
>
> c ya
> alvin
> http://www.Linux-Sec.net/Harden/server.gwif.html#DNS .. DNS stuff
>
> On Thu, 12 Jul 2001, Sebastiaan wrote:
>
> > Hi,
> >
> > It is known that running a domain name server in a chroot jail is more
> > secure than running it the default way. I have also heard this about other
> > packages. So my question: would it not be smart/handy to have this
> > opportunity during install? When installing bind, a question could be
> > asked if you want it run default or in a chroot enviro. I do not think it
> > is very difficult to extend the installation scripts? It would make
> > security easier.
> >
> > Greetz,
> > Sebastiaan
>
> --
> To UNSUBSCRIBE, email to debian-security-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: