Każdy kto ma laptopa wyposażonego w kartę WiFi, czy też ogólnie komputer posiadający bezprzewodową sieciówkę, ten prawdopodobnie spotkał się z błędem podobnym do tego: Direct firmware load for iwlwifi-6000g2a-6.ucode failed with error -2 . W tym przypadku sprawa dotyczyła karty Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] działającej w oparciu o moduł kernela iwlwifi . W takich przypadkach zwykle wystarczy zainstalować firmware od określonego modułu i po kłopocie. No i faktycznie w Debianie jest dostępny pakiet firmware-iwlwifi , który zawiera ten potrzebny plik iwlwifi-6000g2a-6.ucode . Problem jednak w tym, że instalacja paczki z firmware niekoniecznie może nam pomóc. Ten powyższy przykład nie jest odosobniony i czasami pliki z firmware muszą być dostępne w chwili ładowania kernela do pamięci RAM czy też na etapie initramfs/initrd. W takim przypadku zainstalowanie paczki z firmware w naszym linux'ie nic nam nie da, bo pliki rezydują na niezamontowanym jeszcze dysku. Jak zatem wybrnąć z tej wydawać by się było patowej sytuacji?

Zapewne każdy z nas słyszał o narzędziu do testowania pamięci operacyjnej RAM zwanym memtest86. W Debianie są dostępne dwa pakiety memtest86 (strona projektu) oraz memtest86+ (strona projektu) , które można sobie zainstalować w systemie. Niemniej jednak, jak się popatrzy na daty ostatnich wersji obu tych aplikacji (rok 2014), to mamy do czynienia z dość starym oprogramowaniem. Tak czy inaczej, jeśli dany soft działa, to bez znaczenia powinno być jak stary on jest. Problem w przypadku memtest86 dostarczanego w tych dwóch pakietach jest taki, że działa on w zasadzie jedynie w konfiguracji BIOS, a nie EFI/UEFI. Dodatkowo, oryginalny memtest86 został sprzedany PassMark'owi, który od wersji 5.0 uczynił go własnościowym softem. To dlatego w Debianie nie będzie już nowszej wersji memtest86. W dalszym ciągu memtest86 może działać w konfiguracji EFI/UEFI ale potrzebna nam jest wersja, która to EFI/UEFI wspiera. Memtest86 zaczął wspierać EFI/UEFI od wersji 5.0. Jeśli nam nie przeszkadza licencja własnościowa, to możemy sobie przygotować memtest86, tak by można go było bez problemu odpalić z menadżera rozruchu rEFInd.

Szukając informacji na temat uruchamiania mojego zaszyfrowanego Debiana (LUKSv2+LVM) na laptopie z EFI/UEFI, natrafiłem na dość ciekawy mechanizm zwany kernel EFI boot stub, czasem też zwany kernel EFISTUB. Zadaniem tego mechanizmu jest uruchomienie linux'a bezpośrednio z poziomu firmware EFI z pominięciem czy też bez potrzeby stosowania dodatkowych menadżerów rozruchu (rEFInd) czy bootloader'ów (grub/grub2/syslinux/extlinux). Jakby nie patrzeć bardzo ciekawa alternatywa, która wymaga, by się z nią zapoznać i ocenić jej przydatność pod kątem użyteczności.

Mając możliwość skonfigurowania EFI/UEFI na moim laptopie, postanowiłem jak najbardziej się za to przedsięwzięcie zabrać. Okazało się jednak, że w przypadku takiej dystrybucji linux'a jak Debian, to zadanie może być nieco problematyczne, zwłaszcza gdy chce się korzystać jedynie z menadżera rozruchu jakim jest rEFInd, czyli bez dodatkowego bootloader'a (grub/grub2/syslinux/extlinux) instalowanego bezpośrednio na dysku twardym i jednocześnie posiadając w pełni zaszyfrowany system (LUKSv2 + LVM). Rzecz w tym, że w takiej sytuacji w konfiguracji rEFInd trzeba podawać ścieżki bezpośrednio do plików initrd.img oraz vmlinuz (obecnych na partycji /boot/ ). W Debianie nazwy tych plików mają format initrd.img-x.x.x-x-amd64 i vmlinuz-x.x.x-x-amd64 . Za każdym razem, gdy wypuszczany jest nowy kernel, to ten numerek ( x.x.x-x ) ulega zmianie, co pociąga za sobą potrzebę ręcznego dostosowania konfiguracji rEFInd. Może i aktualizacje kernela w Debianie nie są jakoś stosunkowo częste ale może istnieje sposób, by ten problem z dostosowaniem konfiguracji rozwiązać?

Ostatnio udało mi się nabyć dość niedrogo laptop Lenovo, a konkretnie był to model ThinkPad T430. Maszyna jakby nie patrzeć jest bardzo kompatybilna z linux i w zasadzie nie mogę jej nic zarzucić, przynajmniej póki co. Niemniej jednak, jest pewien szkopuł, który mnie zaczął ździebko irytować od praktycznie samego początku jak tylko podłączyłem ten komputer do prądu. Chodzi o wentylator chłodzący radiator procesora, który no troszkę daje o sobie znać i to mimo faktu, że temperatura CPU jest w granicach 40 stopni. Przeglądając opcje w BIOS nie natrafiłem na nic co mogło by te obroty wyregulować. Na szczęście w przypadku laptopów Lenovo można programowo zdefiniować obroty wiatraka posługując się narzędziem thinkfan.

Przeglądając ostatnio listę sprzętów podłączonych do mojego routera WiFi, zauważyłem, że niektóre pozycje na niej w polu z hostname mają coś na wzór android-4c52c33baae0b4fa . Pierwsza część nazwy tego hosta wskazuje na system operacyjny, a drugi kawałek to unikalny numerek ID. Nie jestem zbytnio fanem rozgłaszania takich informacji publicznie, bo mogą one ułatwić ewentualne ataki, oraz też identyfikują jednoznacznie dane urządzenie (osobną kwestią jest adres MAC karty sieciowej). Ponadto, mając w sieci wiele mobilnych urządzeń, ciężko jest czasem połapać się który telefon ma przypisany konkretny adres IP (bez patrzenia w ustawienia telefonu). Z reguły na linux'owym desktopie czy laptopie zmiana hostname jest stosunkowo łatwym zadaniem ale w przypadku smartfona z Androidem ten zabieg okazał się niezmiernie trudnym procesem. Jak zatem zmienić hostname telefonu, by można było mu przypisać jakaś w miarę ludzką nazwę?

Część użytkowników smartfonów z Androidem na pokładzie żyje w głębokim przekonaniu, że instalowanie aplikacji spoza sklepu Google Play nie jest zbyt rozważnym posunięciem. Nie chodzi tutaj tylko o szeroko rozumiane alternatywne źródła aplikacji, np. serwis apkmirror ale również o Yalp/Aurora Store czy też repozytoria F-Droid. Zdaniem tych osób pobieranie aplikacji z zewnętrznych źródeł może skompromitować bezpieczeństwo systemu oraz zagrozić naszej prywatności. No jakby nie patrzeć wgrywanie czegokolwiek bez zastanowienia się co tak naprawdę instalujemy w systemie nie jest zbyt mądre. Dlaczego zatem nie weryfikujemy aplikacji obecnych w oficjalnym sklepie Google? Co chwila przecież można usłyszeć w mediach o syfie, który udało się co prawda z tego sklepu usunąć ale też jakaś większa liczba użytkowników taką aplikację zdążyła już zainstalować i używała jej przez dłuższy lub krótszy okres czasu. Rozumowanie na zasadzie, że aplikacje ze sklepu Google Play są bezpieczne, bo są obecne w sklepie Google Play, daje nam jedynie fałszywe poczucie bezpieczeństwa, które jest gorsze od całkowitego braku bezpieczeństwa, bo w tym drugim przypadku człowiek przynajmniej jest świadom czyhających na niego niebezpieczeństw i włącza myślenie. Jak zatem odróżnić aplikacje, które są w stanie nam wyrządzić krzywdę od tych, które tego nie mają na celu i czy faktycznie pobieranie aplikacji na Androida z innego źródła niż oficjalny sklep Google Play jest takie niebezpieczne?

Obrazy ISO różnych dystrybucji Linux, szczególnie te live, bywają niezastąpione w sytuacjach kryzysowych. Dzięki takiej płytce CD/DVD czy pendrive (może być też i karta SD) można wybrnąć nawet z najgorszych opresji bez potrzeby rezygnowania przy tym z graficznego środowiska pracy podłączonego do internetu. Zwykle jednak użytkownicy są stawiani przed wyborem systemu, który mogą sobie wgrać na zewnętrzny nośnik, by w późniejszym czasie przeprowadzać ewentualne prace naprawcze. Chodzi generalnie o fakt, że taki obraz ISO czy IMG przy wgrywaniu konsumuje całe urządzenie bez względu na jego rozmiar, i tak mając 32G pamięci na flash możemy wgrać w zasadzie tylko jeden obraz, np. Debiana, a by wgrać obraz Ubuntu, to już trzeba albo osobnego pendrive albo nadpisać ten poprzednio wgrany obraz. Takie rozwiązanie jest mało praktyczne i też generuje koszty. Na szczęście można stworzyć boot'owalny pendrive (w oparciu o GRUB/GRUB2), na którym można umieścić dowolną ilość obrazów ISO i w fazie rozruchu wybrać sobie ten system, który nas interesuje, a wszystko dzięki projektowi GLIM (GRUB Live ISO Multiboot).

Zapewne wielu użytkowników Debiana zdążyło już zauważyć, że od wydania 10 (Buster), AppArmor jest włączony domyślnie. Nie powinien on raczej sprawiać żadnych problemów po doinstalowaniu pakietów apparmor-profiles oraz apparmor-profiles-extra , które zawierają szereg profili pod różne aplikacje użytkowe. Niemniej jednak, pewnych procesów nie da się ograniczyć przez AppArmor, przynajmniej nie w standardowy sposób. Chodzi o to, że jeśli mamy już odpalony jakiś proces, to nie ma możliwości zamknąć go w profilu AA do momentu aż zakończy on swoje działanie i zostanie uruchomiony ponownie. Profile AppArmor'a są ładowane podczas startu systemu w pewnym określonym momencie ale szereg procesów systemowych startuje sporo wcześniej w stosunku do usługi AppArmor'a. W taki sposób nawet jeśli w późniejszym czasie profile zostaną załadowane, to i tak część procesów nie będzie ograniczona bez względu na to czy zdefiniowaliśmy im zestaw reguł. Oczywiście można próbować restartować usługi lub szeregować je po apparmor.service ale nie zawsze tak się da zrobić. Alternatywnym rozwiązaniem tego problemu jest ładowanie polityki AppArmor'a w fazie initrd/initramfs, czyli w momencie, w którym nasz system nie ma jeszcze nawet uruchomionego procesu z PID z numerkiem 1 .

Od jakiegoś czasu tworzę dla aplikacji w moim Debianie profile pod AppArmor, tak by ograniczyć programom swobodny dostęp do plików czy urządzeń. Tych profili zebrało się już trochę i podczas pisania jednego z nich, zacząłem się zastanawiać czy wszystkie CAP'y (linux capabilities), których żądają procesy, są im faktycznie niezbędne do prawidłowego funkcjonowania. Chodzi póki co o dac_read_search i dac_override . Co ciekawe, odmowa dac_override w części aplikacji nie powodowała żadnych negatywnych konsekwencji. Idąc dalej tym tropem, postanowiłem z paru profili AA usunąć linijkę zawierającą capability dac_override, zostawiając tym samym jedynie capability dac_read_search, i zobaczyć co się stanie. Okazało się, że sporo programów już o dac_override nie prosi. Zatem co się zmieniło przez tych parę lat i czy ta zmiana dotyczy samych aplikacji, a może kernela linux'a?