Parę dni temu na jednych z forów, które czasem odwiedzam, pojawił się wątek dotyczący problemu jaki może nieść ze sobą budzenie linux'a ze stanu uśpienia/wstrzymania (Suspend to RAM, STR) za sprawą myszy. O ile w przypadku klawiatury sprawa wybudzania komputera zdaje się być dość oczywista, to w przypadku tego małego gryzonia już niekoniecznie, bo wystarczy lekko mysz przemieścić po blacie stołu czy innego biurka i system się nam wybudzi. Część komputerów ma stosowne opcje w BIOS/UEFI i można za ich sprawą skonfigurować to jakie urządzenia będą mieć możliwość wybudzania systemu. Niekiedy jednak, opcje w BIOS są tak ubogie, że nie mamy możliwości skonfigurowania tego aspektu pracy naszej maszyny. Trzeba zatem w nieco inny sposób podejść do tego zagadnienia. Na necie można się spotkać z radami odnośnie zapisu pliku /proc/acpi/wakeup przez przesłanie do niego czteroznakowych kodów, np. EHC1 czy USB1 . Takie rozwiązanie może nieść ze sobą negatywne konsekwencje i powinno się go unikać. Lepszym rozwiązaniem jest napisanie reguły dla UDEV'a dla konkretnego urządzenia, gdzie będziemy mogli łatwo sterować (przez plik power/wakeup ) tym czy dane urządzenie ma mieć możliwość wybudzania systemu czy też nie.

Jeszcze nie tak dawno temu przeciętnej klasy desktop był wyposażony w pojedynczy i do tego niewielkiej pojemności dysk twardy, który był w stanie pomieścić wszystkie pliki swojego właściciela. Obecnie jednak większość maszyn ma tych nośników już kilka. Mowa tutaj nie tylko o dyskach systemowych, które są fizycznie na stałe zamontowane w komputerze ale również o tych wszystkich urządzeniach, które można podłączyć do portu USB. Polityka linux'a wymusza, by wszystkie nośniki pamięci masowej (HDD, SSD, pendrive czy też karty SD) były montowane w systemie jedynie przez użytkowników posiadających uprawnienia administratora. Domyślnie taki przywilej ma jedynie root. Zatem by uzyskać dostęp do danych na takim zewnętrznym nośniku musimy logować się na root'a. Jakby nie patrzeć ma to swoje plusy patrząc z perspektywy bezpieczeństwa, niemniej jednak czy naprawdę potrzebny nam jest root do wgrania czegoś na nasz ulubiony pendrive? Widać nie tylko ja zadawałem sobie takie pytanie i ktoś postanowił stworzyć narzędzie UDisks (lub jego nowszą wersję UDisks2), które za pomocą mechanizmu PolicyKit (zwanym też PolKit) jest w stanie nadać stosowne uprawnienia konkretnym użytkownikom systemu, przez co można określić zespół akcji, które będą oni w stanie przeprowadzić bez potrzeby podawania hasła, np. montowanie czy odmontowanie zasobu. Postanowiłem zatem zobaczyć jak ten duet sobie radzi na moim Debianie przy tradycyjnym użytkowaniu systemu i ocenić jego stopień przydatności.

Jakiś czas temu natknąłem się na artykuł chwalący Google Play Services i sugerujący zarazem, że nasz smartfon bez tych usług (i appek zależnych od nich) na niewiele się zda człowiekowi. Nie jest to jednak do końca prawdą i postanowiłem pokazać na żywym przykładzie jak wygląda operowanie na telefonie z Androidem pozbawionym jakichkolwiek usług czy aplikacji własnościowych od Google. W rolach głównych wystąpi mój smartfon LG G4C, który jest już dość leciwy ale można na niego wgrać LineageOS (lub też inny ROM na bazie AOSP). Po wgraniu ROM'u, w telefonie znajduje się jedynie garstka podstawowych aplikacji (przeglądarka, galeria, itp), które po pierwsze są opensource, a po drugie można je bez problemu wyłączyć jeśli nie zamierzamy z nich korzystać. Z telefonu można dzwonić, przeglądać net (WiFi/LTE), robić zdjęcia i używać tego urządzenia do różnego rodzaju multimediów. W zasadzie czego oczekiwać więcej od telefonu? Niektórzy jednak chcieli by mieć możliwość używania, np. nawigacji. No i tu już zaczynają się schody, bo na takim w pełni otwartoźródłowym Androidzie, GPS nie zadziała OOTB i potrzebna nam jest jakaś alternatywa w postaci pośrednika między aplikacjami a GPS. Standardowo w Andkach tym zadaniem zajmują się właśnie te usługi Google. Jak więc zatem zmusić GPS do poprawnej pracy nie chcąc przy tym wgrywać sobie tego rozbudowanego w uprawnieniach szpiega od Google? Problemów naturalnie może być więcej, a to czy doświadczymy któregokolwiek z nich zależy głównie od odpowiedniej konfiguracji systemu. Niniejszy artykuł postara się zebrać wszystkie te niezbędne informacje mające na celu zaimplementowanie w naszym smartfonie otwartoźródłowej alternatywy dla Google Play Services w postaci microG.

Czasami pewna niestandardowa konfiguracja naszego linux'a może sprawiać pewne problemy podczas aktualizacji zainstalowanych w nim pakietów. Dla przykładu, wykorzystując mechanizm AppArmor do okrojenia profilów Firefox'a, muszę tworzyć osobne twarde dowiązania do binarki tej przeglądarki. Te dowiązania mają taki problem, że jak usunie się plik, na który wskazywały, np. podczas aktualizacji paczki, to utworzenie pliku w tym samym miejscu przez menadżer pakietów apt/aptitude nie sprawi, że te dowiązania zaczną ponownie funkcjonować poprawnie (tak jak to jest w przypadku dowiązań symbolicznych). Z początku usuwałem te stare dowiązania i tworzyłem nowe ale postanowiłem w końcu poszukać rozwiązania, które by zautomatyzowało cały ten proces i uczyniło go transparentnym dla użytkownika końcowego. Tak natrafiłem na mechanizm Debianowych trigger'ów (deb-trigger), które aktywują się za każdym razem ilekroć pliki w konkretnych ścieżkach są ruszane w jakiś sposób przez menadżer pakietów. W tym artykule spróbujemy sobie zaprojektować taki trigger i obadać czy może on nam się w ogóle do czegoś przydać

Minęło już trochę czasu od momentu, w którym postanowiłem się przerzucić z iptables na nftables w swoim Debianie i w zasadzie większość mechanizmów obronnych mojego laptopowego firewall'a została już z powodzeniem przeportowana na ten nowy filtr pakietów. Poza tymi starymi regułami próbuję czasem ogarniać nieco bardziej wyrafinowane sposoby na unikanie zagrożeń sieciowych, choć implementacja niektórych rzeczy nie zawsze jest taka oczywista, z tym, że niekoniecznie niemożliwa do zrealizowana. Tak było w przypadku mechanizmu automatycznego blokowania hostów próbujących się łączyć z daną maszyną, która sobie najwyraźniej tego nie życzy. Dla przykładu, jest serwer udostępniający usługę SSH na porcie 11111 i tylko ten port jest wystawiony na świat. Wszelkiego rodzaju boty próbujące dostać się do maszyn linux'owych próbkują z kolei głównie standardowe porty, w tym przypadku 22 . Ci użytkownicy, którzy powinni mieć dostęp do usługi SSH, wiedzą na jakim porcie ona nasłuchuje. Można zatem założyć, że wszystkie połączenia na port 22 będą dokonywane przez boty albo przez użytkowników, którzy mają niecne zamiary. Wszystkie te połączenia można by zatem zablokować tworząc mechanizm automatycznego banowania hostów w oparciu o czas ostatniej próby połączenia, tak jak to zostało opisane mniej więcej w tym wątku na forum. Problem w tym, że tamto rozwiązanie dotyczy jedynie iptables w połączeniu z ipset , co nieco komplikuje wdrożenie go w przypadku nftables ale to zadanie jest jak najbardziej możliwe.

Obecnie nftables cierpi dość mocno z powodu pewnych problemów związanych z wydajnością przy aplikowaniu reguł zapory sieciowej. Niemniej jednak, w stosunku do iptables , nftables posiada tablicę netdev , która jest w stanie nieco zyskać w oczach tych nieco bardziej wybrednych użytkowników linux'a. Chodzi generalnie o fakt, że ta tablica jest umieszczona zaraz na początku drogi pakietów, tuż po odebraniu ich z NIC (interfejsu karty sieciowej), a biorąc pod uwagę fakt, że ruch sieciowy, który nigdy ma nie trafić do naszej maszyny, powinien być zrzucany jak najwcześniej (by nie marnować zasobów procesora i pamięci), to ta tablica wydaje się być idealnym miejscem by zablokować cały niepożądany ruch przychodzący. Przy wykorzystaniu iptables , takie pakiety zrzuca się w tablicy raw . Jeśli zaś chodzi o nftables , to zrzucanie pakietów w tablicy netdev jest ponad dwu lub nawet trzykrotnie bardziej wydajne (szybsze i mniej zasobożerne). Można zatem dość dobrze poradzić sobie z wszelkiego rodzaju atakami DOS/DDOS, np. ICMP/PING flood czy SYN flood. Zastanawiające może być natomiast ogarnięcie ataku UDP flood ale przed tym rodzajem ataku linux również jest w stanie się bez problemu ochronić.

W dzisiejszych czasach dystrybucje linux'a wykorzystują mechanizm sudo do wykonywania operacji jako administrator systemu. Zanika więc potrzeba stosowania polecenia su , by zalogować się na konto root i to z jego poziomu wykonywać wszystkie niezbędne rzeczy. Jednym z argumentów zwolenników sudo za takim sanem rzeczy jest możliwość nadania jedynie konkretnym użytkownikom w systemie uprawnień do wykonywania poleceń jako administrator, podczas gdy inni użytkownicy (niebędący w grupie sudo ) nie mogą w ogóle korzystać z tego mechanizmu . No faktycznie, dostęp do su jest w zasadzie dla każdego użytkownika w systemie i tylko hasło konta admina dzieli ich od uzyskania dość szerokich uprawnień. Niewiele jednak osób wie, że można skonfigurować su w taki sposób, by dostęp do niego mieli tylko ci użytkownicy, którzy powinni, np. ci obecni w grupie wheel .

Podczas rutynowego skanu powierzchni dysków HDD w moim laptopie, S.M.A.R.T wykrył w jednym z nich podejrzany blok, który zdawał się wyzionąć już ducha, przez co proces weryfikacji integralności powierzchni dysku twardego nie był w stanie zakończyć się z powodzeniem. Komunikat zwracany przy czytaniu padniętego sektora też był nieco dziwny: bad/missing sense data, sb[] . Jakiś czas temu już opisywałem jak realokować uszkodzony sektor dysku HDD i w zasadzie wszystkie informacje zawarte w tamtym artykule można by wykorzystać do próby poprawienia zaistniałego problemu, gdyby tylko nie fakt, że w tym przypadku badblock znalazł się w obszarze voluminu logicznego LVM na partycji zaszyfrowanej przy pomocy mechanizmu LUKS. Taki schemat układu partycji sprawia, że do realokowania błędnego bloku trzeba podejść nieco inaczej uwzględniając w tym procesie kilka offset'ów, bez których w zasadzie nic nie da się zrobić. Postanowiłem zatem napisać na konkretnym przykładzie jak realokować badsector dysku, gdy do czynienia mamy z zaszyfrowanym linux'em zainstalowanym na voluminach LVM.

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.