Polskie Forum Użytkowników Debiana

Witam, czy ktoś z was może jest rozeznany w kwestii sandboxingu oraz kontenerów w dystrybucjach opartych na Debianie?

Chodzi mi o izolację programów third-party od reszty systemu bez uruchamiania ich na wirtualnej maszynie.

Pasowałby mi QubesOS, ale właśnie przeszkadza mi jego model bezpieczeństwa, który jest właśnie oparty na maszynach wirtualnych oraz hiperwizorze, który może być celem ataku.

Zależy mi na zdecentralizowanym systemie bezpieczeństwa oparty na izolacji sesji oraz przydzielaniu uprawień i ograniczeń w celu uzyskania dostępu do poszczególnych modułów systemu lub sprowadzeniu ich do bezpiecznej strefy, która jest odseparowana w jak największym stopniu od reszty systemu.


(Dystrybucje oparte na kompozytorach Wayland nie są odporne na keyloggery oraz oprogramowanie szpiegowskie, ale pomimo tego rezygnacja za X11 na rzecz Wayland ogólnie zwiększa bezpieczeństwo systemu.)

W związku z tym mam trzy pytania:

1. W jaki sposób mogę zabezpieczyć system przed zainfekowanym oprogramowaniem, a dokładniej końmi trojańskimi?

(Zakładam, że większość osób nie ma czasu przeglądać kodu źródłowego pakietu oraz kompilować go przed jego instalacją.)

2. Czy istnieje lepsza alternatywa dla AppArmor oraz namespaces nie licząc rozwiązań takich jak QubesOS?

3. I jak mogę się dowiedzieć czy pakiety, które są dostarczane do mojej dystrybucji są bezpieczne? (Najlepiej przed, niż po fakcie.)

A SELinux próbowałeś?

SELinux wydaje mi się lepszym rozwiązaniem od AppArmor lub Smack, tym bardziej, że obsługuje zabezpieczenia wielopoziomowe (MLS).

https://access.redhat.com/documentation ... _guide/mls

Ale nie jestem pewien co do wystarczalności SELinux, chroot, cgroups, wystarczy, że zaktualizuje mi bibliotekę do zainfekowanej wersji a konfiguracja polityki bezpieczeństwa pozostanie tak sama.

SELinux nie przewiduje wszystkich sytuacji, a konfiguracje polityki dla bibliotek powinny być dynamiczne i nie ufać z góry, że plik, który jest dostarczany z zaufanego repozytorium jest bezpieczny.

Chyba, że coś pominąłem w czytaniu przewodnika SELinux.

Selinux wytnie ci działania niepożądane, jeśli biblioteka zmieni swoje działanie a nie zostało ono przewidziane to zostanie zablokowane. Będziesz sobie musiał sam zaktualizować politykę dla danej akcji.
Prosty przykład: centos z włączonym selinux, uruchomione apache, katalog /var/www/html jest dostępny bez problemu, ale /var/www2/html już nie pomimo, że apache jest skonfigurowany poprawnie i powinno śmigać.

Selinux wytnie ci działania niepożądane, jeśli biblioteka zmieni swoje działanie a nie zostało ono przewidziane to zostanie zablokowane.

Ok, czyli mogę skonfigurować politykę bezpieczeństwa SELinux w taki sposób, żeby proces x o niższym stopniu czułości nie mógł komunikować się żadnym sposobem komunikacji międzyprocesowej z procesem y o wyższym stopniu czułości?

Czyli jeśli piszesz własne rozwiązanie to musisz napisać do niego politykę selinux. Inaczej kontekst działania będzie blokowany.

Nadal nie jestem pewien czy dzięki SELinux jestem w stanie zablokować dostęp danemu procesowi do pamięci współdzielonej.

Wiem, że złośliwy proces nie będzie w stanie wykonać operacji zapisu lub odczytu plików na dysku, jeżeli nie jest do tego uprawniony.

A co do danych w pamięci RAM i wirtualnego systemu plików to nie mam 100% pewności że są chronione przed innymi procesami, nawet jak jest skonfigurowany SELinux.

Ale dziękuję za pomoc i wszystkim zdrowia życzę.