Projekt Sandbox2 bazuje na dobrze znanych i renomowanych technologiach, strukturze zasad oraz 2 procesach: wykonawcy piaskownicy i środowisku piaskownicy.
Wykorzystywane technologie
W sekcjach poniżej opisano technologie, które tworzą warstwę podstawową Sandbox2.
Przestrzenie nazw systemu Linux
Przestrzenie nazw systemu Linux stanowią próbę wirtualizacji na poziomie systemu operacyjnego. Chociaż wiele przestrzeni użytkownika działa z pozoru niezależnie, mają one jednakową instancję jądra. Sandbox2 używa tych rodzajów przestrzeni nazw:
- IPC
- Sieć (chyba że została wyłączona przez połączenie z numerem
PolicyBuilder::AllowUnrestrictedNetworking()) - Podłącz (za pomocą niestandardowego widoku drzewa systemu plików)
- Identyfikator zamówienia reklamowego
- Użytkownik (chyba że został wyraźnie wyłączony przez wywołanie
PolicyBuilder::AllowUnsafeKeepCapabilities()) - UTS
Więcej informacji o przestrzeniach nazw systemu Linux znajdziesz w Wikipedii i na powiązanej stronie man.
IPC
Tryb piaskownicy 2 umożliwia wymianę dowolnych danych między wykonawcą piaskownicy a niezaufanym użytkownikiem. Obsługuje wiadomości TLV, przekazując deskryptory plików i wymianę danych logowania za pomocą tokenów i nicków.
Seccomp-BPF
Sandbox2 korzysta z protokołu seccomp-bpf, który jest rozszerzeniem bezpiecznego przetwarzania danych (seccomp), które umożliwia używanie reguł BPF (Berkeley Packet Filter) do filtrowania wywołań syscall.
seccomp to usługa jądra systemu Linux, która ogranicza wywołania systemowe procesu tak, aby zezwalały tylko na exit, sigreturn, read i write. Jeśli proces spróbuje wykonać inne wywołanie syscall, zostanie zakończony. Rozszerzenie seccomp-bpf daje większą elastyczność niż seccomp. Zamiast zezwalać na stały zestaw wywołań syscall, seccomp-bpf uruchamia program BPF na danych syscall i w zależności od wartości zwracanej przez program może wykonać wywołanie syscall, pominąć wywołanie syscall i zwrócić wartość fikcyjną, zakończyć proces, wygenerować sygnał lub powiadomić tracker.
Punktor
Wywołanie systemowe ptrace (śladu procesu) udostępnia funkcję, która umożliwia procesowi śledzenia obserwację i kontrolę wykonania procesu śledzenia. Po podłączeniu logu czasu proces ma pełną kontrolę nad logiem. Przeczytaj więcej o ptrace w Wikipedii lub na powiązanej stronie tego artykułu.
Zasady piaskownicy
Zasada piaskownicy jest najważniejszą częścią piaskownicy, ponieważ określa działania, które może ona wykonywać, a jakie nie. Zasada piaskownicy składa się z 2 części:
- Zasady dotyczące systemu Sycall
- Konfiguracja przestrzeni nazw
Domyślna zasada Syscall
Domyślna zasada blokuje wywołania Sys, które są zawsze niebezpieczne, i ma pierwszeństwo przed zasadą rozszerzoną podaną przez użytkownika.
Zasady dotyczące rozszerzonego systemu Syscall
Rozszerzoną zasadę dotyczącą połączeń syscall można utworzyć za pomocą naszej klasy PolicyBuilder. Ta klasa określa szereg reguł ułatwiających przeglądanie (np. AllowStaticStartup, AllowDynamicStartup, AllowOpen), których można użyć, aby zwiększyć czytelność zasad.
Jeśli chcesz jeszcze bardziej ograniczyć wywołania syscall lub wymagać bardziej złożonych reguł, możesz określić nieprzetworzone makra BPF za pomocą AddPolicyOnSyscall i AddPolicyOnSyscalls. Przykład crc4 korzysta z tego mechanizmu do ograniczania argumentów wywołań systemowych read, write i close.
Ogólnie rzecz biorąc, im bardziej restrykcyjne zasady dotyczące piaskownicy, tym lepiej, bo zasady będą ograniczać wykorzystanie luk w kodzie. Jeśli możesz dokładnie określić, które wywołania syscall i argumenty są wymagane do normalnego działania programu, każdy atakujący wykorzystujący lukę w wykonywaniu kodu również zostanie ograniczony do tych samych limitów.
Naprawdę ścisła zasada piaskownicy może odrzucać wszystkie wywołania syscalls oprócz odczytów i zapisów w standardowych deskryptorach plików wejściowych i wyjściowych W tej piaskownicy program może przyjąć dane wejściowe, przetworzyć je i zwrócić dane wyjściowe. Jeśli jednak proces próbuje wywołać inne wywołanie systemu, zostanie zakończony z powodu naruszenia zasad. Jeśli więc proces zostanie naruszony (uruchomienie kodu przez szkodliwego użytkownika), nie będzie miało nic bardziej niekorzystnego niż wynik błędu (którą nadal musi obsłużyć wykonawca i inni użytkownicy).
Konfiguracja przestrzeni nazw
Obiekt PolicyBuilder służy też do konfigurowania indywidualnego widoku systemu plików w piaskownicy. Na środowisko Sandboxee można zmapować pojedyncze pliki (AddFile / AddFileAt), całe katalogi (AddDirectory / AddDirectoryAt) oraz pamięć tymczasową (AddTmpfs). Dodatkowo pliku AddLibrariesForBinary można użyć do automatycznego mapowania wszystkich bibliotek potrzebnych do określonego dynamicznie połączonego pliku wykonywalnego.
Flagi wiersza poleceń
Każdą zasadę Sandbox2 można wyłączyć, podając jedną z poniższych flag wiersza poleceń. Flagi te są przeznaczone do celów testowych (np. podczas dopracowania zasad programu rozszerzonego programu).
--sandbox2_danger_danger_permit_all--sandbox2_danger_danger_permit_all_and_log
Wykonawca piaskownicy
Wykonawca piaskownicy to proces, który nie znajduje się w piaskownicy. To proces śledzenia ptrace, który łączy się z procesem Sandboxee (procesem śledzenia ptrace). Wykonawca piaskownicy konfiguruje i uruchamia też instancję Monitor, która śledzi użytkownika piaskownicy i dostarcza informacje o stanie.
W piaskownicy 2 dostępne są 3 tryby wykonywania: samodzielny, serwer rozwidlenia Sandbox2 i niestandardowy serwer rozwidlenia. Jeśli korzystasz z serwera rozwidlenia, obszar piaskownicy jest tworzony jako proces podrzędny wykonawcy piaskownicy. Poniżej znajdziesz szczegółowe omówienie tych trybów.
Piaskownica
Użytkownik piaskownicy to proces działający w ograniczonym środowisku piaskownicy, które zostało zdefiniowane w zasadach piaskownicy. Wykonawca piaskownicy wysyła zasadę do piaskownicy przez IPC. Następnie użytkownik piaskownicy stosuje zasadę. Każde naruszenie zasad spowoduje zakończenie procesu, chyba że zostanie ono skonfigurowane inaczej (patrz Zasady piaskownicy).