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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
