MXC - 샌드박스 코드 실행 시스템

bubblewrap·seatbelt·processcontainer용 프런트엔드/SDK로 볼 수도 있지만, 이들을 일관되게 설정하는 일은 결코 쉽지 않음. 직접 구현하는 건 경험상 정말 좋지 않은 선택임.
런타임에 필요한 권한과 설정을 파악하는 학습 모드, MIT 라이선스, 선택적 원격 측정에 대한 명확한 고지, 간결하면서 읽기 쉬운 문서가 마음에 듦. Microsoft에 대한 호불호와 별개로 목적이 뚜렷하고 유용하며, 첫 버전인데도 상당히 품질이 좋아 보임.

사용하기 쉬워 보이지만 smolvm을 포기할지는 모르겠음. 작업마다 인스턴스를 띄우는 스크립트를 쓰고, 코딩 에이전트는 Nono로 감싸며, 해당 작업용 git 복제본을 제공하는 구성이 아주 잘 작동함.

bubblewrap을 조금 써봤는데, 조금만 복잡한 일을 하려 해도 다루기 까다로워짐. 마음대로 조립할 수 있는 거대한 레고 상자 같지만, 최종 사용자에게는 대개 미리 조립된 몇 가지 세트면 충분함.

SDK 설계는 평가하기 어렵지만 에이전트 실행 환경과 파이프라인에 통합하기 좋은 선택지로 보임. 특히 감사·디버그 모드가 유용함. bubblewrap에 새 실행 환경을 붙일 때면 보통 strace로 의존성을 하나씩 찾아내는 과정을 여러 차례 반복해야 함.

유망하지만 내가 특히 중요하게 여기는 세밀한 네트워크 제어가 macOS에는 빠져 있음. Windows와 Linux는 지원하지만, macOS에서는 호스트명별 허용·차단이나 IP·CIDR·포트·프로토콜별 허용·차단이 불가능함. 지원 표를 보면 확인할 수 있음. 나머지는 훌륭해 보이며, 서로 다른 기술 위에 공통 추상화 계층을 만드는 데 따르는 보편적인 어려움인 듯함.

smol machines는 macOS·Linux·Windows에서 그 기능들을 지원함. 네트워크 설정 문서에서 확인 가능함. [network]의 allow_hosts = ["api.github.com"]는 하위 도메인까지 허용하고, allow_host_patterns = ["example.com", "*.npmjs.org"]는 정확한 이름이나 하위 도메인 전용 패턴을 지정함. allow_cidrs = ["10.0.0.0/8", "1.1.1.1"]로 IP 대역이나 단일 IP도 지정 가능함. [[network.credentials]]에는 name = "github", environment_variable = "GITHUB_TOKEN"처럼 자격 증명을 설정함.

microsandbox도 세밀한 네트워크 정책을 지원하며, 이미 여러 기술을 아우르는 추상화 계층을 구축해 왔음. Unix에서는 VM 추상화 계층인 libkrun을 기반으로 함.
나는 그 위에 편리한 실행 도구인 runcontain을 만들고 있으며, 현재 이름을 변경하는 중임. Microsoft가 지금 가장 크게 기여할 수 있는 부분은 Windows용 경량 격리 기술이라고 봄.

비슷한 규칙을 강제하는 HTTP 프록시를 함께 제공할 수도 있을 듯함. Claude 특유의 문체를 걷어내고 읽으면, “외부 통신 격리는 강제되지만 프록시 사용은 협조적”이라는 문구는 결국 프록시를 통하지 않고는 외부로 통신할 수 없다는 뜻임. 물론 HTTP만 제한할 뿐, 다른 형태의 네트워크 요청까지 다루지는 못함.

흥미롭게도 Anthropic SRT는 같은 macOS 기반 기능을 쓰면서도 내가 원하는 네트워크 설정을 지원함. 라이브러리 사용 예시에서 확인 가능함. SandboxRuntimeConfig의 network.allowedDomains에 example.com, api.github.com을 지정하고 deniedDomains를 비워둘 수 있음. 파일시스템도 denyRead로 ~/.ssh 읽기를 막고, allowWrite로 .과 /tmp 쓰기를 허용하며, denyWrite로 .env 쓰기를 차단하는 식으로 설정 가능함.

최소 권한 샌드박스로 시작해 필요할 때 권한을 비동기적으로 추가하고 회수할 수 있는 도구가 있을까? 에이전트 실행 환경도 프로젝트 밖 폴더에 접근할 때 비슷한 시도를 하지만, 강제가 불완전하고 대개 권한 회수도 불가능함. 승인을 기다리는 동안 실행을 막기 때문에, 다른 방법으로 진행할 수 있는 작업조차 계속 지켜봐야 함.
실수로 실행한 rm -rf와 개인정보 유출은 막고 싶지만, 최소 권한 설정이 실제 작업을 방해하는 경우가 잦음. 차단된 접근을 모아 외부 TUI 대시보드에 보여주고, 에이전트를 멈추지 않은 채 권한을 허용할 수 있으면 좋겠음. 반복적인 승인 피로도 줄일 수 있을 텐데, 비슷한 도구가 이미 있을까?

nono가 비슷한 방향일 수 있음. 샌드박스 명령이 종료된 뒤 차단된 접근을 바탕으로 권한을 추가할 수 있지만, 원하는 것처럼 실시간으로 작동하지는 않음.

제대로 된 역량 기반 운영체제(capability-based OS) 가 있다면 모든 프로세스에 그 속성을 부여할 수 있음. 디스크 쓰기가 필요하면 쓰기 권한을 의존성으로 주입하고, 원격 호스트와 통신해야 하면 그 호스트에만 접근하는 핸들을 주면 됨. 권한을 원하지 않으면 아무것도 하지 않으면 되며, 그것이 기본 상태임.

익숙한 작업 방식 때문에 양자택일처럼 느껴지는 것일 수도 있음. 개방형 대화식 작업이라도 충분히 조사하고 시제품을 만든 뒤 구현으로 넘어가는 경계가 있고, 그때 필요한 권한 범위가 바뀜. 초기 조사와 자리를 비운 동안의 자동 실행을 분리하는 편이 나을 수 있음.

나도 같은 딜레마를 겪음. pi 세션과 하위 세션에 필요한 권한을 미리 알기 어려움. 예를 들어 하위 세션이 작업 중 로컬 Docker 개발 환경의 상태를 알아보려고 여러 Docker 명령을 실행하려 할 때가 있음.

Nvidia OpenShell과 관련 개발 블로그를 살펴보길 권함. 찾는 기능에 가까워 보임.

대부분 Rust인 코드가 35만 줄이나 되는데, 기반 샌드박스 코드를 저장소에 포함한 것도 아님. 코드 규모를 보면 확인 가능함. 나는 sandbox-run처럼 직접 파악하고 이해할 수 있는 것을 기반으로 삼는 편이 훨씬 안심됨.

파일을 살펴보면 적어도 절반은 주석이나 단위 테스트로 보임. 이 파일을 사이트는 2,900줄로 세지만, Rust 주석을 제대로 구분하지 못하는 듯함. 실제 소스는 1,465줄이고 테스트는 635줄이므로 35만 줄이라는 수치는 크게 부풀려짐.
반면 sandbox-run은 기여자가 한 명이고 기본적인 스모크 테스트만 있는 듯하며, 심각한 보안 취약점도 몇 가지 보임. _generate_seccomp_filter는 줄바꿈으로 구분한 시스템 호출을 여러 줄짜리 차단 목록과 비교해 사실상 아무것도 차단하지 못함. 메인 스크립트는 파일시스템 제한과 권한 축소 전에 작업 디렉터리의 .env를 셸 코드로 실행하므로, 공격자가 해당 파일을 제어하면 전체 권한으로 코드를 실행할 수 있음.
검증하지 않은 경쟁 상태도 여럿 보이지만 앞의 취약점만으로도 충분함. PR을 보낼 수도 있겠지만, 애초에 코드 줄 수 최소화를 목표로 Bash 샌드박스를 직접 만드는 방향에 동의하기 어려움. HN 댓글 대부분이 이 저장소 홍보처럼 보이는 것도 조금 우려됨.

시간이 지나며 감사해야 할 코드량에 영향을 주는 단위 시간당 변경 줄 수가 더 나은 지표라고 느낌. 다만 MXC의 한 달치 변경량이 runc의 2~3년치보다 많기는 함.

저수준부터 이런 고수준 도구까지 샌드박싱을 살펴보는 중인데, Rust mxc-sdk API는 좋아 보여도 빌드 구성에는 아쉬움이 있음.
SDK에 실행 파일과 이를 처리하는 빌드 스크립트 로직이 들어 있고, Windows 전용 작업을 모든 플랫폼에서 수행함. 일부 백엔드를 기능 플래그로 분리하지 않아 빌드 스크립트 작업이 늘어나며, 그 작업은 향후 Cargo 버전에서 깨질 예정임. 나머지 작업 중에도 빌드 스크립트로 처리할 필요가 없는 부분이 있고, 의존성도 상당히 많아 보임.

백엔드별 동작 문서를 훑어보니 거의 전체를 최신 세대 LLM이 만든 듯함. 용도에 맞게 깔끔하고 안전한 설계를 하라는 대신, 무슨 수를 써서든 작동하게 만들라는 지시로 받아들인 것처럼 보임.
bubblewrap 통합 문서조차 의식의 흐름대로 쏟아낸 글에 가까워서, 결과물을 거의 신뢰할 수 없음.

같은 연산을 여러 플랫폼과 기기에서 실행하려면 WebAssembly 런타임으로 만드는 게 맞음.

나도 샌드박스인 slopbox를 만들고 있음. Microsoft가 내 아이디어를 훔쳤다고 농담하고 싶지만, 요즘은 너도나도 샌드박스를 만드는 중임.

지난달쯤 Windows에 Experimental_CreateProcessInSandbox API가 추가된 것도 흥미로움. 공식 문서까지 생겼으니, 이제 이 이름을 영원히 유지해야 할 것 같아 재미있음.

문서는 실험적 기능임을 명확히 밝히고 있고, DLL에서 내보내는 함수조차 아님. 그래도 어떤 애플리케이션이 의존해 버려 계속 유지해야 한다면 우스운 일이 될 듯함.

조금 다른 이야기지만, 샌드박스 플러그인을 만드는 데 wasmtime과 wasm32-wasip3를 아주 잘 쓰고 있음. Rust로 플러그인을 작성할 때 도구 지원이 꽤 좋지만, 다른 언어는 현재 어떤지 모르겠음.
wasip3는 아직 안정화되지 않았지만, wasip2보다 비동기 코드 통합에 유용한 변화가 많이 들어 있음.