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. _______________________________________________ pld-cvs-commit mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit
