PLD-doc/queue/sys-chroot.txt

Tue Feb 14 00:48:19 CET 2006

Author: qwiat
Date: Tue Feb 14 00:48:15 2006
New Revision: 6971

Modified:
   PLD-doc/queue/sys-chroot.txt
Log:
- poprawienie kodowania z UTF na ISO
- poprawki merytoryczne
- wiele poprawek stylistycznych


Modified: PLD-doc/queue/sys-chroot.txt
==============================================================================

--- PLD-doc/queue/sys-chroot.txt	(original)
+++ PLD-doc/queue/sys-chroot.txt	Tue Feb 14 00:48:15 2006
@@ -2,131 +2,131 @@
 ==============
 
 
-WstÄ™p
+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:
+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
+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Ä

+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:
+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.
+Pierwsze rozwiązanie jest bardziej elastyczne i wygodne, gdyż umożliwia
+łatwą i szybką 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 w PLD jest przystosowany do pierwszego z rozwiązań,
+wymaga kompletu rc-skrytów, powłoki i kilku programów do pracy. W ten
+sposób uzyskamy wygodne narzędzie, które będzie bardzo podobne w
+zarządzaniu do głównego systemu.
 
 
 Instalacja 
 ----------
-Tworzymy katalog dla Ĺ›rodowiska:
+Tworzymy katalog dla środowiska:
 # mkdir -p /chr-apache
-Tworzymy bazÄ™ pakietĂłw RPM:
+Tworzymy bazę pakietów RPM:
 # rpm --root /chr-apache --initdb
+
+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
+W drugim wypadku jedynie kopiujemy z głównego systemu plik /etc/sysconfig/rpm.
+do /chr-apache/etc/sysconfig/rpm.
+
 Instalujemy docelowy pakiet:
 # poldek --root=/chr-apache -i apache
-PowyĹźsze polecenie zainstaluje wszystkie wymagane pakiety wymagane przez
-serwer SSH.
+Powyższe polecenie zainstaluje wszystkie wymagane pakiety wymagane przez
+serwer Apache.
 
 
 Konfiguracja
 ------------
-
-Musimy jeszcze przygotowaÄ‡ system wewnÄ™trzny np. dodaÄ‡ uĹźytkownikĂłw:
+W zależności od zastosowania systemu musimy 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
+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
+Następnie startujemy podsystem klatek
 # service sys-chroot start
 
-Nasz chroot juĹź dziaĹ‚a powinien juĹź dziaĹ‚aÄ‡, teraz musimy go
-dodatkowo zabezpieczyÄ‡.
+Nasz chroot powinien już działać, teraz musimy go
+dodatkowo zabezpieczyć.
 
 
-"Utwardzanie" klatki
+Zabezpieczanie klatki
 --------------------
-
-W Ĺ›rodowisku chroot nie powinny siÄ™ znaleĹşÄ‡ Ĺźadne elementy ktĂłre
-mogĹ‚y by umoĹźliwiÄ‡ ucieczkÄ™ z klatki nawet po uzyskaniu
+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:
+Bardzo niebezpieczne jest posiadanie kompletu urządzeń w katalogu /dev,
+musimy pozostawić jedynie urządzenia konieczne do pracy danej usługi. 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:
+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
 
-/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.
+Musimy jeszcze zadecydować o sposobie zarządzania pakietami,
+które zostało opisane dalej.
 
 
-ZarzÄ
dzanie pakietami
+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:
+Oprogramowanie w klatce należy od czasu do czasu aktualizować, jeśli
+zdecydowaliśmy się na zewnętrzne zarządzanie pakietami użyjemy
+następującego wywołania Poldka:
 # poldek --root=/chr-apache
+w przeciwnym wypadku będziemy wywoływać następująco:
+# chroot /chr-apache poldek
 
 
 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.
+- 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, ponadto zarządzanie nim będzie łatwiejsze, musimy jednak
+zmodyfikować wszystkie wywołania crona z klatek np. dotyczące logrotate.
 
 
