Home / server / Questions / 438892
Accepted
Nils
Asked: 2012-10-17 03:31:34 +0800 CST

Is there a chroot build script somewhere?

  • 772

I am about to develop a little script to gather information for a chroot-jail.

In my case this looks (at the first glance) pretty simple: The application has a clean rpm-install and did install almost all files into a sub-directory of /opt.

My idea is:

  • Do a find of all binaries
  • Check their library-dependencies
  • Record the results into a list
  • Do a rsync of that list into the chroot-target-directory before startup of the application

Now I wonder - ist there any script around that already does such a job (perl/bash/python)?

So far I found only specialized solutions for single applications (like sftp-chroot).

Although is does not matter (imho) - OS is CentOS 5 x86_64 current minor release and patch-level.

rpm -ql is IMHO not generic enough, since it will only cover rpm-based distributions. The mention of the "clean install" above was just to mention that the files of the software are not distributed across the whole file-system. So my starting point is - at the moment - a find /opt/directory/... that should work on almost any system (even not Linux).

linux

4 Answers

  1. I would suggest creating a template chroot and installing all the packages you want just like it was a normal OS. After that you can manage the chroot using your typical tools (update scripts, package manager, etc.) and rsync the updates into each chroot built using that template.

    There are a few advantages to this approach. The two big ones are you can manage the template using familiar tools (no strange hoops to jump through to upgrade your chroot), and if you have one chroot which can't be updated for some reason (say it needs a particular version of some package) you can exclude it from the rsync upgrade process and manage it independently as though it were a standalone machine, marking the package as "held" or equivalent so it doesn't get stomped on.

    Your mileage (and implementation requirements) may vary...

    • 2

  2. First approach (service is the application itself): Do a bind-ro-mount in the chroot for all the "usual" binaries, libs, etc...:

    • /etc
    • /bin
    • /usr
    • /lib
    • /lib64
    • /var
    • /home/used_accounts
    • /opt/service

    Now this was ok to test if the service runs in the chroot. To my astonishment my HIDS told me that there was a write located in a sub-directory in /opt/service.

    So I manually chrooted into this with a shell and tested write-access - which worked!

    So if nothing else helps - RTFM. man mount hinted that a read-only-bind-mount only works with kernel 2.6.26 or greater (bad luck here: CentOS 5 is 2.6.18).

    Another drawback: This leaves a potential attacker with the full set of operating-system-tools.

    • 0

  3. Now this is, where my scipt is at the moment:

    mkchroot.cfg:

    # Configuration file for building a chroot envirnoment with Linux
#
# V 1.2 2012-10-24
#
# Define which directories to scan for executables
#  use space to separate directories
DIRS="/opt/application /opt/bin"
#
# Define a number of files to check outside the dirctories set in the DIRS
# directive above. Use space to separate entries.
FILES="/bin/sh"
#
# Define additional things that should be added to chroot without check.
# This could be block or char-devices. Use space to separate entries. 
ADDITIONAL="/dev/urandom /dev/null /var/lock/subsys /var/application"
#
# Target chroot-directory
TARGETDIR=="/var/lib/application"
#
# Here goes the list of files that has to be synced to chroot
FILELIST="/tmp/chroot_files.dat"
#

    mkchroot.sh

    #!/bin/sh
. /opt/application/mkchroot.cfg
getlibs ()
{
  # Parameter1: Name of a file containing files to check
  for b in $(cat ${1})
    do
      ldd $b |grep -v ":"|grep "/"|sed "s/.*>//g; s/ (.*//g"|awk '{print $1}'
  done
}
# Main program
clear
for f in ${FILELIST}_bin ${FILELIST}_tmp ${FILELIST}_lib ${FILELIST}
  do
    [ -f $f ] && rm $f
done
for d in $DIRS
  do
    echo Build filelist for directory $d
    find $d -type f -exec file {} \; 2>/dev/null |grep ELF |cut -d : -f 1 >>${FILELIST}_bin
done
for f in $FILES
  do
    echo $f >>${FILELIST}_bin
done
echo Find libaries on stage 1
getlibs ${FILELIST}_bin >>${FILELIST}_tmp
# Now find indirect libraries until list does not get any longer...
sort -u ${FILELIST}_tmp >${FILELIST}_lib
typeset -i LIBNEW="$(wc -l <${FILELIST}_lib )" LIBOLD=0 STAGE=2
while [ $LIBNEW -ne $LIBOLD ]
  do
    echo Find libaries on stage $STAGE
    let STAGE++
    LIBOLD=$LIBNEW
    cp ${FILELIST}_lib ${FILELIST}_tmp
    getlibs ${FILELIST}_lib >>${FILELIST}_tmp
    sort -u ${FILELIST}_tmp >${FILELIST}_lib
    LIBNEW=$(wc -l <${FILELIST}_lib)
done
cp ${FILELIST}_lib ${FILELIST}_tmp
for e in $ADDITIONAL
  do
    echo $e >>${FILELIST}_tmp
done
echo Für chroot zu synchronisierende Dateien:
GDIRS=$(echo $DIRS |sed "s/ /\\\|/g;")
grep -v "$GDIRS" ${FILELIST}_tmp |sort -u >${FILELIST}
cat $FILELIST

    Problem that still exists: There are shell-files within my chroot. They might reference some other binaries.

    As workaround these have to be put manually into $FILES.

    • 0
  4. Best Answer

    There is a set of tools named jailkit.

    This may work with linux, too. According to its home-page it is confirmed to work with

    • Solaris
    • "many" Linux distributions
    • OpenBSD
    • FreeBSD
    • MacOSX

    Its dependencies look good:

    • (g)libc
    • python
    • posix threads
    • 0