Opisując mechanizm szyfrowania katalogu domowego przy pomocy narzędzia encfs , wspomniałem o problemie jaki powstaje przy jednoczesnym braku szyfrowania przestrzeni wymiany SWAP. Oczywiście, jeśli posiadamy w systemie dużą ilość pamięci RAM, to raczej nie potrzebna nam jest przestrzeń wymiany. Podobnie sprawa ma się w przypadku, gdy nie korzystamy z hibernacji. Natomiast, jeśli jedna z naszych partycji jest sformatowana jako SWAP i aktywnie z niej korzystamy, to niepełne szyfrowanie dysku, jakie zapewnia encfs może doprowadzić do skompromitowania zaszyfrowanych danych.

Wielu ludzi uważa, że szyfrowanie całego dysku jest zbędne i pozbawione większego sensu, no bo przecie "system nie zawiera żadnych wrażliwych danych, które by wymagały szyfrowania". Nie będę się tutaj spierał co do tego punktu widzenia, bo raczej wszyscy znają moje zdanie na temat "danych wymagających szyfrowania" i skupię się tu raczej na tym jak troszeczkę podratować niepełne szyfrowanie, które ludzie, nie wiedząc czemu, są bardziej skłonni stosować, niż cały ten full disk encryption.

Narzędzie encfs nie przeszło pomyślnie audytu bezpieczeństwa, a to z takiego powodu, że projekt nie był rozwijany przez szereg lat. Obecnie jest on w rekach społeczności i to od niej będzie zależeć czy te wykryte błędy zostaną poprawione.

Jakiś czas temu natknąłem się na moduł pam-usb , który to w dość ciekawy sposób zabezpiecza dostęp do konta użytkownika root. Cały mechanizm opiera się o pendrive, którego to unikalne cechy są brane pod uwagę przy uwierzytelnianiu podczas logowania się na konto super użytkownika, czyli min. gdy wydajemy polecenie su albo sudo . Jest to o tyle ciekawa rzecz, że konto użytkownika root możne stać się niewrażliwe na próby złamania hasła w przypadku połączenia sieciowego. Jak by nie patrzeć, atakujący, który łączy się zdalnie, nie jest w stanie podłączyć do naszego komputera żadnego fizycznego urządzenia, w wyniku czego nigdy nie uzyska dostępu do konta administratora.

Pakiet libpam-usb wyleciał z debiana jakiś czas temu. Powodem były zależności, które wskazywały na przestarzały już pakiet udisks . Poza tym, nikt nie zajmował się tym pakietem. Obecnie jest on dostępny jedynie w starszych wydaniach debiana.

Podczas ogarniania kolekcji filmów i przerabiania jej w taki sposób by został nam tylko jeden plik, tj. kontener MKV, możemy czasem napotkać problemy, które mogą nam uniemożliwić to zadanie. Może się zdarzyć tak, że będziemy mieli do czynienia z innymi kontenerami niż MKV, np. MP4. Ten wpis będzie poświęcony właśnie tego rodzaju kontenerom.

Wiele osób posiada pliki video i ci co uczą się angielskiego, czy innych języków, niezbyt przepadają za słuchaniem polskiego lektora na filmach, bo zagłusza on przecie całą oryginalną ścieżkę audio. Poza tym, jakość tłumaczenia jest na żenująco niskim poziomie. Z samego słuchu człowiek ciężko się uczy, zwłaszcza jak zaczyna naukę nowego języka, dlatego też można sobie dociągnąć polskie napisy. Co jednak w przypadku, gdy chcemy mieć kilka ścieżek audio czy napisów w jednym filmie? Posiadanie wielu plików wprowadza trochę zamętu. Poniżej zostanie opisany sposób na ogarnięcie kolekcji filmowej, tak by został nam się tylko jeden plik w przypadku każdego ulubionego przez nas filmu.

Praktycznie każdy z nas korzysta z menadżera pakietów apt lub też jego nakładki aptitude . Operowanie na debianie bez tych narzędzi raczej by nam nieco utrudniło życie. Sporo osób ogranicza się jedynie do podstawowych poleceń, typu update , upgrade czy dist-upgrade , pomijając przy tym całą konfigurację w/w narzędzi. W tym wpisie zostanie zaprezentowanych szereg opcji, które można zdefiniować na stałe w pliku konfiguracyjnym /etc/apt/apt.conf , tak by nie trzeba było ich ciągle wpisywać w terminalu ilekroć tylko korzystamy któregoś menadżera pakietów.

Na forum DUG'a znów został poruszony ciekawy wątek, tym razem odnośnie usunięcia całego środowiska graficznego z systemu. Pozornie niby nic nadzwyczajnego, przecie każdy z nas potrafi odinstalować szereg pakietów via apt czy aptitude . Problematyczne za to mogą się okazać zależne pakiety, które nie zostaną automatycznie usunięte wraz z konkretnym metapakietem od środowiska graficznego. Jak zatem usunąć te pozostałości?

Jak możemy przeczytać na wiki projektu GNOME, dconf to swojego rodzaju baza danych, która zawiera informacje o konfiguracji systemu w postaci klucz-wartość. Jak nie korzystam, co prawda, ze środowisk graficznych ale wykorzystuję w swoim linux'ie szereg ich elementów, które mogą działać z powodzeniem w okrojonym systemie, np. gnome-keyring . Część programów wykorzystuje tę bazę danych do przechowywania swoich ustawień, które możemy zmieniać via gsettings , gconf lub też dconf . Problem pojawia się po dłuższym czasie używania systemu, gdzie cześć z ustawień jest już przestarzała, np. w wyniku zaprzestania użytkowania jakiejś aplikacji. Przydałoby się zatem raz na jakiś czas oczyścić te bazę danych ze zbędnych wpisów i o tym będzie ten wpis.

Czytając sobie artykuł na temat TORyfikacji zapytań do serwerów kluczy GPG, pomyślałem, że w sumie mógłbym zreprodukować przedstawione tam kroki dotyczące implementacji tego rozwiązania na windowsie i wdrożyć je na linux'ie. Chodzi generalnie o to, by serwer kluczy GPG nie był odpytywany bezpośrednio przy szukaniu/przesyłaniu kluczy przez sieć, bo to może identyfikować nas, jak i grupę ludzi, która się z nami komunikuje. Jakby nie patrzeć, klucze GPG składają się z dość newralgicznych informacji, typu imię, nazwisko czy adres email, a serwer kluczy GPG tych danych w żaden sposób nie zabezpiecza i są one zwykle przesyłane otwartym tekstem przez sieć.

Jeśli korzystamy z serwera dźwięku PulseAudio na swoim linux'ie, prawdopodobnie zdarzyła nam się już sytuacja, w której chcieliśmy zablokować lub wygasić ekran monitora mając jednocześnie odpalony jakiś odtwarzacz muzyki. Gdy tylko ekran zostanie zablokowany, możemy odnotować brak dźwięku, bo ten zwyczajnie natychmiast zamiera. Za to po odblokowaniu ekranu, dźwięk wraca. Podobnie sprawa ma się przy przejściu z trybu graficznego (Xorg) na jedną z konsol TTY.