Sunday, November 30, 2014

Proces nr 1 systemu Linux - systemd

Od ponad 18 lat procesem nr 1 w systemie GNU/Linux jest init, którego obecnie zastąpić ma niejaki systemd. Zmiana tego procesu wywołuje znaczną różnice w korzystaniu z systemu Linux. Zapewne to jest powodem tego, iż wielu użytkowników system Linux znienawidziło go oraz jego autora. W tym tekście postaram się wyjaśnić jaki jest cel wymiany procesu init na systemd oraz co z tego wynika.

Otóż po załadowaniu jądra do pamięci musi zostać uruchomiony jakiś program aby coś robić. W Linuksie pierwszym procesem, który może, a nawet musi uruchomić inne procesy - głównie powłokę - jest init. Gdyby w procesie uruchamiania systemu nie została uruchomiona powłoka poprzez proces login to niemożna byłoby w żaden sposób sterować systemem - chyba, że zostanie uruchomiona usługa SSH. Jak widać pierwszy proces pełni bardzo ważną rolę w systemie i co najważniejsze działa najdłużej w systemie - w sensie czasu, a nie czasu zużycia procesora. Tak więc nie dość, że init jest pierwszym procesem, który zostaje uruchomiony i ostatnim, który jest zamykany to wszystkie pozostałe procesy w systemie są mu podrzędne w hierarchii procesów. Oczywiście nadal można oderwać się poprzez podwójnego forka, ale to już inny temat. Chodzi o to, że proces init będąc rodzicem wszystkich usług system może wykonywać prace, których nie mógłby wykonywać żaden inny proces - jest tylko jeden taki proces - jest nim proces nr 1.

Chodzi o to, że 20 lat temu wymyślono proces init, który był uruchamiany przez jądro, następnie sam odpalał skrypty z lokalizacji /etc/init.d/ i na tym jego praca się "kończyła" - mimo iż działa nadal. Przez wiele lat to wystarczało i nikt nawet nie myślał to zmieniać. Więc dlaczego dziś musimy to zmieniać?

Więc, po pierwsze to wcale nie musimy tego robić, ale obecnie system Linux używany jest do wielu różnych zadań, a jego jądro jest wyposażone w wiele mechanizmów, których wcześniej nie było. Taka kombinacja nowych możliwości i potrzeb zainicjowała poszukiwanie nowych sposobów na usprawnienie systemu. W systemie Linux bardzo często pewne jego części są przepisywane w całości na nowo, to się dzieje cały czas, tylko nie wszystkie te zmiany są widoczne gołym okiem. Z procesem init jest inaczej - dostrzeżono jego potencjał, który może rozwiązać problemy do tej pory nierozwiązane i zdecydowano się to zrobić. Mało tego, wymyślono nowe sposoby wykorzystywania pierwszego procesu i wszystkie te pomysły wcielono do systemd. Wielu uważa, że są to durne pomysły i krytykuje je, ale co ciekawe to tak naprawdę to wszystkie one wcale nie są nowe. Gdyby dokładnie to przeanalizować to okazałoby się że większość z nich doczekała się swojej implementacji w jakiś sposób. Tu różnica polega na tym, że zrobiono to kompleksowo i centralnie. Mało tego, systemd nie jest wcale pierwszy i nie mam tu na myśli Upstart lecz launchd.

Launchd to zamiennik procesu init w systemie Mac OS X, okazał się sukcesem i ktoś po prostu postanowił zrobić to samo w systemie Linux - w wyniku czego został skrytykowany - własnie tak. Jednak krytyka z czasem milknie i największe dystrybucje zaczynają wdrażać nową implementację procesy init - czyli systemd. Launchd nie miał być tylko lepszą wersją pierwszego procesu, lecz całym framework-iem służącym do zarządzania usługami. Tak też zbudowany jest systemd. Systemd to nie jeden demon lecz wiele demonów, dlatego, że koncepcja systemd obejmuje zastąpienie innych demonów takich jak inetd, acpid, udev, syslog, watchdog, cron i atd. Z pomysłu rozbudowania procesu init powstała całą warstwa, która oddzielała jądro od userlandu, i tak należy traktować systemd. Poniższy schemat obrazuje jak wiele elementów system zostało wcielone do tej warstwy.

Architektura systemd - Wikipedia
Systemd to pierwszy krok do podziału demonów na te służące do zarządzania systemem i te oferujące usługi systemowe, takie jak poczta, www itp.. Nawet proces logowania i sesji będzie realizowany w ramach frameworku systemd. Wcześniej pisałem o podwójnym forku, otóż systemd maksymalnie używa mechanizmu cgroups, który uniemożliwia dla uruchamianych procesów ucieczkę od rodzica, a tym samym brak kontroli nad takim procesem. W systemd poszczególne grupy cgroups nazywane są odcinkami (ang. slice) i możemy zobaczyć ich podział chociażby wydając poniższe polecenie.

ps xaf -eo pid,user,args,cgroup

Zabawne, bo podstawową cechą systemd miała być szybkość uruchamiania. Mimo. iż osiągnięto to poprzez mechanizm jednoczesnego uruchamiania usług, to nie ta cecha jest najbardziej widoczną dla użytkowników. Wręcz przeciwnie, jest to jedna z tych zmian, które nie są widoczne gołym okiem. Nie znaczy to, że system wcale nie uruchamia się szybciej dzięki systemd, bo to możemy dokładnie sprawdzić i przeanalizować wydając poniższe polecenie.

systemd-analyze plot> s.svg

Wynikiem jego działania będzie schemat w postaci obrazu, który przedstawia analizę procesu botowania.
Warto tu króciutko wspomnieć ja osiągnięto taki efekt, ale ważniejsze jest w tym to jakie dodatkowe możliwości daje systemd dla usług. Otóż kluczem do uruchamiania wielu usług jednocześnie jest to, że systemd tworzy sockety np. typu AF_INET dla swoich usług, następnie uruchamia te usługi. Jednak już w tym czasie inne usługi (np. B), które również zostały uruchomione ale potrzebują tej pierwszej (np. A) mogą normalnie startować, ponieważ poprzez dostępny socket usługi A myślą, że ta usługa już jest dostępna, podczas gdy tak naprawdę to systemd przetrzymuje w swojej kolejce wszystkie pakiety, które zostały wysłane do tego socketu i przekaże je do jeszcze uruchamianej usługi A, gdy ta zakończy swoje uruchamianie. Efekt będzie taki, że usługa B będzie już gotowa do działania ale brakuje jej jeszcze tylko odpowiedzi od usługi A, czyli ubocznym efektem będzie długi czas oczekiwania, co nie znaczy, że w ostatecznym rozrachunku i tak wszystkie usługi uruchomią się szybciej.
Teraz warto wspomnieć co z tego wynika. Wcześniej jeszcze tylko dodam, że koncepcja centralnego demona zarządzającego socketami to nic innego niż stary inetd. Ale powodem, dla którego komercyjne dystrybucje klasy enterprise wprowadziły systemd jest to, że dzięki takiej centralizacji wykonanej w pierwszym procesie teraz możemy zresetować serwer Apache bez utraty nawiązanych sesji np. https. Mało tego dzięki integracji demona D-Bus z systemd proces, który się zawiesi może automatycznie zostać zrestartowany.

Ciekawą sprawą jest też to, że w systemd nie tylko sockety AF_INET zostały zrównoleglone, ale zrobiono to również z socketami D-Bus (AF_UNIX), a nawet z systemem plików. O systemd można napisać jeszcze bardzo dużo, ale w tym tekście chciałem przekazać ogólną koncepcję, którą realizuje ten projekt.

Więcej informacji:
- Rethinking PID 1
- Wykipedia - systemd
Why systemd?
Here We Go Again, Another Linux Init: Intro to systemd
Understanding and Using Systemd
Intro to Systemd Runlevels and Service Management Commands


Sunday, November 16, 2014

Debian LTS - przedłużone wsparcie dla poprawek bezpieczeństwa

Parę miesięcy temu zakończył się okres wsparcia poprawek bezpieczeństwa dla systemu Debian 6 Squeeze, co wielu użytkowników bardzo martwi, zwłaszcza tych, którzy używają system w firmach i instytucjach. Debian należy do bardzo popularnych dystrybucji wybieranych przez wielu największych graczy w świeci sieciowych usług, np. hostingi.

Niestety świat idzie szybko do przodu i stara polityka systemu Debian zaczyna niektórych irytować. Mniej więcej rok temu oraz mniej więcej rok przed zakończeniem wsparcia łatek bezpieczeństwa dla Debian Squeeze (czyli w czasie wydania nowej wersji stabilnej Debian 7 Wheezy) jeden z większych hostingów [1] oświadczył, iż zamierza porzucić Debiana przez krótki okres wsparcia łatek bezpieczeństwa. Wieść ta wywołała długą dyskusję wśród developerów Debiana [2], której wynikiem było wprowadzenie inicjatywy dłuższego wsparcia zwanej Debian LTS (Long Term Support) [3].

Z jednej strony to dobra wiadomość ale z drugiej Ubuntu oraz CentOS od dawna posiadają wersje LTS swoich dystrybucji. Jednak między Debianem a wymienionymi dystrybucjami istnieje zasadnicza różnica. Debian jest w pełni projektem społecznościowym, natomiast ze Ubuntu LTS stoi Canonical, a CentOS pobiera łatki z FTP RedHat. Jak widać posiadanie wersji LTS to wspólna cecha dystrybucji oferowanych w modelu enterprise, czyli dla biznesu.

Mimo to deweloperzy Debiana podjęli wyzwanie i od paru miesięcy możemy dodać nowe repozytoria dla wersji 6 (oldstable), aby pobierać nadal łatki bezpieczeństwa po oficjalnym wsparciu:

deb http://http.debian.net/debian/ squeeze-lts main contrib non-free 
deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

Projekt LTS rozszerza standardowe wsparcie oferowane przez zespół deweloperów Debiana o dwa lata. Oznacza to, że dzięki tej inicjatywie Debian będzie oferował w sumie 5-cio letnie wsparcie dla łatek bezpieczeństwa. Harmonogram dostępny jest na poniższej stronie [4].

Na tym można by zakończyć i cieszyć się z nowości jaką jest wsparcie LTS w Debianie, ale projekt ten dopiero raczkuje i daleko mu do swoich konkurentów. Otóż na jego realizacje potrzebne są pieniądze, bo jak stwierdzili deweloperzy nie ma co się okłamywać, że w naszym ekonomicznym świecie każdy musi z czegoś żyć. Na dzień dzisiejszy projekt LTS ma kilku sponsorów, których dotacje wystarczają zaledwie na ok 25% potrzeb. Co to oznacza, a no to, że na niektóre łatki bezpieczeństwa w tej chwili trzeba trochę poczekać, ponieważ jest więcej pracy niż pieniędzy (błędy, które nie zostały jeszcze poprawione [5]).

Powstaje więc pytanie, czy Projekt Debiana LTS poradzi sobie ze wyzwaniem, zanim inni zaczną przechodzić na Ubuntu LTS tak jak DreamHost? Czy w czasach, w których system GNU/Linux coraz bardziej asymiluje się ze światem biznesu całkowicie społeczna dystrybucja pozbawiona komercyjnego wsparcia nadąży za konkurencją? Czas pokaże.

[1] http://www.dreamhost.com/dreamscape/2013/06/03/change-is-in-the-air-dreamhost-upgrades/
[2] https://lists.debian.org/debian-devel/2013/08/msg00346.html
[3] https://wiki.debian.org/LTS
[4] http://www.freexian.com/services/debian-lts.html
[5] http://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?revision=HEAD&view=co

Thursday, November 13, 2014

SELinux - rozwalające porady

To nic nowego, że w internecie najwięcej porad o SELinux dotyczy jego wyłączenia. Również prezentacje typu ~"Przestańcie wyłączać SELinux" itp. były na porządku dziennym. Red Hat próbuje walczyć z tym, a sposób po jaki już sięgnął nie powstrzymał mnie od napisania tego wpisu - bo już nie wytrzymam :] Zanim zaprezentuje perełki tego tematu słowo wstępu.

Zapewne spotkaliście się z 'wyznawcami' najsłuszniejszego systemu jakim jest GNU/Linux, jaki to on jest bezpieczny itp. oraz z ich przeciwnikami, którzy często podają przykłady typu "gdyby był taki bezpieczny to nie włamali byś się do ..." itp.

Teraz przedstawię genezę jak dochodzi do włamań w najbezpieczniejszym systemie świata :)

Zapewne słyszeliście o tym, że w GNU/Linux konkretną rzecz można zrobić na wiele sposobów (w końcu o co Linuksiarze kłóciliby się ze sobą!). Oto 4 efektywne sposoby na wyłączenie SELinux.


Nikt teraz nie powie, że Linuksa nie można przystosować do swoich potrzeb. Do każdego gustu znajdzie się metoda na to :)

Wracając do tematu, znacie taką firmę IBM, tak, tak, to ta co promuje Linuksa i rozwiązania otwarte. Oferują również świetną dokumentację do swoich produktów, np. jak zainstalować na wirtualnej maszynie RHEL.


Oczywiście instalacja nie mogłaby się powieść bez ptk. 8


Tak zainstalowany system można z powodzeniem zaoferować klientom :)

Skoro jesteśmy przy temacie RHEL, słyszeliście o takim oprogramowaniu cPanel do zarządzania hostingiem - działa głównie na RHEL. Otóż oni też wiedzą jak dobrze postawić swój produkt na 'relku' - najbardziej podoba mi się tytuł podręcznika instalacyjnego - "Installation Guide - Disable SELinux".


Warto zwrócić uwagę na pogrubione stwierdzenie, że do instalacji niezbędne jest wyłączenie SELinux. Nie ma co się dziwić, przecież nie napiszą do swojego produktu (najlepszy ponoć) polityki, nie!

Dan Walsh chyba się załamał bo sięgnął już po metodę jaką jest kolorowanka dla "dzieci" :) Proszę Państwa przedstawiam SELINUX COLORING BOOK.


Książka powstała aby pomóc zrozumieć jak działa SELinux.

Wyjaśniono w niej, iż są procesy różnego typu (kotek i piesek).

Oraz, iż istnieją obiekty różnego typu (jedzenie dla kotka i pieska).


W końcu, wyjaśniono na czym polega mechanizm wymuszanie typów (piesek nie może jeść karmy dla kotka, system go powstrzyma).


Piesek może jeść tylko jedzenie przeznaczone dla niego.
I tak sprawy się mają z bezpieczeństwem w GNU/Linux - miłego kolorowania.

Saturday, November 8, 2014

Debian Squeeze bug 668174 with SELinux - workaround for this problem

Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668174

I use Debian Squeeze on server and want set permissive mode from some domain.
In newer version policycoreutils this bug is repaired, but in Debian Squeeze max version is 2.0.82-3.

So I change code in two place:


1. Problem with '/var/lib/selinux'

semanage permissive -a smbd_t
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 460, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 363, in process_args
    OBJECT.add(target)
  File "/usr/lib/pymodules/python2.6/seobject.py", line 275, in add
    os.chdir(dirname)
OSError: [Errno 2] No such file or directory: '/var/lib/selinux'


Change:

head -n 280 /usr/lib/pymodules/python2.6/seobject.py|tail -n 10
    def add(self, type):
               import glob
               name = "permissive_%s" % type
               #dirname = "/var/lib/selinux"
               dirname = "/usr/share/selinux"
               os.chdir(dirname)
               filename = "%s.te" % name
               modtxt = """
module %s 1.0;



2. Problem with '/usr/share/selinux/devel/'

semanage permissive -a smbd_t
Traceback (most recent call last):
  File "/usr/sbin/semanage", line 460, in <module>
    process_args(sys.argv[1:])
  File "/usr/sbin/semanage", line 363, in process_args
    OBJECT.add(target)
  File "/usr/lib/pymodules/python2.6/seobject.py", line 291, in add
    mc.create_module_package(filename, 1)
  File "/usr/lib/pymodules/python2.6/sepolgen/module.py", line 172, in create_module_package
    self.refpol_build(sourcename)
  File "/usr/lib/pymodules/python2.6/sepolgen/module.py", line 186, in refpol_build
    raise RuntimeError("compilation failed:\n%s" % self.last_output)
RuntimeError: compilation failed:
make: /usr/share/selinux/devel/Makefile: Nie ma takiego pliku ani katalogu
make: *** Brak reguł do wykonania obiektu `/usr/share/selinux/devel/Makefile'. Stop.


Change:

 head -n 128 /usr/lib/pymodules/python2.6/sepolgen/module.py |tail -n 10
        self.checkmodule = "/usr/bin/checkmodule"
        self.semodule_package = "/usr/bin/semodule_package"
        self.output = output
        self.last_output = ""
        #self.refpol_makefile = "/usr/share/selinux/devel/Makefile"
        self.refpol_makefile = "/usr/share/selinux/default/include/Makefile"
        self.make = "/usr/bin/make"

    def o(self, str):
        if self.output:



This is works for me :)