☰

どこかに chroot ビルド スクリプトはありますか?

tag-icon • tag-icon linux centos scripting chroot
どこかに chroot ビルド スクリプトはありますか?

私は chroot-jail の情報を収集するための小さなスクリプトを開発しようとしています。

私の場合、これは (一見すると) かなり単純に見えます。アプリケーションにはクリーンな rpm インストールがあり、ほぼすべてのファイルが /opt のサブディレクトリにインストールされています。

私の考えは：

  • すべてのバイナリを検索する
  • ライブラリの依存関係を確認する
  • 結果をリストに記録する
  • アプリケーションの起動前に、そのリストをchrootターゲットディレクトリにrsyncします。

ここで疑問に思うのは、すでにそのような作業を実行するスクリプト (perl/bash/python) が存在するかどうかです。

これまでのところ、単一のアプリケーション (sftp-chroot など) に特化したソリューションしか見つかりませんでした。

ただし、それは問題ではありません (私見) - OS は CentOS 5 x86_64 の現在のマイナー リリースおよびパッチ レベルです。

rpm -ql私の意見では、これは十分に一般的ではない。回転数ベースのディストリビューション。上記の「クリーン インストール」という説明は、ソフトウェアのファイルがファイル システム全体に分散されていないことを言及するためだけのものです。そのため、現時点での私の出発点は、find /opt/directory/ほぼすべてのシステム (Linux 以外でも) で動作するはずの ... です。

答え1

テンプレート chroot を作成し、通常の OS と同じように必要なパッケージをすべてインストールすることをお勧めします。その後、通常のツール (更新スクリプト、パッケージ マネージャーなど) を使用して chroot を管理し、そのテンプレートを使用して構築された各 chroot に更新を rsync できます。

このアプローチにはいくつかの利点があります。2つの大きな利点は、使い慣れたツールを使ってテンプレートを管理できること（chrootをアップグレードするために奇妙な手順を踏む必要がない）と、1つのchrootがあればできない何らかの理由で更新する必要がある場合 (たとえば、あるパッケージの特定のバージョンが必要な場合)、rsyncアップグレード プロセスから除外し、スタンドアロン マシンであるかのように独立して管理し、パッケージを「保留」または同等のものとしてマークして、邪魔されないようにすることができます。

走行距離 (および実装要件) は異なる場合があります...

答え2

現時点での私のスクリプトは次のとおりです。

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

まだ存在する問題: chroot 内にシェル ファイルがあります。それらは他のバイナリを参照している可能性があります。

回避策として、これらを手動で $FILES に配置する必要があります。

答え3

というツールセットがありますジェイルキット。

これはLinuxでも動作するかもしれません。ホームページによると、動作することが確認されています。

  • ソラリス
  • 「多くの」Linuxディストリビューション
  • オープンBSD
  • フリーBSD
  • MacOSX

依存関係は良好です:

  • libc の
  • パイソン
  • POSIX スレッド

答え4

最初のアプローチ (サービスはアプリケーション自体): すべての「通常の」バイナリ、ライブラリなどに対して chroot で bind-ro-mount を実行します。

  • /等
  • /置き場
  • /usr
  • /ライブラリ
  • /lib64
  • /var
  • /ホーム/使用済みアカウント
  • /opt/サービス

これで、chrootでサービスが実行されるかどうかをテストできました。驚いたことに、HIDSは、サブディレクトリに書き込みがあることを教えてくれました。/opt/サービス。

そこで、シェルを使用して手動で chroot し、書き込みアクセスをテストしました - うまくいきました!

他に何も役に立たない場合は、RTFM を参照してください。man mount読み取り専用バインド マウントはカーネル 2.6.26 以上でのみ機能することを示唆しています (残念ながら CentOS 5 は 2.6.18 です)。

もう一つの欠点は、潜在的な攻撃者がオペレーティング システム ツールの完全なセットを入手してしまうことです。

関連情報