Programy ładujące systemu Linux obsługujące pełne szyfrowanie dysku?

Czy są jakieś programy ładujące Linuksa obsługujące pełne szyfrowanie dysku (a la TrueCrypt ). Wiem, że pracowano nad dodaniem obsługi szyfrowania do GRUB2, ale nie wydaje się to jeszcze gotowe. Jakieś inne opcje?

(Pamiętaj, że naprawdę mam na myśli tutaj pełne szyfrowanie dysku - w tym /boot)

Większość odpowiedzi opisuje konfigurację, w której /bootnie jest szyfrowany, a niektóre z nich próbują wyjaśnić, dlaczego niezaszyfrowane /bootpowinno być OK.

Nie wdając się w dyskusję na temat tego, dlaczego tak naprawdę potrzebuję / boot do szyfrowania, oto artykuł, który dokładnie opisuje to, czego potrzebuję, w oparciu o zmodyfikowaną wersję GRUB2:

• http://xercestech.com/full-system-encryption-for-linux.geek

Problem polega na tym, że te modyfikacje najwyraźniej nie są obsługiwane w obecnej bazie kodu GRUB2 (a może coś przeoczam).

Myślę, że obecna wersja GRUB2 nie obsługuje sama ładowania i deszyfrowania partycji LUKS (zawiera kilka szyfrów, ale myślę, że są one używane tylko do obsługi hasła). Nie mogę sprawdzić eksperymentalnej gałęzi programistycznej, ale na stronie GRUB znajduje się kilka wskazówek, że planowane są prace nad wdrożeniem tego, co chcesz zrobić.

Aktualizacja (2015) : najnowsza wersja GRUB2 (2.00) zawiera już kod dostępu do partycji zaszyfrowanych LUKS i GELI. (Link do strony xercestch.com podany przez OP wspomniał o pierwszych łatach, ale są one teraz zintegrowane z najnowszą wersją).

Jeśli jednak próbujesz zaszyfrować cały dysk ze względów bezpieczeństwa, pamiętaj, że niezaszyfrowany moduł ładujący (taki jak TrueCrypt, BitLocker lub zmodyfikowany GRUB) oferuje nie więcej ochrony niż niezaszyfrowana /bootpartycja (jak zauważył JV w komentarzu powyżej) . Każdy, kto ma fizyczny dostęp do komputera, może równie łatwo zastąpić go niestandardową wersją. Jest to nawet wspomniane w artykule na stronie xercestech.com, który podłączyłeś:

Dla jasności, w żaden sposób nie zmniejsza to odporności systemu na atak offline, jeśli osoba atakująca zastąpi program ładujący własnym programem lub przekieruje proces rozruchu w celu uruchomienia własnego kodu, system nadal może zostać zagrożony.

Należy pamiętać, że wszystkie produkty programowe do pełnego szyfrowania dysku mają tę słabość, bez względu na to, czy używają niezaszyfrowanego modułu ładującego rozruchu, czy niezaszyfrowanej partycji rozruchowej / przedbootowej. Nawet produkty obsługujące układy TPM (Trusted Platform Module), takie jak BitLocker, można zrootować bez modyfikowania sprzętu.

Lepszym podejściem byłoby:

1. odszyfrować na poziomie systemu BIOS (w płycie głównej lub na dysku lub w sprzęcie zewnętrznym [karta inteligentna], z układem TPM lub bez), lub
2. przenieś kod PBA (autoryzacja przed uruchomieniem) ( /bootw tym przypadku partycję) na urządzenie wymienne (takie jak karta inteligentna lub pamięć USB).

Aby to zrobić w drugi sposób, możesz sprawdzić projekt Linux Full Disk Encryption (LFDE) na stronie: http://lfde.org/, który zawiera skrypt poinstalacyjny do przeniesienia /bootpartycji na zewnętrzny dysk USB, szyfrując klucz za pomocą GPG i przechowywanie go również w pamięci USB. W ten sposób słabsza część ścieżki rozruchowej (niezaszyfrowana /bootpartycja) jest zawsze przy Tobie (tylko Ty będziesz mieć fizyczny dostęp do odszyfrowującego kodu ORAZ klucza). ( Uwaga : ta witryna została utracona, a blog autora również zniknął, jednak stare pliki można znaleźć na stronie https://github.com/mv-code/lfde. Uwaga: ostatnie opracowanie zostało zrobione 6 lat temu). Jako lżejszą alternatywę można zainstalować niezaszyfrowaną partycję rozruchową w pamięci USB podczas instalacji systemu operacyjnego.

Pozdrawiam, MV

Sprawdź, czy początkowy dysk RAM i folder / boot nie używają szyfrowania.

Spowoduje to uruchomienie „minimalnego” jądra ze sterownikami i obsługą do przełączania się na „rzeczywisty” główny system plików, który jest zaszyfrowany.

Zanim zaczniesz twierdzić, że to „włamanie” - pamiętaj - większość (jeśli nie wszystkie) dystrybucje Linuksa uruchamiają się dzisiaj w ten sposób. Pozwala to jawnie uruchomić system i załadować główny system FS przy użyciu modułów, które należy załadować z systemu plików. (Rodzaj problemu z kurczakiem i jajkami). Na przykład, jeśli główny system plików znajdował się na sprzętowym woluminie RAID i trzeba było załadować jego sterownik, zanim będzie można zamontować główny FS.

Przejrzałem link, który opublikowałeś - chociaż nie ma partycji rozruchowej, na dysku twardym nadal znajduje się niezaszyfrowany moduł ładujący, do którego można uzyskać dostęp i zaatakować go przy użyciu ataku złej pokojówki. Przyglądałem się podobnej konfiguracji, w której nie ma niezaszyfrowanych danych na dysku twardym, ale jak dotąd wymyśliłem tylko uruchamianie programu ładującego z dysku wymiennego.

Sądzę, że większość z nich robi to, czego potrzebujesz, to przede wszystkim instrukcja instalacji systemu operacyjnego z zaszyfrowanym HD.

Ubuntu ma ładną stronę z instrukcjami tworzenia zaszyfrowanych partycji, LMVP, folderów itp., Po prostu google swoją wersję dystrybucji tego ...

Nie, myślę, że nie ma.

Czy naprawdę potrzebujesz szyfrować / uruchamiać? Nie podejrzewam Reszta systemu plików może być zaszyfrowana przez normalne oprogramowanie Linux, które znajduje się na initramfs w / boot i odpowiednio monituje użytkownika.

Wygląda na to, że prosisz o coś, co jest niemożliwe, i porównujesz to z rozwiązaniem Windows, które ukrywa przed tobą implementację, ale w rzeczywistości robi to samo, co Linux.

Najbliższym rozwiązaniem, jakie mogę wymyślić, jest użycie dysku twardego, który implementuje hasło bezpieczeństwa i szyfrowanie. Niektóre laptopy Thinkpad korzystają z tych rozwiązań sprzętowych.

Odpowiedź jest podana w artykule. „Jest to teraz możliwe dzięki rozszerzeniom programu ładującego GRUB2 nowej generacji, który został załatany, aby obsługiwać nie tylko” i „chcemy później zainstalować nasz nowy obraz grub2 z obsługą Luksa” oraz „Teraz kompilujemy źródło GRUB2 z włączoną obsługą LUKS. „ Wygląda na to, że istnieje łatka lub rozszerzenie, które musisz uzyskać i dołączyć do GRUB2, lub rozwidlone źródło GRUB2.

Grub2 w wersji 2.02 ~ beta3 potrafi wiele rzeczy, których nie może zrobić Grub2 w wersji 2.02 ~ beta2, przetestowane przeze mnie:

1. Uruchom przy użyciu dysku Super Grub 2
2. Wpisz „c”, aby przejść do wiersza poleceń
3. Wpisz polecenia, aby zamontować zaszyfrowaną partycję, którą chcę
   • insmod luks
   • cryptomount (hd0, #) // gdzie # oznacza zaszyfrowaną partycję
4. Wpisz hasło i wpisz więcej poleceń
   • multiboot (crypto0) /grub/i386-pc/core.img
   • bagażnik

Spowoduje to załadowanie kolejnego Grub2, który znajduje się w zaszyfrowanej partycji, szalony atak zła nie ma tu miejsca ... Rozruchuję z płyty CD (tylko do odczytu), a następnie montuję zaszyfrowaną partycję (bez hasła, jak śmie ktoś może wstrzyknąć cokolwiek!), a następnie uruchamia się z zaszyfrowanej partycji i ładuje Grub2 z własnym menu itp.

Uwaga: taki rozruch Grub 2.02 ~ beta3 (używam płyty Super Grub 2 cd) może znajdować się na pamięci USB, dysku twardym USB itp.

Ostrzeżenie: Grub2 w wersji 2.02 ~ beta2 nie może zrobić tego samego, ponieważ ma kilka błędów (które wydają się być naprawione w wersji Grub2 2.02 ~ beta3) związanych z cryptomount ...

Błędy beta2, o których mówię, to:

1. Tak naprawdę nie montuje zaszyfrowanej partycji, więc nie pozwala na dostęp (crypto0) / *
2. Jeśli istnieje więcej niż jedna zaszyfrowana partycja, użycie cryptomount -atylko poprosi o jedno hasło
3. Po jednorazowym uruchomieniu cryptomount jest ponownie uruchamiany, nic nie robi

w wersji beta 3:

1. Naprawdę montuje zaszyfrowaną partycję i umożliwia dostęp do plików przez (crypto0) / * lub (crypto1) / * itd., Jeśli więcej niż jedna jest zamontowana w tym samym czasie
2. Pyta o każde hasło (po jednym na zaszyfrowaną partycję)
3. Pozwala uruchomić go tyle razy, ile potrzebujesz, możesz zamontować jeden, a potem drugi itd.

Uwaga dodatkowa: Nie zastanawiałem się, jak je odmontować, oprócz ponownego uruchomienia lub uruchomienia innego lub tego samego programu ładującego grub2 / other itp.

Mam nadzieję, że to pomoże w wyjaśnieniu rzeczy i mam nadzieję, że Grub2 w wersji 2.02 ~ beta3 zostanie zintegrowany z LiveCD, dzięki czemu będziemy mogli go zainstalować bez konieczności samodzielnej kompilacji.

PD: Z dyskiem Super Grub 2 nie widzę żadnego sposobu na zainstalowanie Grub2 w wersji 2.02 ~ beta3 na partycji MBR / boot itp.