Z okazji wypuszczenia parę dni temu nowego Debiana, przeglądałem sobie notki dla wydania stabilnego pod kątem aktualizacji z buster (10) -> bullseye (11). Niby ja i tak korzystam cały czas z unstable/experimental i zwykle jestem na bieżąco ze zmianami wprowadzanymi w tej dystrybucji linux'a ale też zawsze coś może umknąć uwadze z perspektywy wielu miesięcy czy nawet kilku lat (a dokładnie 25 miesięcy). Sporo z tych rzeczy, które w tych podlinkowanych notatkach wyczytałem, miałem już załatwione wcześniej ale zapomniałem rozprawić się z repozytoriami APT. Konkretnie chodzi tutaj o odejście od apt-key , czyli narzędzia, które w Debianie używane jest do dodawania kluczy GPG do systemowego keyring'a APT. Te klucze zwykle wykorzystywane są do weryfikacji sygnatur złożonych pod zewnętrznymi repozytoriami, a że ja mam ich sporo, to musiałem się nieco zagłębić w temat i ustalić w jaki sposób od następnego wydania Debiana (bookworm/12) będzie się te klucze GPG od takich repozytoriów ogarniać. No i właśnie o tym będzie ten poniższy kawałek artykułu.

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ć

Posiadanie aktualnego systemu za sprawą regularnych aktualizacji może znacząco przyczynić się do poprawy bezpieczeństwa naszego linux'a. Niemniej jednak, niezabezpieczony proces aktualizacji może zdradzić pewne informacje, które mogą się okazać przydatne dla potencjalnego atakującego. Dlatego też menadżer pakietów apt/aptitude w Debianie wyposażony jest w dodatkowe transporty umożliwiające komunikację z serwerem repozytorium w oparciu o różne protokoły. Standardowy protokół, którym posługują się maszyny mające na pokładzie dystrybucję Debian, to HTTP (ewentualnie FTP). Oba z nich ślą wszelkie informacje w postaci czystego tekstu, który nadaje się do analizy przez człowieka. Możemy jednak skorzystać z protokołu SSL/TLS i zaszyfrować proces pobierania aktualizacji za sprawą pakietu apt-transport-https .

Debian to dość stara i rozbudowana dystrybucja linux'a, którą można spotkać praktycznie w każdym zakątku naszego globu. Dziesiątki tysięcy pakietów dostępne w oficjalnych repozytoriach tylko czekają aż je pobierzemy i zainstalujemy w swoim systemie. Problem zaczyna się jednak w momencie, gdy wielu użytkowników w tym samym czasie zaczyna pobierać pakiety i to z tego samego serwera. Wtedy aktualizacja Debiana może trwać dłużej niż zazwyczaj. By zaadresować ten problem, developerzy tej dystrybucji stawiają serwery lustrzane (mirror) w różnych częściach świata i rozładowują w ten sposób ruch, który by powędrował do głównego serwera. Spora część krajów ma kilka własnych mirror'ów ale ich jakość może czasami zostawić wiele do życzenia. Co w przypadku, gdy taki mirror, z którego my korzystamy, ulegnie awarii? Trzeba będzie poddać edycji plik /etc/apt/sources.list i zmienić adres repozytorium przez dostosowanie w nim części odpowiedzialnej za lokalizację, np. ftp.pl czy ftp.us . Istnieje jednak sposób, który dostosuje lokalizację serwera lustrzanego automatycznie, a my już nie będziemy musieli sobie głowy zawracać edycją wspomnianego wyżej pliku.

Projekt, o którym traktuje poniższy wpis, nie jest już rozwijany przez Debiana. Więcej info tutaj.

Dystrybucja linux'a Debian oferuje możliwość pobierania pakietów .deb za pomocą sieci TOR. W ten sposób jesteśmy w stanie ukryć nieco informacji na temat zainstalowanego w naszym systemie oprogramowania. Jakby nie patrzeć, aplikacje mają pełno dziur i nie wszystkie z tych programików są łatane natychmiast po opublikowaniu podatności. Z chwilą dokonywania aktualizacji systemu, potencjalny atakujący może dowiedzieć się zatem z jakich programów korzystamy, wliczając w to ich wersje. Znając te dane, można ocenić czy system posiada jakieś błędy. By zaimplementować w menadżerze pakietów apt/aptitude możliwość korzystania z sieci TOR, musimy posiadać w systemie skonfigurowanego klienta TOR oraz zainstalować pakiet apt-transport-tor . W tym artykule postaramy się skonfigurować ten cały mechanizm TOR'owych aktualizacji.

Debian posiada bardzo rozbudowany system robienia pakietów. Generalnie rzecz biorąc, to wszystkie z nich musiały przejść przez ten proces zanim trafiły do głównego repozytorium dystrybucji. Dzięki takiemu stanu rzeczy, nie musimy ręcznie powielać pracy szeregu innych osób i odpada nam własnoręczna kompilacja pakietów, a wszyscy wiemy, że zajmuje ona cenny czas i zasoby. Paczki .deb są tworzone ze źródeł i instalowane przy pomocy menadżera pakietów aptitude/apt/dpkg . Nic jednak nie stoi na przeszkodzie by daną aplikację skompilować sobie ręcznie i zainstalować ją przy pomocy make install . Problem w tym, że w taki sposób robi się śmietnik w naszym systemie i śledzenie wszystkich zainstalowanych w ten sposób pakietów w pewnym momencie stanie się wręcz niemożliwe. Dlatego też przydałby nam się mechanizm, który ułatwiłby nam nieco to zadanie. Debian udostępnia szereg narzędzi, które są w stanie w pełni zautomatyzować cały ten proces budowy pakietów. Ten poradnik zaś ma na celu zebranie wszystkich istotniejszych informacji związanych z obsługą narzędzi takich jak dh_make , dpkg-buildpackage , pbuilder , quilt czy lintian , tak by tworzyć pakiety w prosty sposób i przy tym równając do najwyższych standardów debiana.

Aktualizacje systemu niosą ze sobą nowsze wersje pakietów. Czasami mają one błędy, które wychodzą na jaw po jakimś czasie korzystania z danej aplikacji. W takiej sytuacji zwykle zachodzi potrzeba cofnięcia wersji kilku pakietów. Jest jednak wielce prawdopodobne, że akurat tej wersji pakietu, której potrzebujemy, nie znajdziemy z repozytorium debiana. Pobieranie pojedynczych pakietów z internetu przez klikanie w pierwszy lepszy link, który zostanie nam zwrócony przez wyszukiwarkę, nie jest dobrym pomysłem. Na szczęście w przypadku debiana nie musimy się aż tak narażać. A to z tego względu, że debian robi migawki (shapshots) swoich repozytoriów 4 razy dziennie (co 6 godzin). W ten sposób mamy dostęp do różnych stanów repozytoriów, w tym też tych, które zawierają pakiety aktualnie niedostępne w repozytoriach. W tym wpisie postaramy się pobrać i zainstalować nieistniejące pakiety z takich snapshot'ów.

Posiadając nowszej klasy procesor, jesteśmy w stanie korzystać z 64 bitowego systemu operacyjnego. W przypadku windowsów uruchamianie aplikacji 32 czy 64 bitowych nie stanowi większego problemu. W na debianie sprawa wygląda nieco inaczej. Gdy mamy wgranego 64 bitowego debiana, aplikacje 32 bitowe nie będą chciały się nam odpalić. Wszystkiemu winne są biblioteki 32 bitowe, które są wykorzystywane przez dany program, a bez nich on zwyczajnie nie może działać. Jednym z rozwiązań tego problemu może być kontener LXC, gdzie jesteśmy w stanie zainstalować 32 bitowy system wewnątrz środowiska 64 bitowego i to z tego systemu możemy uruchamiać 32 bitowe aplikacje. Skonfigurowanie takiego kontenera może być nieco skomplikowane, dlatego też dużo lepszym rozwiązaniem jest przerobienie naszego 64 bitowego systemu na muliarch, czyli taki, który jest w stanie obsługiwać wiele architektur (multiarch).

W dobie całego tego świata informatycznego zwykliśmy polegać na osobach, których nigdy w życiu na oczy nie wiedzieliśmy, nie wspominając o jakimkolwiek kontakcie fizycznym. Zaufanie to obecnie chyba najbardziej krytyczna luka bezpieczeństwa jeśli chodzi o oprogramowanie, z którego korzystamy na co dzień. My, którzy używamy debiana w swojej pracy, polegamy na mechanizmach jakie oferuje nam apt czy aptitude przy weryfikacji pakietów przed ich instalacją w systemie. Co się jednak by stało gdyby w tych menadżerach pojawił się błąd, który by uniemożliwiał poprawną weryfikację pakietów? Skąd wiemy czy te mechanizmy zabezpieczające w ogóle działają? Może one nam dają jedynie fałszywe poczucie bezpieczeństwa, a tak naprawdę przez niczym nas nie chronią? W tym wpisie postaramy się odpowiedzieć na te powyższe pytania i sprawdzimy czy manualna weryfikacja pakietu jest w ogóle możliwa

Obecnie systemy operacyjne stają się nieco bardziej stabilne i czasy, w których reinstalacja takiego systemu, czy też nawet format dysku, odchodzą powoli w niebyt. Data instalacji mojego linux'a wskazuje na prawie 2 lata wstecz. Jakby nie patrzeć jest to szmat czasu, w czasie którego przez mojego Debiana przetoczyła się ogromna ilość oprogramowania. Nie zawsze były to pakiety, które pochodziły z głównych repozytoriów tej dystrybucji. Niemniej jednak, każde repozytorium z pakietami jest podpisane i by móc z nich bezpiecznie korzystać, trzeba pozyskać klucz GPG i dokonać jego weryfikacji. Prędzej czy później przyjdzie czas, gdy takie klucze GPG przestaną być ważne lub też zmianie ulegną źródła pakietów. W ten sposób baza danych kluczy zawierać będzie szereg zbędnych pozycji. Może wielu ludziom nie przeszkadza ten fakt ale raz na jakiś czas przydałoby się oczyścić keyring ze śmieci, które są już nam do niczego niepotrzebne.