자주 묻는 질문(FAQ)

스레드를 사용할 수 있나요?

예, 스레드는 Sandbox2에서 지원됩니다.

모든 스레드는 샌드박스 처리되어야 함

Linux의 작동 방식 때문에 seccomp-bpf 정책은 현재 스레드에만 적용됩니다. 즉, 정책이 다른 기존 스레드에는 적용되지 않지만 향후 스레드는 정책을 상속합니다.

• `execve()` 전에 샌드박스 처리가 사용 설정된 first mode 에서 Sandbox2를 사용하는 경우 모든 스레드가 정책을 상속하며 문제가 없습니다.execve() 이 모드는 샌드박스 처리의 기본 모드입니다.
• 실행기에 set_enable_sandbox_before_exec(false)가 있고 Sandboxee가 SandboxMeHere()를 사용하여 샌드박스 처리할 시점을 실행기에 알리는 두 번째 모드 를 사용하는 경우 필터가 모든 스레드에 적용되는지 확인합니다. 그렇지 않으면 샌드박스 이스케이프 위험이 있습니다. 악성 코드가 샌드박스 처리된 스레드에서 샌드박스 처리되지 않은 스레드로 이전될 수 있습니다.

Sandboxee를 컴파일하려면 어떻게 해야 하나요?

정적으로 연결된 실행 파일과 비교할 때 sandboxee를 동적으로 연결된 실행 파일로 컴파일하면 허용 목록에 추가해야 하는 syscall (예: open/openat, mmap 등)이 크게 증가합니다. 이러한 추가 syscall은 런타임 시 공유 라이브러리를 로드하기 위한 동적 링커 호출로 인해 필요합니다.

하지만 정적으로 연결된 sandboxee를 살펴보면 허용 목록에 추가해야 하는 syscall은 적지만 보안에 미치는 영향도 있습니다. ASLR 힙 엔트로피가 30비트에서 8비트로 감소하여 익스플로잇이 더 쉬워집니다.

이는 다음과 같이 요약할 수 있는 딜레마입니다.

• 동적: 힙 ASLR이 양호하고 초기 코드 실행이 더 어려울 수 있지만 샌드박스 정책의 효과가 떨어지고 이스케이프가 더 쉬울 수 있습니다.
• 정적: 힙 ASLR이 좋지 않고 초기 코드 실행이 더 쉬울 수 있지만 샌드박스 정책이 더 효과적이고 이스케이프가 더 어려울 수 있습니다.

이전에는 정적으로 연결된 바이너리가 위치 독립 코드 (pie)를 지원하지 않았습니다. 또한 Bazel은 기본적으로 pie를 추가했습니다. 엄격한 syscall 필터를 정의하려면 Bazel의 기본값을 덮어써야 했습니다.

컴파일러는 수년에 걸쳐 개선되었으며 이제 static-pie 옵션을 지원합니다. 이 옵션을 사용하면 컴파일러에 위치 독립 코드를 생성하도록 지시하지만 이제 pie와 비교하여 정적으로 연결된 모든 라이브러리도 포함됩니다. 보안 관점에서 static-pie는 여전히 ASLR 엔트로피를 30비트에서 14비트로 줄이지만 이는 이전 상황보다 개선된 것입니다.pie

Bazel은 기본적으로 pie를 추가하고 정적은 pie와 호환되지 않으므로 링커 옵션 플래그를 사용하여 -static-pie 링커 플래그를 cc_binary 규칙에 전달하고 기본값을 덮어쓰는 것이 좋습니다.

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

이러한 옵션의 예는 정적 예 BUILD를 참고하세요. static_bin.cc는 static-pie와 정적으로 연결되어 매우 엄격한 syscall 정책을 사용할 수 있습니다. 이는 서드 파티 바이너리를 샌드박스 처리하는 데도 유용합니다.

32비트 x86 바이너리를 샌드박스 처리할 수 있나요?

Sandbox2는 컴파일된 것과 동일한 아키텍처만 샌드박스 처리할 수 있습니다.

또한 32비트 x86 지원이 Sandbox2에서 삭제되었습니다. 64비트 x86 실행기를 사용하여 32비트 x86 바이너리를 샌드박스 처리하거나 32비트 syscall을 만드는 64비트 x86 바이너리 (int 0x80을 통해)를 샌드박스 처리하려고 하면 둘 다 아키텍처 라벨[X86-32]로 식별할 수 있는 샌드박스 위반을 생성합니다.

이 동작의 이유는 syscall 번호가 아키텍처마다 다르며 syscall 정책이 실행기의 아키텍처로 작성되기 때문입니다. 따라서 Sandboxee에 다른 아키텍처를 허용하는 것은 위험합니다. 실제로 이는 겉보기에는 무해한 syscall을 허용하는 것으로 이어질 수 있지만 실제로는 더 유해한 syscall이 샌드박스를 이스케이프에 노출시킬 수 있습니다.

실행기 프로세스가 요청할 수 있는 샌드박스 수에 제한이 있나요?

각 Sandboxee 인스턴스 (forkserver에서 생성된 새 프로세스)에 대해 새 스레드가 생성됩니다. 여기에 제한이 있습니다.

실행기가 둘 이상의 샌드박스 생성을 요청할 수 있나요?

아니요. 1:1 관계가 있습니다. 실행기 인스턴스는 Sandboxee의 PID를 저장하고 샌드박스 인스턴스에 대한 Comms 인스턴스를 관리합니다.

forkserver.cc 내에서 '함수가 구현되지 않음'이 표시되는 이유는 무엇인가요?

Sandbox2는 비교적 새로운 커널에서만 실행을 지원합니다. 현재 컷오프는 3.19 커널이지만 향후 변경될 수 있습니다. 이는 TSYNC 플래그가 있는 사용자 네임스페이스 및 seccomp를 비롯한 비교적 새로운 커널 기능을 사용하기 때문입니다.

프로덕션에서 실행 중인 경우 거의 전체 플릿이 충분히 새로운 커널을 실행하고 있으므로 문제가 되지 않습니다. 이와 관련하여 문제가 있으면 Google에 문의하세요.

Debian 또는 Ubuntu에서 실행 중인 경우 다음과 같이 실행하여 커널을 업데이트할 수 있습니다.

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