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ą.

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ń.

Jakiś czas temu postanowiłem przetestować sposób zamknięcia graficznych aplikacji w kontenerze Docker'a. Całe rozwiązanie zostało opisane na przykładzie skonteneryzowania przeglądarki Firefox. Ten opisany w podlinkowanym artykule pomysł był nawet całkiem przyzwoity ale nie nadaje się on, gdy w grę wchodzą programy odtwarzające dźwięk. No może to za dużo powiedziane, że się nie nadaje, ale z pewnością brakuje mu jednego istotnego elementu. Nawet ta przykładowa przeglądarka internetowa jest w stanie odtwarzać dźwięki jeśli się odwiedzi stosowną stronę WWW. Standardowo jednak nic nie usłyszymy w głośnikach, gdy odpalimy dajmy na to stronę YouTube i puścimy jakiś materiał video. Dlatego też wypadałoby skonfigurować dźwięk i przesłać go do serwera PulseAudio, który będzie odpalony na naszym linux'owym hoście. Kiedyś już tego typu rozwiązanie nawet opisywałem na przykładzie zintegrowania PulseAudio z kontenerami LXC. Okazuje się, że tamto rozwiązanie znajduje również zastosowanie w przypadku Docker'a. Trzeba tylko nieco inaczej skonfigurować kontener i właśnie tej kwestii będzie dotyczył niniejszy wpis.

Zgodnie z informacją, która pojawiła się już ponad pół roku temu, dystrybucje linux'a powoli zaczynają odchodzić od iptables . Prawdopodobnie w niedługim czasie iptables zostanie już całkowicie wyparty i zastąpiony przez nftables , przynajmniej jeśli chodzi o desktopy. Nawet Debian zakomunikował, że następne wydanie stabilne tej dystrybucji (Buster) będzie domyślnie wykorzystywało nftables . Wypadałoby zatem się przenieść na ten nowy framework i przygotować sobie kilka podstawowych reguł firewall'a, które zabezpieczoną naszą maszynę przed nieautoryzowanym dostępem z sieci.

Połączenie z internetem, z którego ostatnio przyszło mi korzystać, nie należało zbytnio do tych najbardziej wydajnych pod względem prędkości przesyłu danych. O ile szybkość transferu można by jeszcze przemilczeć, to owe łącze nie należało też do tych najstabilniejszych i czasem kontakt ze światem był zwyczajnie zrywany. Krótko rzecz ujmując, ten net nadawał się chyba jedynie do przeglądania stron WWW. Pech jednak chciał, że potrzebowałem zassać na takim połączeniu repozytorium git'a z patch'ami Debiana nakładanymi na kernel linux'a. To repozytorium nie należy do największych ale też do małych ono się nie zalicza -- waży około 2 GiB. Oczywiście można by zrobić jedynie płytki klon takiego repo za sprawą git clone --depth=1 , co skutkowałoby pobraniem plików w wersji z ostatniego commit'a, co z kolei zredukowałoby w znacznym stopniu wielkość pobieranych danych (parę-paręnaście MiB). Co jednak zrobić w przypadku, gdy musimy sklonować sporych rozmiarów repozytorium git, a dysponujemy przy tym dość wolnym połączeniem sieciowym? Czy jest to w ogóle możliwe, bo przecież git nie ma zaimplementowanej opcji wznawiania przerwanej synchronizacji i każde zakłócenie tego procesu skutkować będzie tym, że całe repozytorium trzeba będzie pobrać jeszcze raz i to bez względu na to, czy proces się zawiesi zaraz na początku, czy też pod koniec operacji.