Parę dni temu opisywałem jak udało mi się realokować uszkodzony sektor z dysku, który już przepracował dość długi okres czasu. Nie było to znowu jakoś specjalnie trudne, z tym, że cały problem dotyczył jakiegoś losowego sektora gdzieś w środku partycji. Jako, że domyślnym systemem plików na linuxie są te z rodziny ext (ext2, ext3, ext4) , oraz, że trzecia wersja tego systemu plików została wyposażona w dziennik (journal), to trzeba by się zastanowić, co w przypadku gdy taki uszkodzony sektor trafi się właśnie w dzienniku tego systemu plików?

Pisząc ostatni artykuł na temat udeva i montowania przy jego pomocy zaszyfrowanego kontenera, wpadł mi do głowy ciekawy pomysł na trzymanie pliku klucza (keyfile) w czymś co się potocznie nazywa "głębokim ukryciem". Z reguły ludzie nie chcą używać haseł do odblokowywania swoich systemów czy partycji i zamiast nich wolą stosować keyfile, czyli małe pliki, zwykle o rozmiarze paru KiB, które, jakby nie patrzeć, są dość unikatowe i odporne na ataki słownikowe czy inne formy przemocy. Jedyny problem z jakim człowiek musi się zmierzyć, to z zabezpieczeniem takiego keyfile i tutaj sprawa nie wygląda wcale dobrze. Takie pliki klucze są trzymane zwykle na tym samym urządzeniu, do których mają zapewniać bezpieczny dostęp, a nawet jeśli nie na tym samym, to w pobliżu takich urządzeń, dając nam tym samym jedynie fałszywe poczucie bezpieczeństwa.

Uszkodzone sektory w przypadku dysków HDD, to jak sama nazwa wskazuje, sektory, które z jakichś przyczyn nie działają tak jak powinny. Doprowadza to z reguły do niestabilności systemu operacyjnego objawiającej się jego zawieszaniem w momencie próby odczytu danych z takiego padniętego sektora. Przyczyny mogą być różne. Zwykle jest to jednak fizyczne uszkodzenie powierzchni nośnika, np w wyniku wstrząsu, czy też zwyczajne zmęczenie materiału. Jest wielce prawdopodobne, że nie jesteśmy w stanie nic poradzić w tego typu sytuacji, a ci bardziej zaawansowani użytkownicy zalecają jak najszybszą wymianę dysku, bo pierwszy bad sektor oznacza, że niedługo będzie ich więcej. Czasem jednak błędy odczytu mogą być programowe, tj. fizycznie każdy sektor jest w porządku ale z jakiegoś powodu system nie potrafi odczytać z nich danych. Przy odrobinie szczęścia jesteśmy w stanie odblokować taki sektor.

Udało mi się znaleźć trochę informacji ma temat parametru S.M.A.R.T 198 , tj. Offline Uncorrectable . Wychodzi na to, że część dysków nie resetuje go, nawet po pomyślnym przejściu testu offline. Za to demon smartd domyślnie ma ustawione informowanie o niezerowej wartości tego atrybutu w logu systemowym i prawdopodobnie chyba nie da się nic zrobić w tej sprawie ale można poinstruować smartd by wyrzucał komunikat tylko w przypadku gdy wartość tego atrybutu zostanie zwiększona w stosunku do wartości zapisanej przy poprzednim skanowaniu, czyli jeśli teraz mamy wartość, np. 2, to ostrzeżenie pojawi się gdy będzie tam widniało 3 i więcej.

Suma kontrolna daje możliwość sprawdzenia czy dane zawarte w pliku nie zostały zmienione podczas transferu z jednego medium informacyjnego na inne. Jeśli weźmiemy przykład pakietów sieciowych, to pliki przesyłane między dwoma punktami są dzielone na mniejsze kawałki. W każdym z nich są zawarte sumy kontrole danych, które zawierają. Komputer odbierający taki pakiet generuje własną sumę kontrolą i porównuje ją z tą otrzymaną w pakiecie. W przypadku gdy suma kontrolna się nie zgadza, mamy do czynienia z błędami przesyłu, tj. pakiet został uszkodzony gdzieś po drodze. W tej sytuacji maszyna odbierająca dane prosi o ponowne przesłanie uszkodzonego segmentu. Ta sytuacja może się zdarzyć ale błędy są automatycznie naprawiane. Problem jest taki, że przy pobieraniu plików z internetu nie zawsze korzystamy z bezpiecznych połączeń, poza tym, zawsze ktoś może uzyskać dostęp do serwera i podmienić pliki. Czy możemy zatem mieć pewność, że dany plik trafił do nas w formie takiej jak powinien?

Wiele czasu zajęło mi opanowanie w końcu tych bestii zwanych dirty pages, które to są trzymane w cache pamięci RAM i potrafią dać się nieźle we znaki, zwłaszcza gdy ma się mało pamięci operacyjnej i maszynę 64 bitową. Chodzi o to, że podczas kopiowania plików z/na pendrive, system zaczyna się strasznie przycinać, bo następuje zrzucanie danych innych procesów z RAM do SWAP by zrobić miejsce pod te dane, które są aktualnie kopiowane.

Narzędzie gpg posiada swój własny plik konfiguracyjnych, który zwykle jest zlokalizowany w ~/.gnupg/gpg.conf . Można w nim sprecyzować większość z opcji, które zwykle są podawane w terminalu przy wywoływaniu polecenia gpg . Po zdefiniowaniu odpowiednich wpisów w pliku konfiguracyjnym, nie będziemy musieli już wyraźnie podawać tych parametrów ilekroć będziemy chcieli skorzystać z gpg . Przy okazji szukania info o kluczach GPG, natknąłem się na dość ciekawy artykuł na temat GnuPG. Jest tam sporo informacji, które są wielce użyteczne w procesie konfiguracji tego narzędzia poprawiając tym samym dość znacznie bezpieczeństwo komunikacji.

Zapuszczając się w coraz to i głębsze warstwy systemu podczas dążenia do zbadania jak on tak naprawdę działa, zacząłem się stykać z regułami udev'a (tymi umieszczanymi w katalogu /etc/udev/rules.d/ ). Jako, że nazbierało mi się już ich kilka, zaistniała potrzeba przebadania tego co ten katalog tak naprawdę zawiera. Na dobrą sprawę nigdy się nad tym nie zastanawiałem, jedynie kopiowałem rozwiązania z internetu i wklejałem je do odpowiedniego pliku i jeśli ono działało, to odznaczałem problem jako rozwiązany. Zwykle takich reguł się nie potrzebuje, temu praktycznie niewielu ludzi w ogóle się orientuje jak ogarnąć tego całego udeva. Są przypadki kiedy przepisanie nazw urządzeń czy wykonanie określonych akcji po podłączeniu jakiegoś sprzętu do komputera jest wielce niezbędne i nie ma innej opcji jak tylko zrozumieć co udev tak naprawdę robi.

Wszelkie obrazy .iso płyt cd/dvd czy nawet pliki .img zawierające strukturę obrazów live możemy zamontować lokalnie na komputerze uzyskując tym samym dostęp do ich systemu plików. W większości przypadków, każdy taki obraz zawiera tylko jedną partycję, czasem lekko przesuniętą względem początku ale generalnie nie ma większych problemów z zamontowaniem tego typu plików. Najwyżej trzeba podać jeden dodatkowy parametr, tj. offset . A co w przypadku obrazów dysków, które zwykle mają więcej niż jedną partycję? Gdybyśmy spróbowali zamontować taki plik w systemie, to zostanie nam zwrócony błąd, no bo przecież kernel nie wie za bardzo jak taki plik ma odczytać. Możemy za to skorzystać z urządzeń loop , które po odpowiedniej konfiguracji, są w stanie nam takie obrazy z powodzeniem zamontować na naszym linux'ie.

Struktura pliku .img czy .iso niczym nie odbiega od struktury przeciętnego dysku twardego. W obu przypadkach mamy dokładnie taki sam schemat budowy, tj. mamy obecny MBR i partycje, z których pierwsza zwykle jest wyrównana do 1MiB, zostawiając tym samym 2047 sektorów wolnego miejsca z początku pliku, tuż za MBR, tzw. MBR-GAP. Obraz .img można poddać edycji, np. utworzyć wewnątrz niego inne partycje, zmienić rozmiar ich systemu plików, a nawet można manipulować rozmiarem samego obrazu .img . Taki plik możemy również zamontować w systemie przy pomocy narzędzia mount ale też trzeba odpowiednio podejść do tego zadania, bo przez fakt, że mamy z początku MBR i trochę wolnego miejsca, to linux zwyczajnie nie potrafi rozpoznać systemu plików, który znajduje się w obrazie .img.