Firma przedstawiła do dyskusji na liście mailingowej programistów jądra Linux kod modułu LSM z implementacją mechanizmu IPE (Integrity Policy Enforcement), rozszerzającego istniejące systemy zarządzania dostępem na podstawie uprawnień. Zamiast powiązania z etykietami i ścieżkami, w IPE decyzja o zezwoleniu lub zakazie operacji podejmowana jest na podstawie stałych właściwości komponentu systemowego, z którym operacja jest wykonywana. Moduł umożliwia określenie ogólnej polityki zapewnienia integralności dla całego systemu, wskazując, jakie operacje są dozwolone i w jaki sposób należy weryfikować autentyczność komponentów.
IPE ma na celu stworzenie w pełni weryfikowalnych systemów, których integralność jest potwierdzona od początkowego bootloadera i jądra do końcowych plików wykonywalnych, konfiguracji i plików ładujących. Na przykład, za pomocą IPE można wskazać, które pliki wykonywalne można uruchamiać, z uwzględnieniem weryfikacji ich zgodności z wzorcową wersją, przy użyciu kryptograficznych skrótów dostarczanych przez system dm-verity. W przypadku zmiany lub podmiany pliku, IPE może zablokować operację lub zarejestrować fakt naruszenia integralności.
Proponowany mechanizm może być stosowany w oprogramowaniu układowym dla urządzeń wbudowanych, w których całe oprogramowanie i ustawienia są specjalnie kompilowane i dostarczane przez właściciela. Na przykład, w centrach danych Microsoft IPE jest stosowane w sprzęcie do firewalli. W przeciwieństwie do innych systemów weryfikacji integralności, takich jak IMA, IPE odznacza się niezależnością od metadanych w systemie plików — wszystkie właściwości definiujące dopuszczalność operacji są przechowywane bezpośrednio w jądrze.
Reguły są definiowane w formie tekstowej przy użyciu zestawów klucz-wartość. Podstawowe to klucz „op”, określający operację, do której stosuje się regułę (na przykład, op=EXECUTE zadziała przy próbie wykonania), oraz „action”, określający działanie (na przykład, „action=DENY” w celu zablokowania). Reguły są powiązane z właściwościami dostarczanymi przez zewnętrzne podsystemy, takie jak dm-verity i fs-verity.
Na przykład, zasady op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY zezwalają tylko na ładowanie z zweryfikowanej partycji, zabraniają uruchamiania plików z partycji bez podpisów w dm-verity, a także selektywnie zabraniają wykonania pliku o hashu „401fce…0dec146938”.
Początkowy zestaw zasad rozruchowych jest określany za pomocą ustawienia SECURITY_IPE_BOOT_POLICY i jest zawierany w składzie jądra, a pozostałe zasady są dodawane w razie potrzeby przez plik /sys/kernel/security/ipe/new_policy. Przekazywane zasady są szyfrowane przy użyciu certyfikatu określonego w SYSTEM_TRUSTED_KEYRING.
Na systemach ogólnego przeznaczenia zaleca się stosowanie IPE w połączeniu z mechanizmem DIGLIM, rozwijanym przez firmę Huawei. DIGLIM jest realizowany za pomocą eBPF i pozwala łatwo wdrożyć kontrolę integralności na poziomie pojedynczych plików w standardowych dystrybucjach, nie wymagając ich przeróbki (przedstawiane jako opcja Secure Boot, działająca na poziomie aplikacji). Istota DIGLIM polega na utrzymywaniu puli weryfikacyjnych hashy dla plików i metadanych oraz udostępnianiu dostępu do plików wykonywalnych tylko wtedy, gdy ich hash znajduje się w puli. Lista hashy może być uzyskana od menedżera pakietów RPM lub ręcznie wygenerowana przez użytkownika.
Źródło: opennet.ru
