Architektura Sandbox2 opiera się na znanych i sprawdzonych technologiach, ramach zasad oraz 2 procesach: Sandbox Executor i Sandboxee.
Technologie
W sekcjach poniżej znajdziesz informacje o technologiach, które stanowią warstwę podstawową Sandbox2.
Przestrzenie nazw w systemie Linux
Przestrzenie nazw w systemie Linux to próba zapewnienia wirtualizacji na poziomie systemu operacyjnego. Chociaż wiele przestrzeni użytkownika działa pozornie niezależnie od siebie, korzystają one z jednego jądra. Sandbox2 korzysta z tych rodzajów przestrzeni nazw:
- IPC
- Sieć (chyba że została wyraźnie wyłączona przez wywołanie funkcji
PolicyBuilder::AllowUnrestrictedNetworking()) - Montowanie (przy użyciu widoku niestandardowego drzewa systemu plików)
- Identyfikator zamówienia reklamowego
- Użytkownik
- UTS
Więcej informacji o przestrzeniach nazw w systemie Linux znajdziesz w Wikipedii lub na odpowiedniej stronie podręcznika.
IPC
Sandbox2 umożliwia wymianę dowolnych danych między wykonawcą piaskownicy a niezaufanym procesem piaskownicy. Obsługuje wiadomości typu Długość-Typ-Wartość (TLV), przekazywanie deskryptorów plików oraz wymianę danych logowania za pomocą tokenów i uchwytów.
Seccomp-BPF
Sandbox2 korzysta z seccomp-bpf, czyli rozszerzenia trybu bezpiecznego obliczania (seccomp), które umożliwia filtrowanie wywołań systemowych za pomocą reguł Berkeley Packet Filter (BPF).
seccomp to funkcja jądra systemu Linux, która ogranicza wywołania systemowe procesu, aby zezwalać tylko na exit, sigreturn, read i write. Jeśli proces spróbuje wykonać inne wywołanie systemowe, zostanie zakończony. Rozszerzenie seccomp-bpf zapewnia większą elastyczność niż seccomp. Zamiast zezwalać na stały zestaw wywołań systemowych, seccomp-bpf uruchamia program BPF na danych wywołania systemowego i w zależności od zwracanej przez program wartości może wykonać wywołanie systemowe, pominąć je i zwrócić wartość zastępczą, zakończyć proces, wygenerować sygnał lub powiadomić narzędzie śledzące.
Ptrace
Wywołanie systemowe ptrace (śledzenie procesu) udostępnia funkcję, która umożliwia procesowi śledzącemu obserwowanie i kontrolowanie wykonywania procesu śledzonego. Po dołączeniu proces śledzący ma pełną kontrolę nad procesem śledzonym. Więcej informacji o ptrace znajdziesz w Wikipedii lub na odpowiedniej stronie podręcznika.
Zasady dotyczące piaskownicy
Zasady dotyczące piaskownicy są najważniejszą częścią piaskownicy, ponieważ określają działania, które proces w piaskownicy może i nie może wykonywać. Zasady piaskownicy składają się z 2 części:
- Zasady wywołań systemowych
- Konfigurowanie przestrzeni nazw
Domyślne zasady wywołań systemowych
Domyślne zasady blokują wywołania systemowe, które są zawsze niebezpieczne, i mają pierwszeństwo przed rozszerzonymi zasadami dostarczonymi przez użytkownika.
Rozszerzone zasady wywołań systemowych
Rozszerzoną zasadę dotyczącą wywołań systemowych można utworzyć za pomocą klasy PolicyBuilder. Ta klasa definiuje szereg reguł ułatwiających korzystanie z zasad (np. AllowStaticStartup, AllowDynamicStartup, AllowOpen), które mogą poprawić czytelność zasad.
Jeśli chcesz dodatkowo ograniczyć wywołania systemowe lub wymagać bardziej złożonych reguł, możesz określić surowe makra BPF za pomocą znaków AddPolicyOnSyscall i AddPolicyOnSyscalls. Przykład crc4 wykorzystuje ten mechanizm do ograniczania argumentów wywołań systemowych read, write i close.
Ogólnie im bardziej rygorystyczne są zasady Sandbox, tym lepiej, ponieważ wykorzystanie wszelkich luk w kodzie będzie ograniczone przez te zasady. Jeśli możesz dokładnie określić, które wywołania systemowe i argumenty są wymagane do prawidłowego działania programu, każdy atakujący wykorzystujący lukę w zabezpieczeniach umożliwiającą wykonanie kodu będzie również podlegać tym samym ograniczeniom.
Bardzo restrykcyjna zasada piaskownicy może odrzucać wszystkie wywołania systemowe z wyjątkiem odczytu i zapisu w deskryptorach plików standardowego wejścia i wyjścia. W tym środowisku testowym program może przyjmować dane wejściowe, przetwarzać je i zwracać dane wyjściowe. Jeśli jednak proces spróbuje wykonać inne wywołanie systemowe, zostanie zakończony z powodu naruszenia zasad. Dlatego jeśli proces zostanie naruszony (wykonanie kodu przez złośliwego użytkownika), nie może on zrobić niczego bardziej szkodliwego niż wygenerowanie nieprawidłowych danych wyjściowych (które wykonawca i inne osoby nadal muszą prawidłowo obsłużyć).
Konfiguracja przestrzeni nazw
Obiekt PolicyBuilder służy też do konfigurowania indywidualnego widoku systemu plików przez Sandboxee. Pojedyncze pliki (AddFile / AddFileAt), całe katalogi (AddDirectory / AddDirectoryAt) oraz pamięć tymczasowa (AddTmpfs) można mapować w środowisku Sandboxee. Dodatkowo narzędzie
AddLibrariesForBinary może automatycznie mapować wszystkie biblioteki
potrzebne do określonego wykonywalnego pliku połączonego dynamicznie.
Flagi wiersza poleceń
Każdą zasadę Sandbox2 można wyłączyć, podając jedną z tych flag wiersza poleceń. Te flagi są przeznaczone do celów testowych (np. podczas dopracowywania rozszerzonych zasad wywołań systemowych).
--sandbox2_danger_danger_permit_all--sandbox2_danger_danger_permit_all_and_log
Wykonawca piaskownicy
SandboxExecutor to proces, który sam nie jest objęty piaskownicą. Jest to proces śledzący ptrace, który dołącza do Sandboxee (proces śledzony ptrace). Wykonawca piaskownicy konfiguruje też i uruchamia instancję Monitora, która śledzi proces Sandboxee i dostarcza informacje o stanie.
Sandbox2 umożliwia 3 tryby wykonywania: samodzielny, serwer rozwidlenia Sandbox2 i niestandardowy serwer rozwidlenia. Jeśli używasz serwera fork, proces Sandboxee jest tworzony jako proces podrzędny procesu Sandbox Executor. Te tryby są szczegółowo opisane tutaj.
Sandboxee
Proces umieszczony w piaskownicy to proces, który działa w ograniczonym środowisku piaskownicy zdefiniowanym przez zasady piaskownicy. Proces Sandbox Executor wysyła zasady do procesu Sandboxee za pomocą komunikacji IPC. Sandboxee następnie stosuje zasadę. Każde naruszenie zasad spowoduje zakończenie procesu, chyba że skonfigurujesz go inaczej (patrz Zasady dotyczące piaskownicy).