Wykonanie potencjalnie szkodliwego programu w systemie Linux

Piszę program, który przetestuje programy napisane przez studentów. Obawiam się, że nie mogę im ufać i muszę się upewnić, że nie skończy się to źle na komputerze, na którym jest uruchomiony.

Zastanawiałem się nad stworzeniem jakiegoś użytkownika do testów zderzeniowych z ograniczonym dostępem do zasobów systemowych i uruchamiania programów jako ten użytkownik, ale z tego, co dotychczas znalazłem w sieci, stworzenie systemu wirtualnego byłoby najbezpieczniejszą opcją ...

Czy ktoś może mi pomóc w wyborze odpowiedniego podejścia? Bezpieczeństwo jest dla mnie bardzo ważne. Z drugiej strony nie chcę rozwiązania, które byłoby nadmierne i marnuje dużo czasu na próbę nauczenia się czegoś, czego tak naprawdę nie potrzebuję.

• Maszyna wirtualna może zapewnić najwyższe bezpieczeństwo bez ponownego uruchamiania, ale najniższą wydajność.

• Inna opcja, dla jeszcze większego bezpieczeństwa niż maszyna wirtualna: uruchom dysk CD / DVD / pendrive „na żywo” bez dostępu do dysku twardego (tymczasowo wyłącz dysk twardy w systemie BIOS; jeśli nie możesz, przynajmniej nie zamontuj napędu / odmontuj go, jeśli zostanie zamontowany automatycznie - ale jest to znacznie mniej bezpieczne)

• Doker pojemnik jest nieco mniej bezpieczna alternatywa dla pełnej maszynie wirtualnej. Prawdopodobnie zasadniczą różnicą (pod względem bezpieczeństwa) między tymi dwoma jest to, że systemy działające w oknie dokowanym faktycznie używają jądra systemu hosta.

• Istnieją programy takie jak isolate , które stworzą specjalne, bezpieczne środowisko - jest to ogólnie nazywane piaskownicą - zazwyczaj są oparte na chroot, z dodatkowym nadzorem - znajdź taki, który ci odpowiada.

• Prosty chroot będzie najmniej bezpieczny (szczególnie w odniesieniu do wykonywania programów), choć może trochę szybciej, ale ... Musisz zbudować / skopiować całe oddzielne drzewo root i użyć montowania powiązań dla /devitp. (Patrz Uwaga 1 poniżej!). Ogólnie rzecz biorąc, takie podejście nie może być zalecane, szczególnie jeśli można użyć bezpieczniejszego i często łatwiejszego do skonfigurowania sandboxśrodowiska.

Uwaga 0: Do aspektu „specjalnego użytkownika”, takiego jaknobodykonto: Daje to prawie żadne bezpieczeństwo, znacznie mniej niż nawet prostechroot. nobodyUżytkownik może nadal pliki i programy, które mają dostęp do odczytu i wykonywania uprawnień określonych dla innych . Możesz to przetestowaćsu -s /bin/sh -c 'some command' nobody. A jeśli masz jakikolwiek plik konfiguracji / historii / pamięci podręcznej dostępny dla każdego (przez pomyłkę lub drobną dziurę w zabezpieczeniach), program działający znobodyuprawnieniami może uzyskać do niego dostęp, grep dla poufnych danych (takich jak „pass =” itp.) I w na wiele sposobów wysyłaj je przez sieć lub cokolwiek innego.

Uwaga 1: Jak zauważył Gilles w komentarzu poniżej , proste środowisko chroot zapewni bardzo niewielkie bezpieczeństwo przed exploitami mającymi na celu zwiększenie uprawnień. Jedyny chroot ma sens pod względem bezpieczeństwa, tylko jeśli środowisko jest minimalne, składa się tylko z programów o potwierdzonym bezpieczeństwie(ale nadal istnieje ryzyko wykorzystania potencjalnych luk w zabezpieczeniach jądra), a wszystkie niezaufane programy działające w chroot są uruchomione jako użytkownik, który nie uruchamia żadnego procesu poza chroot. Tym, co zapobiega chroot (z wymienionymi tu ograniczeniami), jest bezpośrednia penetracja systemu bez eskalacji uprawnień. Jednak, jak zauważył Gilles w innym komentarzu, nawet ten poziom bezpieczeństwa może zostać ominięty, umożliwiając programowi wyłamanie się z chroot.

Użyj maszyny wirtualnej. Nic mniej nie zapewnia większego bezpieczeństwa.

Kilka lat temu mogłem zasugerować chrootowanego dedykowanego użytkownika lub coś takiego. Ale sprzęt stał się bardziej wydajny, a oprogramowanie maszyny wirtualnej stało się łatwiejsze w użyciu. Co więcej, gotowe ataki stały się bardziej wyrafinowane. Nie ma już powodu, aby nie iść tutaj całą drogą.

Poleciłbym uruchomić VirtualBox. Możesz skonfigurować maszynę wirtualną w ciągu kilku minut, a następnie zainstalować w niej dystrybucję Linuksa. Jedyną inną niż domyślną konfiguracją, którą zalecam, jest konfiguracja sieciowa: utwórz zarówno interfejs „NAT” (do komunikacji ze światem), jak i interfejs „tylko host” (abyś mógł łatwo kopiować pliki do iz hosta oraz ssh do VM). Wyłącz interfejs NAT podczas uruchamiania programów uczniów¹; włącz to tylko podczas instalowania lub aktualizowania pakietów oprogramowania.

W maszynie wirtualnej utwórz jednego użytkownika na jednego ucznia.

¹ _{Interfejs NAT można ograniczyć do białej listy użytkowników, ale jest to bardziej zaawansowane niż potrzebujesz w prostej, konkretnej konfiguracji.}

tutaj znajduje się bardzo dokładne wyjaśnienie, dlaczego używanie Chroota jest nadal bardzo opłacalną opcją i dlaczego pełna wirtualizacja systemu operacyjnego lub sprzętu jest szczególnie nadmierna w określonych scenariuszach.

to tylko mit, że Chroot nie jest zabezpieczeniem. istnieją narzędzia, które automatycznie zbudują system plików chroot, a Chroot jest wbudowany w wiele popularnych aplikacji jako celowa funkcja bezpieczeństwa.

wbrew powszechnemu przekonaniu, nie każda sytuacja wymaga pełnej wirtualizacji systemu operacyjnego lub pełnej symulacji sprzętu. może to w rzeczywistości oznaczać posiadanie większej powierzchni ataku do pokrycia. z kolei oznacza mniej bezpieczny system . (rzekomo dla mniej znających administratorów systemu)

zasady są dość proste: nie wkładaj do chroota niczego, co nie jest konieczne. nie uruchamiaj demona jako root. nie uruchamiaj demona, jak każdy użytkownik uruchamiający demona poza chroot.

usuń wszelkie niebezpieczne aplikacje, pliki binarne setuid, zwisające dowiązania symboliczne / dowiązania twarde bez właściciela. podłącz ponownie niepotrzebne foldery, używając nosuid, noexec i nodev. zbuduj najnowszą stabilną wersję działającego demona ze źródła. a przede wszystkim zabezpiecz system podstawowy!

Dodam to, długo po oficjalnej odpowiedzi na pytanie: MAGIA: Złośliwe starzenie się w obwodach / rdzeniach , które niestety jest zamknięte za zaporą sieciową ACM. Rezultatem pracy jest to, że ślady o bardzo małej szerokości w używanych obecnie obwodach starzeją się podczas użytkowania i ostatecznie ulegają rozpadowi. Po znalezieniu prawidłowych instrukcji i powtarzaniu ich w kółko atakujący może szybko zestarzeć układy scalone.

Żadna z maszyn wirtualnych, piaskownic, kontenerów lub więzień chroot nie zapobiegłaby tego rodzaju złośliwemu zniszczeniu sprzętu. Autorzy artykułu znaleźli takie sekwencje instrukcji i eksperymentalnie postarzali sprzęt do awarii, ale nie rozdawali instrukcji, więc przez pewien czas może to nie być realnym zagrożeniem.

W uniksach pochodzących z BSD (w tym Mac OS X) istnieje funkcja o nazwie sandbox. Strona podręcznika mówi

OPIS
Funkcja piaskownicy pozwala aplikacjom na dobrowolne ograniczenie dostępu do zasobów systemu operacyjnego. Ten mechanizm bezpieczeństwa ma na celu ograniczenie potencjalnych szkód w przypadku wykorzystania luki w zabezpieczeniach. Nie zastępuje innych kontroli dostępu do systemu operacyjnego.

Jest to oddzielne od chrootobiektu, który jest również dostępny.