Hacker News 2026.03.22 33

샌드박싱의 딜레마: 완벽한 격리는 왜 이렇게 어려운가

보안의 기본이자 가장 어려운 문제, 샌드박싱

ACM에서 발행된 이 논문은 소프트웨어 샌드박싱(sandboxing)이라는 주제를 정면으로 다룬다. 샌드박싱은 신뢰할 수 없는 코드를 격리된 환경에서 실행하여 시스템의 나머지 부분에 영향을 주지 못하도록 하는 보안 기법이다. 브라우저가 각 탭을 별도 프로세스로 실행하는 것, 모바일 앱이 다른 앱의 데이터에 접근하지 못하는 것, 컨테이너가 호스트 시스템과 격리되는 것 모두 넓은 의미의 샌드박싱이다.

그런데 이 논문의 부제가 말해주듯, 문제는 "완벽한 경계(foolproof boundaries)"와 "끝없는 우회(unbounded foolishness)" 사이의 긴장 관계에 있다. 아무리 정교한 샌드박스를 만들어도 공격자는 새로운 우회 경로를 찾아내고, 그 경계를 더 강화하면 정상적인 기능까지 제한되는 악순환이 반복된다.

샌드박싱이 어려운 근본적 이유

샌드박싱의 핵심 딜레마는 "격리"와 "기능" 사이의 트레이드오프다. 완벽하게 격리된 프로그램은 아무것도 할 수 없다. 파일을 읽지도, 네트워크에 접속하지도, 화면에 출력하지도 못한다면 그 프로그램은 존재 의미가 없다. 따라서 샌드박스는 반드시 일부 권한을 허용해야 하고, 바로 그 허용된 권한이 공격 표면(attack surface)이 된다.

전통적인 운영체제의 프로세스 격리는 가장 오래된 형태의 샌드박싱이다. Unix의 사용자 권한 모델, chroot, 그리고 이후 등장한 Linux의 namespaces와 cgroups가 이 계보를 잇는다. 하지만 이들 메커니즘은 시스템 콜(syscall) 인터페이스를 통해 커널과 소통해야 하는데, Linux 커널의 시스템 콜 수가 300개가 넘고 각각이 복잡한 동작을 수행하기 때문에, 이 인터페이스 자체가 거대한 공격 표면이 된다.

Google의 Chrome 브라우저는 이 문제에 대한 업계 최고 수준의 접근을 보여준다. 렌더러 프로세스를 seccomp-BPF로 제한하여 사용할 수 있는 시스템 콜을 극소수로 줄이고, 필요한 리소스는 브로커 프로세스를 통해서만 접근하도록 설계했다. 그런데도 Chrome의 샌드박스 탈출(sandbox escape) 취약점은 매년 발견된다. Pwn2Own 같은 해킹 대회에서 Chrome 샌드박스 탈출은 가장 높은 상금이 걸리는 카테고리 중 하나다.

WebAssembly와 새로운 접근법들

최근 샌드박싱 분야에서 가장 주목받는 기술 중 하나는 WebAssembly(Wasm)다. Wasm은 선형 메모리(linear memory) 모델을 사용하여 샌드박스된 코드가 자신에게 할당된 메모리 영역 밖으로 접근하는 것을 원천적으로 차단한다. 기존의 네이티브 코드 샌드박싱이 운영체제의 프로세스 격리에 의존했다면, Wasm은 언어 수준에서 메모리 안전성을 보장하는 셈이다.

WASI(WebAssembly System Interface)는 여기서 한 발 더 나아가 capability-based security 모델을 적용한다. 프로그램이 파일이나 네트워크에 접근하려면 해당 capability를 명시적으로 부여받아야 하며, 부여받지 않은 리소스에는 접근할 방법 자체가 존재하지 않는다. 이것은 전통적인 Unix 모델에서 "기본적으로 대부분의 시스템 콜에 접근 가능하고, 제한하고 싶은 것을 차단하는" 방식과 정반대의 철학이다.

마이크로VM 기반 접근도 주목할 만하다. AWS의 Firecracker는 각 Lambda 함수나 Fargate 컨테이너를 경량 가상머신으로 격리한다. 하이퍼바이저 수준의 격리는 커널 취약점을 통한 탈출이 불가능하다는 점에서 컨테이너보다 강력한 보안 경계를 제공한다. 다만 VM을 시작하는 오버헤드가 있기 때문에, Firecracker는 이를 125ms 이내로 줄이는 데 집중했다.

gVisor는 또 다른 흥미로운 접근을 취한다. 사용자 공간에서 Linux 커널의 시스템 콜 인터페이스를 재구현하여, 컨테이너의 시스템 콜이 호스트 커널에 직접 도달하지 않도록 중간 계층을 둔다. 이것은 공격 표면을 호스트 커널이 아닌 gVisor의 Sentry 프로세스로 제한하는 효과가 있다.

한국 개발자에게 주는 실무적 시사점

샌드박싱은 더 이상 보안 전문가만의 영역이 아니다. 클라우드 네이티브 환경에서 일하는 모든 개발자가 알아야 할 기본 개념이 되었다. 특히 한국에서 많이 사용되는 쿠버네티스 환경에서 컨테이너 격리의 한계를 이해하는 것은 중요하다. 컨테이너는 같은 커널을 공유하기 때문에 커널 취약점 하나로 모든 컨테이너가 위험해질 수 있다.

실무에서 고려할 수 있는 접근법은 몇 가지가 있다. 사용자 입력을 처리하는 코드를 별도의 샌드박스 프로세스로 분리하는 것, 서드파티 라이브러리를 Wasm으로 컴파일하여 격리 실행하는 것, 멀티테넌트 서비스에서 Firecracker 같은 마이크로VM을 활용하는 것 등이다. 어떤 방식을 선택하든 핵심 원칙은 같다. 최소 권한의 원칙(principle of least privilege)을 지키고, 격리 경계를 명확히 정의하며, 그 경계의 한계를 인식하는 것이다.