자주 묻는 질문(FAQ)

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

예, 대화목록은 Sandbox2에서 지원됩니다.

모든 스레드를 샌드박스 처리해야 합니다.

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

  • execve() 전에 샌드박스가 사용 설정된 첫 번째 모드에서 Sandbox2를 사용하는 경우 모든 스레드가 정책을 상속하므로 문제가 없습니다. 이 방법이 선호되는 샌드박스 모드입니다.
  • 실행자에 set_enable_sandbox_before_exec(false)이 있고 Sandboxee가 실행자에 SandboxMeHere()로 샌드박스화하려는 경우 실행자에 알리는 두 번째 모드를 사용 중인 경우 필터가 모든 스레드에 적용되었는지 확인합니다. 그렇지 않으면 샌드박스 이스케이프가 발생할 위험이 있습니다. 악성 코드가 샌드박스 처리된 스레드에서 샌드박스 처리되지 않은 스레드로 이전할 수 있습니다.

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

주의하지 않으면 많은 종속 항목과 부작용 (추가 syscall, 파일 액세스 또는 네트워크 연결)을 상속하기 쉽습니다. 그러면 샌드박스가 더 어렵고 (모든 부작용 추적) 안전하지 않게 됩니다 (syscall 및 파일 정책이 더 넓기 때문에). 일부 컴파일 옵션은 이러한 문제를 줄이는 데 도움이 될 수 있습니다.

  • 많은 syscall (open/openat, mmap 등)을 사용하는 동적 연결을 방지하기 위해 Sandboxee 바이너리를 정적으로 컴파일합니다.

  • Bazel은 기본적으로 pie를 추가하지만 정적 요소는 호환되지 않으므로 기능 플래그를 사용하여 cc_binary 규칙의 다음 옵션을 통해 강제로 사용 중지하는 것이 좋습니다.

    linkstatic = 1,
features = [
    "fully_static_link",  # link libc statically
    "-pie",
],

하지만 정적을 사용하면 ASLR 힙 엔트로피가 30비트에서 8비트로 감소하여 악용이 더 쉬워진다는 단점이 있습니다. 샌드박스 구현 및 정책에 따라 어떤 조치를 취할지 신중하게 결정하세요.

  • 정적이 아님: 좋은 힙 ASLR입니다. 초기 코드를 실행하기가 더 어려울 수 있지만 샌드박스 정책의 효율성이 떨어지고 벗어날 가능성이 있습니다.
  • 정적: 힙 ASLR이 좋지 않습니다. 초기 코드 실행이 더 쉽지만 더 효과적인 샌드박스 정책은 잠재적으로 해제되기 더 어려울 수 있습니다.

하지만 컴파일러가 정적 PIE (위치 독립적 실행 파일)를 지원하지 않기 때문에 안타깝습니다. PIE는 바이너리를 동적 객체로 구현하여 구현되며, 동적 로더가 바이너리를 실행하기 전에 무작위 위치에서 매핑합니다. 그런 다음 힙은 일반적으로 바이너리의 기본 주소 뒤의 무작위 오프셋에 배치되고 brk syscall로 확장되므로 이는 정적 바이너리의 경우 PIE가 없으므로 힙 ASLR 엔트로피만 이 오프셋임을 의미합니다.

이러한 컴파일 옵션의 예는 정적 예제 BUILD.bazel을 참조하세요. static_bin.cc는 정적으로 컴파일되므로 매우 엄격한 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 인스턴스 (포크 서버에서 생성된 새 프로세스)에 대해 새 스레드가 생성됩니다. 바로 이 부분에 제한사항이 있습니다.

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

아니요. 1:1 관계가 있습니다. Executor 인스턴스는 Sandboxee의 PID를 저장하고 Comms 인스턴스를 샌드박스 인스턴스에 관리하는 등의 작업을 수행합니다.

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

Sandbox2는 비교적 새로운 커널에서만 실행을 지원합니다. 현재 마감은 3.19 커널이지만 향후 변경될 수 있습니다. 그 이유는 사용자 네임스페이스, seccomp를 TSYNC 플래그와 함께 비교적 새로운 커널 기능을 사용하고 있기 때문입니다.

프로덕션에서 실행 중인 경우 거의 모든 Fleet에서 새로운 커널을 실행하기 때문에 이 문제는 발생하지 않습니다. 이와 관련하여 문제가 있는 경우 문의해 주시기 바랍니다.

Debian 또는 Ubuntu에서 실행 중인 경우 커널 업데이트는 실행만큼 간단합니다.

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