Pisząc jakiś czas temu poradnik na temat budowania paczek .deb dla dystrybucji linux'a Debian, poruszyłem w nim kwestię związaną z aktualizacją paczki, która zawierała projekt utrzymywany w systemie kontroli wersji (CVS), np. git. Rozchodzi się tutaj o format źródeł. Do niedawna myślałem, że są w zasadzie dwa formaty (tych, z których się zwykle korzysta): 3.0 (native) oraz 3.0 (quilt) . Wszystkie moje pakiety budowane do tej pory miały ten drugi format. Podglądając ostatnio kilka paczek .deb , natrafiłem w jednej z nich na format źródeł 3.0 (git) . Okazuje się, że ten format jest w stanie bardzo łatwo ogarnąć projekty hostowane w takich serwisach jak GitHub, czy GitLab i można za jego sprawą nieco ułatwić sobie życie. Wypadałoby zatem rzucić na niego okiem i ocenić go pod kątem przydatności przy budowaniu pakietów dla Debiana.

Po wyjaśnieniu paru rzeczy w kwestii przestrzeni wymiany, a konkretnie [co jest lepsze: plik SWAP czy osobna partycja]({{ site.baseurl }}/post/czy-w-linux-plik-swap-jest-lepszy-niz-partycja-wymiany/), postanowiłem nieco zmienić układ partycji na dysku mojego laptopa (LUKS+LVM) i zaimplementować sobie przestrzeń wymiany w postaci pliku SWAP. Standardowo jednak plik SWAP nie działa w przypadku hibernacji linux'a i kernel ma problemy z wybudzeniem maszyny z głębokiego snu. Jeśli zamierzamy korzystać z hibernacji, to trzeba inaczej skonfigurować system, by nauczyć go korzystać z przestrzeni wymiany w postaci pliku. W tym artykule rzucimy sobie okiem na ten niezbyt skomplikowany proces.

Użytkownicy linux'a są zwykle chronieni przez mechanizmy bezpieczeństwa, które ten system jest w stanie zaoferować. Oczywiście deweloperzy różnych dystrybucji, np. Debiana, dokładają wszelkich możliwych starań, by system jako całość był wstępnie skonfigurowany tak, by końcowy użytkownik nie musiał za wiele majstrować przy zabezpieczeniach i mógł się czuć i być (przynajmniej względnie) bezpieczny. No i faktycznie złowrogie oprogramowanie ma czasem spore problemy dostać się do maszyny, którą operuje linux. Niemniej jednak, gdy już taki syf się do systemu dostanie, to zwykle niewiele dzieli go od przejęcia kontroli nad komputerem. Może i część zabezpieczeń linux'a zadziała i sprawi, że taki wirus/trojan czy nawet zwykły skrypt będzie miał ograniczone pole manewru, to i tak będzie on mógł przeprowadzić te akcje, które zwyczajny użytkownik systemu (nie root) jest zwykle w stanie poczynić, np. odebrać dźwięk i video ze stosownych urządzeń i przesłać te dane przez sieć. My z kolei możemy nawet tego faktu nie być świadomi. Jasne, że powinno się zwracać uwagę na to jakie pliki się pobiera z internetu i nie uruchamiać wszystkiego lekkomyślnie ale też trzeba mieć na uwadze fakt, że często jedna maszyna jest współdzielona, np. z członkami rodziny i oni już niekoniecznie muszą władać zaawansowaną wiedza z zakresu IT, by przewidzieć wszystkie możliwe zagrożenia czyhające na nich w sieci. Można za to postarać się, by uczynić naszą maszynę nieco bardziej odporną na niezbyt przemyślane zachowania użytkowników jej systemu operacyjnego. Jednym z kroków, które możemy podjąć, jest wdrożenie mechanizmu Trusted Path Execution (TPE), który póki co jest dostępny jedynie w formie patch'a na kernel linux'a lub też jako jego osobny moduł oferujący sporo więcej możliwości w stosunku do wspomnianej wcześniej łaty. W niniejszym artykule rzucimy sobie okiem na ten cały mechanizm TPE i zobaczymy jak jest on w stanie uchronić nasz OS przed niezbyt zaawansowaną ludzką inteligencją.

Ostatnimi czasy, z racji rozwoju technologicznego, mamy do dyspozycji coraz to szybsze komputery, co przekłada się w znacznym stopniu na prędkość wykonywania operacji przez ich systemy operacyjne. Obecnie przeciętnej klasy desktop czy laptop jest już wyposażony w 16G czy nawet 32G pamięci operacyjnej (w niedługim czasie nawet smartfony będą posiadać 12G RAM). Spada zatem zapotrzebowanie wykorzystania dysku twardego jako pamięci RAM. W linux używanie dysku twardego jako rozszerzenie pamięci operacyjnej było i jest w dalszym ciągu realizowane za sprawą przestrzeni wymiany SWAP. Ta przestrzeń wymiany może być zaimplementowana w postaci osobnej partycji dysku twardego albo też jako plik umieszczony w obrębie systemu plików, np. ext4. Część dystrybucji linux'a decyduję się na porzucenie partycji wymiany na rzecz pliku SWAP. Czy taki krok jest uzasadniony i czy korzystając aktualnie z partycji wymiany powinniśmy zmigrować na plik SWAP?

Przeglądając dzisiaj rano logi systemowe wpadł mi w oczy komunikat, którego treść brzmiała mniej więcej tak: e2scrub Volume group "wd_blue_label" has insufficient free space (0 extents): 64 required , po którym z kolei można zanotować e2scrub snapshot FAILED, will not check! oraz Failed to start Online ext4 Metadata Check for /media/Debian . Oczywiście ten punkt montowania to nazwa partycji odnosząca się do jednego z dysków logicznych struktury LVM. Skąd się te błędy wzięły? Przecież jeszcze do niedawna (przez ostatnich parę lat) wszystko z moim linux'em rezydującym na dysku (LUKS+LVM) było w porządku, a teraz nagle takie bardzo niepokojące błędy. Czym jest w ogóle ten e2scrub i czym jest ten cały Online ext4 Metadata Check , który najwyraźniej ma coś wspólnego ze sprawdzaniem systemu plików voluminów logicznych w locie? No i najważniejsze chyba pytanie -- czemu to nie działa jak należy?

Kernel linux'a jest dość złożonym organizmem, który może zostać rozbudowany przy pomocy dodatkowego kodu ładowanego w postaci zewnętrznych modułów. Czasem ze względu na wczesny etap prac nad nową funkcjonalnością jądra, taki moduł może zachowywać się dość nieprzewidywalnie, co przekreśla jego szanse na pojawienie się w stabilnych wydaniach kernela. Czasem też z jakiegoś niezrozumiałego powodu pewne rzeczy nie są celowo dodawane do jądra operacyjnego. Jedną z nich jest moduł Trusted Path Execution (TPE), który jest w stanie znacznie poprawić bezpieczeństwo systemu uniemożliwiając przeprowadzenie w nim szeregu podejrzanych działań. W Debianie tego typu niedogodności związane z brakiem pewnych modułów można obejść przez zastosowanie mechanizmu DKMS, który przy instalacji modułu spoza głównego drzewa kernela linux'a jest nam go w stanie automatycznie zbudować. W repozytorium dystrybucji Debiana znajduje się już szereg pakietów z modułami (mają końcówki -dkms ) i w prosty sposób można je sobie doinstalować. Co jednak w przypadku, gdy mamy moduł, którego nikt jeszcze nie przygotował i nie wrzucił do repozytorium? Co, gdy takich modułów mamy kilka, a przy tym korzystamy z najnowszego stabilnego kernela, który jest aktualizowany średnio co kilka dni? Ręczna budowa wszystkich zewnętrznych modułów za każdym razem jak tylko wyjdzie nowsza wersja kernela, to nie najlepsze wyjście, zwłaszcza jak dojdzie nam do tego aktualizacja samych modułów. Można za to zrobić sobie paczkę .deb tak, by przy instalacji nowego jądra operacyjnego, system nam automatycznie zbudował wszystkie dodatkowe moduły, których nasz komputer wymaga do poprawnej pracy.

Od czasu do czasu w logu systemowym mojego Debiana można zanotować szereg pakietów przychodzących, które są zrzucane przez linux'owy firewall (nftables/iptables ). Po krótkiej analizie okazało się, że są to pakiety protokołu TCP mające stan NEW (czyli są to nowe połączenia) ale niezawierające przy tym flagi SYN . Mój laptop nie ma aktualnie przydzielonego zewnętrznego routowalnego adresu IPv4/IPv6, więc nasunęło się pytanie o przyczynę takiego stanu rzeczy -- przecie będąc za NAT, nikt spoza sieci nie powinien być w stanie nawiązać połączenia z moją maszyną, a ewidentnie co się do jej bram dobija i to nie z adresu lokalnego. Niby mam też odfiltrowane pakiety w stanie INVALID (np. te mające niepoprawny zestaw flag) ale widać te pakiety, o których mowa, nie zaliczają się do tego stanu, więc wygląda na to, że wszystko z nimi jest w porządku. Czy tego typu pakiety TCP w stanie NEW niemające ustawionej flagi SYN stanowią jakieś zagrożenie dla naszego komputera? Czy powinno się je zablokować, a może przepuścić w filtrze pakietów? A jeśli zablokować, to czy zwykły DROP wystarczy czy może powinno się te pakiety potraktować przy pomocy REJECT ?

Ostatnio przeglądając nowe wpisy na forach trafiłem na pytanie o podział dysku pod instalację linux'a. Autorowi wątku chodziło o jak najlepszy podział dysku HDD ale najwyraźniej pogubił się on w tym całym bałaganie informacyjnym, który tyczy się procesu partycjonowania nośnika pod kątem jego optymalnego wykorzystania przez linux. Zagadnienie podziału dysków HDD/SSD nie jest zbytnio jakoś skomplikowane, a mimo to wciąż pojawiają się pytania o poprawne przeprowadzenie tego procesu i to pomimo faktu, że mamy obecnie już dość sporych rozmiarów dyski. To pytanie powoli przestaje mieć jakikolwiek sens, przynajmniej jeśli chodzi o przeciętnego Kowalskiego instalującego linux'a u siebie na kompie (desktop/laptop). Postanowiłem jednak napisać parę słów na temat tego całego podziału dysku na partycje, tak by dobrać optymalny ich rozmiar przy instalowaniu dowolnej dystrybucji linux'a.

Użytkownicy Debiana często w roli firewall'a wykorzystują już dość leciwy iptables . W zasadzie, to tej implementacji linux'owego filtra pakietów sieciowych nic nie dolega, no może poza szeregiem wad konstrukcyjnych, które są obecnie tak ciężkie do zaadresowania, że w sumie trzeba by cały ten iptables napisać od początku. Wszystko przez rozwój internetu, za sprawą którego pojawiło się zapotrzebowanie na tworzenie całej masy reguł (w postaci adresów/portów źródłowych/docelowych), gdzie w standardowym iptables trzeba tworzyć osobne wpisy. Im więcej reguł w filtrze, tym przechodzenie pakietów przez zaporę sieciową trwa dłużej i wiąże się z mocnym obciążeniem dla procesora (zwłaszcza, gdy tych reguł jest kilkadziesiąt tysięcy). By jakoś uporać się z tymi problemami (nieznanymi w innych filtrach sieciowych) stworzono ipset . I faktycznie odciążył on mocno procesor maszyny ale i tak nie wyeliminował on podstawowych wad iptables . Dlatego też zaczęto szukać innego rozwiązania i tak pojawiła się alternatywa m.in. w postaci nftables . W przyszłym stabilnym Debianie (buster) nftables będzie wykorzystywany jako domyślny filtr pakietów i ci, który korzystali z ipset mogą się nieco zdziwić, że nftables nie posiada dla niego wsparcia. Rzecz w tym, że nftables potrafi natywnie obsługiwać listy adresów/portów i ipset nie jest mu w tym do niczego potrzebny.

Ostatnio na Niebezpieczniku pojawił się artykuł na temat niezbyt przyjaznych urządzeń podłączanych do komputera za sprawą portów USB (opisanych na przykładzie niepozornego przewodu) i tego jaką szkodę tego typu hardware może nam wyrządzić w systemie. Ataki z wykorzystaniem podstawionych urządzeń zadziałają nawet na linux, choć pewnie cała masa użytkowników wyznaje jeszcze mit, że ich komputer jest bezpieczny, bo przecie używają alternatywnego systemu operacyjnego, który jest OpenSource i za priorytet obrał sobie szeroko rozumiane bezpieczeństwo. Niestety nie jest tak różowo jakby mogło się co niektórym wydawać ale można ten stan rzeczy naturalnie zmienić i nie trzeba przy tym rekompilować kernela z zamiarem wyłączenia obsługi modułu USB, co ten opisany w podlinkowanym artykule atak oczywiście by również powstrzymało. Zamiast tego możemy zainstalować sobie narzędzie usbguard i przy jego pomocy skonfigurować politykę podłączanych do portów USB urządzeń.