Jednym z możliwych sposobów, choć w praktyce zajęłoby to wyjątkowo dużo czasu, byłoby powrót do korzeni. Rozwój GNU rozpoczął się w 1984 roku, a oryginalna wersja Minix (która była używana podczas wczesnego rozwoju Linuksa do celów ładowania systemu) została wydana w 1987 roku.
Cała odpowiedź opiera się na założeniu, że „[ty] lub inne osoby potrafią odczytać i zrozumieć kod źródłowy pod kątem błędów bezpieczeństwa, więc kod źródłowy zostanie sprawdzony przed kompilacją” i że można ufać wynikowi takiej analizy . Bez tego odpowiedź ta jest prawdopodobnie gorsza niż bezwartościowa, ponieważ będziesz spędzać ogromną ilość czasu bez żadnej korzyści.
Jeśli możesz znaleźć kopię oryginalnej książki Minix z kodem źródłowym, możesz ją wpisać z książki. Skompiluj go, a następnie użyj innego dekompilatora w innym systemie, aby sprawdzić, czy kompilator generuje oczekiwane wyjście binarne języka maszynowego. (Kod jest tylko 12000 linie, przypuszczalnie C, Czyniąc tak jest czasochłonne, ale nadal w powodu jeśli myślisz poważnie o takim projekcie). Można nawet napisać własny dezasembler; to nie powinno być bardzo trudne.
Chwyć najstarsze wersje narzędzi GNU, które możesz zdobyć (ponieważ prawdopodobnie mają mniej kodu i mniej zależności od bibliotek zewnętrznych), przejrzyj kod, skompiluj go dla Minix (może to jednak trochę potrwać; absolutnie chcę tego uniknąć, wprowadzając poprawki do kodu źródłowego, ponieważ spowoduje to, że dodawanie łat później będzie bardzo podatne na błędy) i przejdzie podobny cykl deasemblacji-weryfikacji dla narzędzi GNU. W tym momencie ufasz systemowi operacyjnemu i zestawowi narzędzi, więc musisz tylko przejrzeć kod źródłowy w zestawie poprawek (wszystko, co nie znajduje się w zestawie poprawek, jest już zaufane), ale narzędzia będą nadal bardzo prymitywne i surowe w porównaniu do tego, czego używasz do dzisiaj. Nie spodziewaj się na przykład niczego więcej niż najbardziej podstawowej funkcjonalności narzędzi systemowych.Przeczytaj wiele XKCD.
W pewnym momencie będziesz mieć system, który może kompilować i ładować wczesną wersję jądra Linux, podobnie jak na początku lat 90., gdy Linux zaczął zyskiwać na popularności wśród hakerów. Sugerowałbym migrację do Linuksa w tym momencie (przebuduj biblioteki systemowe i zestaw narzędzi na Linuksa, zbuduj jądro Linuksa, uruchom system Linux i ewentualnie przebuduj jądro Linuksa i łańcuch narzędzi GNU w Linuksie; ostatni pokazuje, że system jest teraz samodzielny hosting), ale to w dużej mierze zależy od Ciebie. Kontynuuj sprawdzanie poprawek, łatanie jądra, bibliotek i podstawowych narzędzi GNU oraz przebudowywanie, aż przejdziesz do nowoczesnych wersji.
Wtedy masz zaufany podstawowy system operacyjny i kompilator, którego można użyć do budowy nowoczesnego oprogramowania. Do tego czasu możesz śledzić np. Przewodniki Linux From Scratch, aby zbudować system zdolny do wykonywania użytecznych zadań.
W żadnym momencie system „kompilatora” nie może być w żaden sposób podłączony do sieci (w tym jako maszyna wirtualna na hoście w sieci); ryzykujesz penetrację dowolnego komponentu sieciowego, w tym jądra. Jeśli martwisz się atakiem kompilatora Thompson , musisz spodziewać się, że dowolny host maszyny wirtualnej również może zostać zagrożony. Użyj sneakernet, aby pobrać kod źródłowy i pliki binarne z fizycznego hosta, na którym kompilujesz. Spodziewaj się problemów z włączaniem i wyłączaniem plików co najmniej zanim dojdziesz do punktu, w którym zaimplementowano obsługę pamięci masowej USB. Jeśli jesteś naprawdę paranoikiem, wykazy kodów źródłowych druk i wpisać je ręcznie (i mam nadzieję, że sterownik drukarki i drukarka nie mają podobny kod w nich) lub odczytaj kod na jednym monitorze komputera i wpisz go na innym komputerze fizycznie obok, ale nie podłączonego do niego.
Tak, zajmie to dużo czasu. Jednak zaletą tego podejścia jest to, że każdy krok ma charakter przyrostowy, co oznacza, że o wiele trudniej będzie się przedostać przez szkodliwe oprogramowanie, o ile nie będzie on stopniowo wprowadzany przez wiele wersji; Dzieje się tak, ponieważ zestaw zmian na każdym etapie jest stosunkowo niewielki, a zatem znacznie łatwiejszy do przejrzenia. Porównaj zestaw poprawek z dziennikiem zmian i upewnij się, że możesz dokładnie określić, który wpis dziennika zmian odpowiada każdej zmianie w kodzie źródłowym. Ponownie zakłada to, że masz możliwość (prawdopodobnie przez kogoś, komu ufasz) sprawdzenia, czy takie zmiany nie zostały zakradzione w bazie kodu, ale powinno to doprowadzić cię tak blisko do zaufanego systemu, jak tylko oprogramowanie, z wyjątkiem… podejście oprogramowania układowego może.