Najczęstsze pytania

Czy mogę używać wątków?

Tak, wątki są obsługiwane w Sandbox2.

Wszystkie wątki muszą być w piaskownicy

Ze względu na sposób działania systemu Linux zasada seccomp-bpf jest stosowana tylko do bieżącego wątku. Oznacza to, że zasada nie jest stosowana do innych istniejących wątków, ale przyszłe wątki będą ją dziedziczyć:

• Jeśli używasz Sandbox2 w pierwszym trybie w którym piaskownica jest włączana przed execve(), wszystkie wątki będą dziedziczyć zasadę i nie będzie żadnego problemu. Jest to preferowany tryb piaskownicy.
• Jeśli używasz drugiego trybu w którym wykonawca ma set_enable_sandbox_before_exec(false) a Sandboxee informuje wykonawcę, kiedy chce być w piaskownicy, za pomocą SandboxMeHere(), upewnij się, że filtr jest stosowany do wszystkich wątków. W przeciwnym razie istnieje ryzyko opuszczenia piaskownicy: złośliwy kod może przenieść się z wątku w piaskownicy do wątku poza nią.

Jak mam skompilować Sandboxee?

W porównaniu z wykonywalnym plikiem połączonym statycznie skompilowanie Sandboxee do a wykonywalnego pliku połączonego dynamicznie spowoduje znaczny wzrost liczby wywołań systemowych (np. open/openat, mmap, itp.), które trzeba dodać do listy dozwolonych. Wszystkie te dodatkowe wywołania systemowe są wymagane ze względu na wywołanie dynamicznego linkera w czasie działania w celu załadowania bibliotek współdzielonych.

Jeśli chodzi o Sandboxee połączone statycznie, to chociaż trzeba dodać do listy dozwolonych mniejszą liczbę wywołań systemowych, wiąże się to też z implikacjami dotyczącymi bezpieczeństwa. Zmniejsza się entropia sterty ASLR (z 30 bitów do 8 bitów), co ułatwia wykorzystanie luk w zabezpieczeniach.

Jest to dylemat, który można sprowadzić do:

• Dynamiczne: dobra sterta ASLR, potencjalnie trudniejsze do uzyskania początkowe wykonanie kodu ale kosztem mniej skutecznej zasady piaskownicy, z której potencjalnie łatwiej się wydostać.
• Statyczne: zła sterta ASLR, potencjalnie łatwiejsze do uzyskania początkowe wykonanie kodu ale bardziej skuteczna zasada piaskownicy, z której potencjalnie trudniej się wydostać.

W przeszłości pliki binarne połączone statycznie nie obsługiwały kodu niezależnego od pozycji (pie). Ponadto Bazel domyślnie dodawał pie. Aby móc zdefiniować ścisły filtr wywołań systemowych, trzeba było zastąpić wartość domyślną Bazela.

Kompilatory z biegiem lat uległy poprawie i obsługują teraz opcję static-pie. Dzięki tej opcji kompilator generuje kod niezależny od pozycji, ale w porównaniu z pie obejmuje on teraz też wszystkie biblioteki połączone statycznie. Z punktu widzenia bezpieczeństwa static-pie nadal zmniejsza entropię ASLR (z 30 bitów do 14 bitów), ale jest to poprawa w stosunku do poprzedniej sytuacji bez pie.

Bazel domyślnie dodaje pie, a statyczny jest z nim niezgodny. Rozważ użycie flagi opcji linkera, aby przekazać flagę linkera -static-pie do cc_binary reguły i zastąpić wartość domyślną:

  linkstatic = 1,
  linkopts=["-static-pie"],

Przykład tych opcji znajdziesz w statycznym przykładzie BUILD: static_bin.cc jest połączony statycznie z static-pie, co umożliwia stosowanie bardzo ścisłej zasady wywołań systemowych. Działa to też dobrze w przypadku piaskownicy plików binarnych innych firm.

Czy mogę umieścić w piaskownicy 32-bitowe pliki binarne x86?

Sandbox2 może umieścić w piaskownicy tylko tę samą architekturę, z którą został skompilowany.

Ponadto obsługa 32-bitowej architektury x86 została usunięta z Sandbox2. Jeśli spróbujesz użyć 64-bitowego wykonawcy x86 do umieszczenia w piaskownicy 32-bitowego pliku binarnego x86 lub 64-bitowego pliku binarnego x86 wykonującego 32-bitowe wywołania systemowe (za pomocą int 0x80), oba wygenerują naruszenie piaskownicy, które można zidentyfikować za pomocą etykiety architektury [X86-32].

Powodem tego zachowania jest to, że numery wywołań systemowych różnią się w zależności od architektury, a ponieważ zasada wywołań systemowych jest napisana w architekturze wykonawcy, zezwolenie na inną architekturę dla Sandboxee byłoby niebezpieczne. Mogłoby to bowiem prowadzić do zezwolenia na pozornie nieszkodliwe wywołanie systemowe, które w rzeczywistości oznacza inne, bardziej szkodliwe wywołanie systemowe, co mogłoby otworzyć piaskownicę na ucieczkę.

Czy istnieją jakieś limity liczby piaskownic, o które może poprosić proces wykonawcy?

W przypadku każdej instancji Sandboxee (nowego procesu utworzonego przez forkserver) tworzony jest nowy wątek. To właśnie w tym miejscu występuje ograniczenie.

Czy wykonawca może poprosić o utworzenie więcej niż 1 piaskownicy?

Nie. Istnieje relacja 1:1 – instancja wykonawcy przechowuje PID Sandboxee, zarządza instancją Comms do instancji piaskownicy itp.

Dlaczego w forkserver.cc pojawia się komunikat „Function not implemented” (Funkcja nie została zaimplementowana)?

Sandbox2 obsługuje tylko działanie w stosunkowo nowych jądrach. Obecnie jest to jądro 3.19, ale w przyszłości może się to zmienić. Powodem jest to, że używamy stosunkowo nowych funkcji jądra, w tym przestrzeni nazw użytkowników i seccomp z flagą TSYNC.

Jeśli używasz wersji produkcyjnej, nie powinno to stanowić problemu, ponieważ prawie cała flota korzysta z wystarczająco nowego jądra. Jeśli masz z tym jakieś problemy, skontaktuj się z nami.

Jeśli używasz Debiana lub Ubuntu, aktualizacja jądra jest tak prosta jak uruchomienie:

sudo apt-get install linux-image-<RECENT_VERSION>