
나는 chroot-jail에 대한 정보를 수집하기 위한 작은 스크립트를 개발하려고 합니다.
내 경우에는 (첫눈에) 매우 간단해 보입니다. 응용 프로그램에는 깨끗한 rpm 설치가 있고 거의 모든 파일을 /opt의 하위 디렉터리에 설치했습니다.
내 생각은 다음과 같습니다
- 모든 바이너리를 찾습니다.
- 라이브러리 종속성을 확인하세요.
- 결과를 목록에 기록
- 애플리케이션을 시작하기 전에 해당 목록을 chroot-target-directory로 rsync하십시오.
이제 궁금합니다. 이미 그러한 작업을 수행하는 스크립트(perl/bash/python)가 있습니까?
지금까지 나는 단일 애플리케이션(예: sftp-chroot)에 대한 전문 솔루션만을 찾았습니다.
중요하지는 않지만(imho) - OS는 CentOS 5 x86_64 현재 마이너 릴리스 및 패치 수준입니다.
rpm -ql
IMHO는 충분히 일반적이지 않습니다.rpm기반 배포. 위에서 "새로 설치"에 대해 언급한 것은 소프트웨어 파일이 전체 파일 시스템에 배포되지 않는다는 점을 언급한 것뿐입니다. 그래서 나의 출발점은 - 현재로서는 - find /opt/directory/
거의 모든 시스템(Linux가 아니더라도)에서 작동해야 하는 것입니다.
답변1
chroot 템플릿을 생성하고 일반 OS처럼 원하는 모든 패키지를 설치하는 것이 좋습니다. 그런 다음 일반적인 도구(업데이트 스크립트, 패키지 관리자 등)를 사용하여 chroot를 관리하고 해당 템플릿을 사용하여 구축된 각 chroot에 업데이트를 rsync할 수 있습니다.
이 접근 방식에는 몇 가지 장점이 있습니다. 두 가지 큰 점은 친숙한 도구를 사용하여 템플릿을 관리할 수 있다는 것입니다(chroot를 업그레이드하기 위해 뛰어넘어야 하는 이상한 과정이 없음).캔트어떤 이유로든 업데이트되는 경우(일부 패키지의 특정 버전이 필요함) rsync
업그레이드 프로세스에서 해당 패키지를 제외하고 마치 독립 실행형 시스템인 것처럼 독립적으로 관리할 수 있습니다. 짓밟히다.
귀하의 마일리지(및 구현 요구 사항)는 다를 수 있습니다...
답변2
이제 이것은 현재 내 scipt가 있는 곳입니다.
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 배포판
- 오픈BSD
- FreeBSD
- 맥 OS X
종속성이 좋아 보입니다.
- (g) libc
- 파이썬
- POSIX 스레드
답변4
첫 번째 접근 방식(서비스는 애플리케이션 자체): 모든 "일반적인" 바이너리, libs 등에 대해 chroot에서 바인드-로-마운트를 수행합니다.
- /등
- /큰 상자
- /usr
- /lib
- /lib64
- /var
- /home/used_accounts
- /선택/서비스
이제 서비스가 chroot에서 실행되는지 테스트해도 괜찮습니다. 놀랍게도 내 HIDS는 다음의 하위 디렉토리에 쓰기가 있다고 말했습니다./선택/서비스.
그래서 쉘을 사용하여 수동으로 루트를 지정하고 쓰기 액세스를 테스트했습니다. 작동했습니다!
따라서 다른 것이 도움이 되지 않는다면 - RTFM. man mount
읽기 전용 바인드 마운트는 커널 2.6.26 이상에서만 작동한다는 것을 암시했습니다(여기서 불운: CentOS 5는 2.6.18입니다).
또 다른 단점: 이로 인해 잠재적인 공격자가 운영 체제 도구 전체 세트를 갖게 됩니다.