PLD-doc/queue/sys-chroot.txt

qwiat cvs w pld-linux.org
Wto, 14 Lut 2006, 00:48:19 CET 

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.

Więcej informacji o li¶cie dyskusyjnej pld-doc