PLD-doc/queue/sys-chroot.txt

[qwiat]

Author: qwiat
Date: Sat Feb 11 17:17:56 2006
New Revision: 6967

Added:
   PLD-doc/queue/sys-chroot.txt
Log:
- nowy rozdzial


Added: PLD-doc/queue/sys-chroot.txt
==============================================================================
--- (empty file)
+++ PLD-doc/queue/sys-chroot.txt	Sat Feb 11 17:17:56 2006
@@ -0,0 +1,132 @@
+PLD SYS-CHROOT
+==============
+
+
+Wstęp
+-----
+Jednym z bardziej niezawodnych metod zabezpieczania serwerĂłw jest umieszczanie
+usług sieciowych w autonomicznych środowiskach typu chroot. PodstawowÄ
 ich
+cechÄ
 jest łatwość tworzenia i stosunkowo dobry poziom bezpieczeństwa.
+PLD ułatwia obsługę środowisk chroot dzięki mechanizmowi sys-chroot. W naszych
+przykładach zainstalujemy w "klatce" serwer Apache. 
+
+Mechanizm chroot w niektĂłrych sytuacjach nie oferujÄ
 wystarczajÄ
cego
+poziomu izolacji, a co za tym idzie bezpieczeństwa. Osobom szukajÄ
cym
+bardziej wyrafinowanych rozwiÄ
zań można polecić Linux-VServer
+(http://linux-vserver.org/) którego konfigurację dla PLD opisano w tutaj:
+http://pld-linux.org/Vserver.
+
+
+Bezpieczeństwo
+--------------
+
+W zależności od budowy takiego środowiska możemy je podzielić na
+dwie zasadnicze grupy: klatki pełne i ścisłe. Pierwsze sÄ

+kompletnymi systemami z niewielkimi zmianami dokonanymi po
+instalacji, zaś drugie sÄ
 precyzyjnie przygotowanymi środowiskami,
+ktĂłre składajÄ
 się jedynie z koniecznych do pracy elementów:
+biblioteki, programy itp.
+
+Pierwsze rozwiÄ
zanie jest bardziej elastyczne i wygodne, gdyĹź umoĹźliwia
+łatwÄ
 aktualizację, co niekiedy jest bardzo waĹźnÄ
 cechÄ
. Ścisłe klatki sÄ

+bezpieczniejsze, jednak jakakolwiek aktualizacja jest złożona i sprowadza
+się na dobrÄ
 sprawę do tworzenia od poczÄ
tku całego środowiska.
+
+Mechanizm sys-chroot jest przystosowany do pierwszego z rozwiÄ
zań, wymaga
+kompletu rc-skrytów, powłoki i kilku programów do pracy, dzięki czemu
+otrzymujemy bardzo wygodne narzędzie.
+
+
+Instalacja 
+----------
+Tworzymy katalog dla środowiska:
+# mkdir -p /chr-apache
+Tworzymy bazę pakietów RPM:
+# rpm --root /chr-apache --initdb
+Instalujemy docelowy pakiet:
+# poldek --root=/chr-apache -i apache
+PowyĹźsze polecenie zainstaluje wszystkie wymagane pakiety wymagane przez
+serwer SSH.
+
+
+Konfiguracja
+------------
+
+Musimy jeszcze przygotować system wewnętrzny np. dodać użytkowników:
+chroot /chr-apache useradd -m jkowalski
+chroot /chr-apache passwd jkowalski
+
+Na poczÄ
tek dodajemy ścieżkę naszej klatki do zmiennej SYSTEM_CHROOTS w pliku
+/etc/sysconfig/system , np.:
+SYSTEM_CHROOTS=/chr-apache
+
+Następnie startujemy podsystem klatek
+# service sys-chroot start
+
+Nasz chroot już działa powinien już działać, teraz musimy go
+dodatkowo zabezpieczyć.
+
+
+"Utwardzanie" klatki
+--------------------
+
+W środowisku chroot nie powinny się znaleźć żadne elementy które
+mogły by umożliwić ucieczkę z klatki nawet po uzyskaniu
+praw root-a. 
+
+Bardzo niebezpieczne jest posiadanie kompletu urzÄ
dzeń w katalogu /dev,
+musimy pozostawić jedynie urzÄ
dzenia konieczne do pracy danej uslugi. KaĹźda
+usługa ma inne wymagania pod tym względem, jednak jest kilka najczęściej
+uĹźywanych plikĂłw, oto ich lista:
+/dev/zero
+/dev/null
+/dev/random
+/dev/urandom
+katalogu /dev/pts
+
+Następnie usuwany niebezpieczne narzędzia:
+/bin/mknod
+/usr/sbin/chroot
+
+
+/etc/fstab - plik ten dla chroota może być znacznie ograniczony, w
+większości wypadków konieczne jest tylko podmontowanie /proc. Systemy plików
+powinny być montowane z zewnÄ
trz tak by nie było potrzeby umieszczania /dev
+Ĺźadnych urzÄ
dzeń zwiÄ
zanych z partycjami. Sprawa się komplikuje jeśli mamy
+używać quoty, niestety wtedy musimy umieścić odpowiedni plik w /dev/ i
+dokonać wpisu do /etc/fstab
+
+Musimy jeszcze zadecydować o sposobie zarzÄ
dzania pakietami,
+które zostało opisane dalej.
+
+
+ZarzÄ
dzanie pakietami
+---------------------
+
+Mamy moĹźliwość zarzÄ
dzania pakietami z chroota lub z systemu "gospodarza".
+Pierwsze rozwiÄ
zanie ułatwia przenośność i niezależność klatki, drugie zaś
+zwiększa bezpieczeństwo i wydaje się być bardziej eleganckie.
+
+Pierwsze rozwiÄ
zanie wymaga instalacji poldka w klatce:
+# poldek --root=/chr-apache -i poldek
+od tej pory będziemy następujÄ
co zarzÄ
dzać pakietami:
+# chroot /chr-apache poldek
+
+W drugim wypadku jedynie kopiujemy z głównego systemu plik /etc/sysconfig/rpm.
+Poldka będziemy wywoływać następujÄ
co:
+# poldek --root=/chr-apache
+
+
+Uwagi
+-----
+
+- Bind domyślnie pracuje chroocie w katalogu /var/lib/named, dlatego nie
+musimy sie o niego martwić.
+- syslog moĹźe pracować na zewnÄ
trz, bez problemu będzie zbierał komunikaty z
+usług w klatkach (o ile dana usługa korzysta z syslog-a).
+- cron - musimy zadecydować czy każda klatka ma mieć własnego demona
+zegarowego czy ma pracować jeden wspólny. Jeden demon będzie zużywał mniej
+zasobĂłw, oraz zarzÄ
dzanie nim będzie łatwiejsze, jednak musimy
+zmodyfikować wszystkie wywołania crona z klatek np. dotyczÄ
ce logrotate.
+
+