Zaszyfrowane systemy (desktopy/laptopy) mają jeden poważny problem, gdy chodzi o zapewnianie bezpieczeństwa chronionym plikom przechowywanym na dyskach twardych. Gdy siedzimy obok naszej maszyny, możemy czuć się bezpiecznie, bo przecież nikt nie może się włamać do jej systemu bez naszej wiedzy. Nawet jeśli ktoś będzie próbował się dostać do naszego PC, to istnieje spora szansa, że takie działanie zostałoby natychmiast przez nas wykryte, przez co moglibyśmy w odpowiedni sposób zareagować na zaistniałe zagrożenie. Co jednak w przypadku, gdy zostawiamy przykładowo naszego laptopa samego? Nawet jeśli zablokujemy mu ekran, wyłączymy go albo zahibernujemy, to ta maszyna wciąż nie jest odpowiednio zabezpieczona, by uniemożliwić osobom postronnym dostęp do naszych wrażliwych danych. Problem leży w fizycznym dostępie do sprzętu, który ludzie mogą uzyskać, gdy nas nie ma w pobliżu naszego komputera. W taki sposób osoby trzecie mogą wykorzystać fakt, że tracimy maszynę z oczu i być w stanie zastawić na nas różne pułapki. By uniknąć zagrożenia związanego z zostawieniem laptopa/desktopa bez nadzoru, nie możemy w zasadzie pozostawiać tego urządzenia samego, co jest zadaniem praktycznie nie do wykonania. Komputery stacjonarne czy nawet laptopy nie są urządzeniami o małych gabarytach i zwykle nie możemy ich wszędzie zabrać ze sobą, w przeciwieństwie do smartfonów. Postanowiłem zatem tak skonfigurować swojego linux'a, by jego zaszyfrowany dysk (LUKS + LVM) można było odszyfrować jedynie przy pomocy mojego telefonu z Androidem, z którym w zasadzie się nie rozstaję.

Prawdopodobnie zauważyliście drobne zmiany w wyglądzie tego bloga oraz pewnie też cześć osób miała w ostatnim czasie problemy z uzyskaniem do niego dostępu. Odpowiedzialne za zaistniałą sytuację są limity narzucone przez GitHub Pages. Zakładają one maksymalny rozmiar repozytorium pod stronę WWW w granicach 1 GiB oraz czas budowania takiego serwisu krótszy niż 10 minut. Limit miejsca na pliki przekroczony został w zasadzie w chwili przeniesienia bloga WordPress na GitHub Pages. Natomiast parę dni temu został przekroczony limit czasu budowania tego projektu. Do momentu transformacji, niniejszy blog działał w oparciu o Jekyll, który generował w zasadzie statyczny kod HTML ze zwykłych plików tekstowych (np. artykuły pisane w MarkDown). GitHub Pages posiada wsparcie dla Jekyll, przez co taką stronę WWW można bardzo prosto wdrożyć. Niemniej jednak, cały ten mechanizm generowania projektu w obrębie infrastruktury GitHub'a zajmuje bardzo dużo czasu. Po rozmowie z supportem okazało się, że gdyby chodziło o miejsce na pliki, to mogli by nagiąć reguły i nie było by problemu ale nie dadzą rady tego zrobić w przypadku przekroczenia czasu generowania projektu. Dlatego też trzeba było zrezygnować z Jekyll'a i poszukać dla niego jakiejś alternatywy. Padło na Hugo, który w odróżnieniu od Jekyll'a nie jest jako tako wspierany przez GitHub i by stronę wygenerowaną przez Hugo podpiąć pod GitHub Pages trzeba się trochę wysilić, bo ten proces nie jest automatyczny i właśnie o tym jak dokonać migracji z Jekyll na Hugo w kontekście GitHub Pages będzie ten poniższy artykuł.

Obecnie szyfrowanie zapytań DNS staje się powoli normą za sprawą protokołu DoH (DNS over HTTPS) lub DoT (DNS over TLS). Można by zatem pomyśleć, że wraz z implementacją szyfrowania tego kluczowego dla działania internetu protokołu (przynajmniej z naszego ludzkiego punktu widzenia), poprawie ulegnie również nasza prywatność w kwestii odwiedzanych przez nas stron WWW. Niemniej jednak, w dalszym ciągu można bez problemu wyciągnąć adresy domen, które zamierzamy odwiedzić. Nie ma przy tym żadnego znaczenia ile stron jest hostowanych na danym adresie IP, ani nawet fakt, że ruch do serwera WWW będzie szyfrowany (w pasku adresu wpiszemy https:// ) z wykorzystaniem protokołu SSL/TLS (w tym również TLS v1.3). Wszystko przez rozszerzenie SNI (Server Name Indication), którego to zadaniem jest umożliwienie jednemu serwerowi na prezentowanie wielu certyfikatów hostowanych w jego obrębie domen. Dzięki takiemu rozwiązaniu, każda domena może szyfrować ruch niezależnie od siebie na linii serwer<->klient (używać innych kluczy szyfrujących). Niemniej jednak, podczas nawiązywania szyfrowanego połączenia, w pakiecie ClientHello przesyłanym do takiego serwera musi znaleźć się nazwa domeny, której to certyfikat serwer będzie musiał nam przedstawić. Niestety ten pakiet jest przesyłany przez sieć otwartym tekstem, przez co każdy, kto podsłuchuje naszą komunikację (w tym też nasz ISP), bez problemu może ustalić na jakie strony internetowe wchodzimy. Ostatnimi czasy jednak pojawiły się dwa rozszerzenia ECH (Encrypted Client Hello) oraz ESNI (Encrypted SNI), które mają zaadresować problemy związane z prywatnością przez pełne zaszyfrowanie pakietu ClientHello lub też zaszyfrowanie jedynie pola SNI w tym pakiecie. Póki co, prace nad tymi rozszerzeniami nie są jeszcze skończone ale Firefox w połączeniu z CloudFlare powoli testują ESNI. Postanowiłem zatem dobrowolnie przyłączyć się do grupy testerów i wdrożyć na swoim linux'ie to rozszerzenie ESNI dla przeglądarki Firefox.

Bawiąc się ostatnio maszynami wirtualnymi na bazie QEMU/KVM, zauważyłem, że sugerowany rozmiar pliku .qcow2 waha się w okolicach 25 GiB. Nie jest to może jakoś specjalnie dużo ale mało to też nie jest, zwłaszcza jeśli tworzymy maszyny wirtualne na dysku swojego laptopa. Co jeśli przeholowaliśmy z szacunkami co do rozmiaru takiego obrazu i po zainstalowaniu systemu operacyjnego gościa okazało się, że w sumie to ten obraz można by zmniejszyć o połowę? Albo też i w drugą stronę, tj. co w przypadku, gdy stworzony obraz maszyny wirtualnej okazał się zbyt mały i teraz zachodzi potrzeba jego powiększenia? Czy w takiej sytuacji musimy na nowo tworzyć maszynę wirtualną odpowiednio zwiększając lub zmniejszając jej przestrzeń na pliki? A może istnieje jakiś sposób na zmianę rozmiaru tych istniejących już obrazów maszyn wirtualnych? Postaramy się ten fakt zweryfikować, a cały proces zostanie opisany przy wykorzystaniu systemu Debian Linux.

W linux rozmiar stron pamięci operacyjnej RAM ma domyślnie 4096 bajtów (4 KiB). Maszyny wirtualne QEMU/KVM mają to do siebie, że wykorzystują dość spore zasoby pamięci (wile GiB), przez co mały rozmiar strony może niekorzystnie wpływać na wydajność systemów gościa. Chodzi generalnie o to, że rozrostowi ulega tablica stron, której przeszukiwanie jest czasochłonną operacją. By temu zaradzić, wymyślono TLB (Translation Lookaside Buffer), który ulokowany jest albo w CPU albo gdzieś pomiędzy CPU i główną pamięcią operacyjną. TLB to mały ale za to bardzo szybki cache. W przypadku systemów z duża ilością pamięci RAM, niewielki rozmiar TLB sprawia, że odpowiedzi na zapytania nie są brane z cache, tylko system wraca do przeszukiwania normalnej tablicy stron zlokalizowanej w pamięci RAM (TLB miss). Taka sytuacja jest bardzo kosztowna, spowalnia cały system i dlatego trzeba jej unikać. Na szczęście jest mechanizm HugePages, który pozwala na zwiększenie rozmiaru strony pamięci z domyślnych 4 KiB do 2 MiB lub nawet do 1 GiB w zależności od właściwości głównego procesora. W tym artykule postaramy się skonfigurować HugePages na potrzeby maszyn wirtualnych dla systemu Debian Linux.

Prawdopodobnie dla większości użytkowników linux'a, wirtualizacja kojarzy się w zasadzie z jednym oprogramowaniem, tj. VirtualBox. Niby strona VBox'a podaje, że jest on na licencji GPL-2 ale w Debianie nie ma go w głównym repozytorium (jest on obecny w sekcji contrib ). Problem z VirtualBox'em jest taki, że wymaga on kompilatora Open Watcom, który już wolnym oprogramowaniem nie jest. VBox też nie jest jedynym oprogramowaniem, które na linux można wykorzystać w roli hiperwizora do obsługi maszyn wirtualnych. Jest o wiele lepsze rozwiązanie, mianowicie QEMU, które jest w stanie zrobić użytek z maszyny wirtualnej kernela (Kernel Virtual Machine, KVM) i realizować dokładnie to samo zadanie, które zwykł ogarniać VirtualBox. Wirtualizacja na bazie QEMU/KVM jest w pełni OpenSource, co ucieszy pewnie fanów wolnego i otwartego oprogramowania, choć zarządzanie maszynami wirtualnymi odbywa się za sprawą konsoli. Oczywiście, osoby które korzystają z VirtualBox'a zdają sobie sprawę, że to narzędzie oferuje graficzny menadżer maszyn wirtualnych (Virtual Machine Manager, VMM), który usprawnia i znacznie ułatwia zarządzanie wirtualnymi maszynami. Jeśli GUI jest dla nas ważnym elementem środowiska pracy i nie uśmiecha nam się konfigurować maszyn wirtualnych przy pomocy terminala, to jest i dobra wiadomość dla takich osób, bo istnieje virt-manager , który jest dość rozbudowanym menadżerem maszyn wirtualnych pozwalającym na ich tworzenie, konfigurowanie i zarządzanie nimi przy wykorzystaniu graficznego interfejsu użytkownika. W tym artykule postaramy się skonfigurować naszego Debiana w taki sposób, by przygotować go do pracy z maszynami wirtualnymi posługując się qemu/libvirt/virt-manager .

Dnia 29-07-2020 do publicznej wiadomości zostały podane informacje na temat podatności BootHole, która to za sprawą bootloader'a GRUB2 w różnych dystrybucjach linux'a jest w stanie obejść mechanizm bezpieczeństwa EFI/UEFI, tj. Secure Boot. Z informacji, które opublikował Debian, sprawa nie wygląda miło, jako że poza aktualizacją GRUB2, shim, jądra linux, Fwupdate oraz Fwupd, unieważnieniu podlegają również klucze dystrybucji Debian/Ubuntu, przez co praktycznie cały soft podpisany tymi kluczami (w tym systemy live) przestaną działać w trybie Secure Boot. Czy jest się czego obawiać i co użytkownik korzystający z mechanizmu SB powinien w takiej sytuacji zrobić?

Jakiś czas temu opisywałem konfigurację własnych kluczy EFI/UEFI, którymi można zastąpić te wbudowane standardowo w firmware naszego komputera. W tamtym artykule napotkałem jednak dość dziwny problem, za sprawą którego nie można było zaktualizować zmiennych PK , KEK , db i dbx przy pomocy efi-updatevar z poziomu działającego linux'a. Gdy próbowało się te zmienne przepisać, dostawało się błąd typu Operation not permitted . Niby system został uruchomiony w trybie Setup Mode ale z jakiegoś powodu odmawiał on współpracy i trzeba było te zmienne aktualizować bezpośrednio z poziomu firmware EFI/UEFI, co było trochę upierdliwe. Szukając wtedy informacji na ten temat, jedyne co znalazłem, to fakt, że sporo osób ma podobny problem i najwyraźniej firmware mojego laptopa jest ździebko niedorobiony, przez co efi-updatevar nie mógł realizować swojego zdania. Rzeczywistość okazała się nieco inna, a rozwiązanie samego problemu było wręcz banalne.

Bawiąc się ostatnio QEMU/KVM na swoim laptopie z zainstalowanym Debianem natrafiłem na ciekawe zagadnienie związane z wirtualizacją, tj. z PCI passthrough. Nie chodzi mi tutaj o samą technikę PCI passthrough ale o dobór sterowników do urządzeń działających pod kontrolą linux. Każdy sprzęt, który ma działać w systemie, musi mieć załadowany w pamięci RAM stosowny moduł kernela. Te moduły zwykle są ładowane automatycznie podczas pracy systemu, np. gdy podłączamy nowy sprzęt do komputera (można też te moduły ładować i ręcznie via modprobe ). Gdy nasz linux z jakiegoś powodu dobierze niewłaściwy (z naszego punktu widzenia) moduł dla jakiegoś urządzenia, to możemy to urządzenie odłączyć od komputera, a moduł bez problemu wyładować, po czym dokonać stosownych poprawek w systemie. Problem zaczyna się w sytuacji, gdy mamy do czynienia ze sprzętem, którego nie da się od komputera fizycznie odłączyć, np. wbudowana w płytę główną karta dźwiękowa, czy też wbudowana grafika bezpośrednio w CPU. Podobnie sprawa wygląda w przypadku wkompilowania modułów na stałe w kernel -- jak wyładować moduł, którego się nie da wyładować? By w takich sytuacjach zmienić przypisany urządzeniu sterownik trzeba dodać parę plików w katalogach /etc/modules-load.d/ / /etc/modprobe.d/ oraz zrestartować maszynę, tak by podczas fazy boot kernel dobrał sprzętowi pożądane przez nas moduły i ich konfigurację. Niemniej jednak, istnieje prostszy sposób na zmianę sterownika działającego w systemie sprzętu i to bez potrzeby fizycznego restartowania maszyny. Chodzi o mechanizm ręcznego przypisywania urządzeń do konkretnych sterowników (manual driver binding and unbinding).

Jakiś czas temu opisywałem moduł TPE (Trusted Path Execution) dla kernela linux, który jest w stanie dość znacznie poprawić bezpieczeństwo naszego systemu. Ostatnio jednak natknąłem się na moduł LKRG (Linux Kernel Runtime Guard), którego to zadaniem jest stać na straży samego jądra operacyjnego i chronić je w czasie rzeczywistym przed różnego rodzaju zagrożeniami poprzez wykrywanie eksploitów wykorzystujących luki w jego mechanizmach bezpieczeństwa. Jako, że ja bardzo lubię zbroić swojego Debiana, to postanowiłem się przyjrzeć nieco bliżej temu całemu LKRG i sprawdzić jego użyteczność. Trzeba jednak wiedzieć, że LKRG jest dostarczany w formie osobnego modułu zamiast łaty na kernel, przez co trzeba będzie także postarać się o automatyzację pewnych rzeczy, m.in. procesu budowania modułu przy aktualizacji kernela via DKMS.