ich habe mich in der letzten woche sehr intensiv mit dem thema chroot
auseinandergesetzt. wie das ja auch zum beispiel an meinen links zu sehen ist.
leider ist das ganze nicht mehr in die neuen produkte eingeflossen, aber
grundsätzlich ist mein informationsstand auf diesem gebiet jetzt um einiges
besser. darum hier eine kleine anleitung wie man schnell und ohne grosses
selbstkompilieren eine chroot auf debian systemen aufbau kann. also erstes
ist das paket libpam-chroot zu installieren (( also das ist jetzt nur für
debianpakete vorhanden, genau kann ich nicht sagen ob es das auch auf anderen
systemen zu finden ist, bei ubuntu ist es jedenfalls vorhanden )). dann sind
wie in dieser [anleitung](http://www.debian.org/doc/manuals/securing-debian-
howto/ap-chroot-ssh-env.de.html) die dateien /etc/pam.d/ssh und
/etc/security/chroot.conf zu ändern. also in der /etc/pam.d/ssh ist diese
zeile einzufügen session required pam_chroot.so grundsätzlich muss jetzt in
die /etc/security/chroot.conf nur noch der user mit seinem homeverzeichniss
eingetragen werden der in seinem homeverzeichnis gefangen sein soll und gut
ist. es gibt aber noch einige andere vorraussetzungen da in einer chroot
umgebung ja alle vorhandenen befehle auch exitieren müssen. [hier](http://de
.gentoo-wiki.com/SSH_Login_ins_Chroot) gibt es ein nettes script was einem
dabei hilft alle benötigten libraries zu kopieren. grundsätzlich ist jetzt zu
überlegen das ganze nicht zu kopieren sondern mittels ln einen link anzulegen,
aber das ist grundsätzlich eine sache des platten platzes und der update
politik. den wenn man alle benötigten dateien kopiert müssen nach einem update
auch alle chroot umgebungen geupdatet werden. aber wenn man ein wenig in der
trickkiste wühlt und seinem benutzer auch nur einige wenige befehle mit auf
den weg geben. ich habe dazu auf die eierlegende wollmilchsau
busybox zurückgegriffen. für mich hatte das den vorteil
das ich ein statisches binary benutzen konnte, am ende nur ca. 800kb pro user
belegt waren und in dem selbstkompilat nur wenige befehle aktiviert waren. das
selbstkompilat ((bei interesse finde sich
hier meine config, einfach
nach .config umbenennen und mittels make oldconfig verwenden)) habe ich
gewählt, da die von debian unter sarge gelieferte version ziemlich alt war und
vor allem aber auch zuviel konnte. dem user habe ich als shell /bin/ash
verpasst und die busybox ist dann eingesprungen nachdem sie nach /bin/ in der
chroot kopiert wurde. mittels hardlinks habe ich die einkompilierten befehle
verfügbar gemacht und für den user sah es auf den ersten blick aus wie ein
wirklich sehr schlankes kleines problem. das wichtige ist, das noch einiges
devices unter /dev/ in der chroot eingerichtet werden müssen. bei mir waren es
dann mknod dev/null c 1 3 mknod dev/zero c 1 5 mknod -m 644 dev/tty1 c 4 1 mknod -m 644 dev/tty2 c 4 2 mknod -m 644 dev/tty3 c 4 3 mknod -m 644 dev/tty4 c 4 4 mknod -m 644 dev/tty5 c 4 5 mknod -m 644 dev/tty6 c 4 6 mknod -m 644 dev/ptmx c 5 2 mknod dev/pts/0 c 136 0 mknod dev/pts/1 c 136 1 also wie
gesagt das verwenden der busybox hat den vorteil das es keine shared libraries
gibt, keinerlei probleme bei updates ((oder nur wirklich sehr sehr wenige und
klar einschränkbar)) und der benutzer einen shell zugriff hat der auf das
nötigste beschränkt ist. so kann grundsätzlich jemand vom einfach mal so
rumspielen abgehalten werden (meiner ansicht nach). für das ausbrechen und das
manipulieren ist also mehr kriminelle energie nötig, als wenn das system als
normaler user benutzt werden kann. das benutzen der busybox hat nur einen
nachteil. grundsätzlich funktioniert zwar der shell zugriff, aber scp oder
sftp sind nicht möglich, wenn jemand einen reinen sftp bzw scp zugang haben
will, kann ich nur rssh empfehlen, eine
shell die nur zum sicheren daten übertragen gemacht wurde, jedoch keinerlei
login möglichkeiten bietet. bei der busybox müssen diese funktionalitäten erst
eingepatched werden genau wie einige andere dinge die ich als wichtig ansehe.
sicherlich können hier auch statisch verlinke binaries genommen werden aber
warum nicht alles in der shell belassen... ... da aber meine bemühungen das
ganze in ein produktiv einzubringen gekippt worden sind, behandeln wir das
einpatchen vielleicht einfach mal später, wenn das ganze dann doch noch einmal
produktiv online gehen sollte ...
{% include JB/setup %}