Show HN: Drop – A rootless Linux sandbox with gVisor support
Show HN: Drop — gVisor를 지원하는 루트리스 Linux 샌드박스
Drop은 기존 Linux 배포판과 설치된 프로그램을 그대로 쓰면서 코딩 에이전트나 외부 프로그램을 격리하는 루트리스 샌드박스입니다. Linux 네임스페이스를 기본 격리 수단으로 쓰고, 선택적으로 gVisor를 붙여 호스트 커널과 프로그램 사이에 사용자 공간 커널을 둡니다.
- 주제
AI 요약
Drop은 개발자가 익숙한 Linux 작업 환경을 유지하면서 코딩 에이전트와 출처가 불분명한 프로그램을 격리하도록 만든 샌드박스입니다. 별도 컨테이너 이미지를 준비하지 않아도 기존 배포판과 설치된 프로그램을 사용할 수 있습니다. 각 환경은 독립된 홈 디렉터리를 쓰고, 호스트의 홈 디렉터리는 샌드박스 안에서 숨깁니다.
권한과 격리 방식
Drop은 root 권한 없이 Linux 사용자 네임스페이스에서 실행됩니다. 프로세스, 마운트, 네트워크, IPC, cgroup 네임스페이스를 분리하고, 샌드박스 프로그램을 실행하기 전에 사용자 네임스페이스의 권한(capabilities)을 모두 제거합니다. 따라서 프로그램이 샌드박스 안에서 권한을 얻어 바인드 마운트 같은 작업을 하는 것을 막습니다. TOML 설정으로 샌드박스에 노출할 파일과 디렉터리, 로컬 네트워크 서비스를 지정할 수 있으며, 기본 설정을 여러 환경에서 공유합니다.
코딩 에이전트를 --dangerously-skip-permissions 옵션으로 실행해도 Drop이 운영체제 수준에서 접근 권한을 제한합니다. 잘못 생성한 rm -rf ~ 명령이 실제 홈 디렉터리를 지우지 못하게 하고, 프롬프트 인젝션이 ~/.ssh를 노려도 샌드박스에서 해당 파일을 찾지 못하게 하는 방식입니다. localhost에서 실행 중인 서비스 연결도 기본적으로 거부합니다. PyPI나 npm에서 설치한 프로그램을 실행할 때도 사용자 계정 전체에 접근 권한을 주지 않도록 격리 환경을 만들 수 있습니다.
gVisor와 기존 도구의 차이
기본 실행 방식은 Linux 네임스페이스를 사용합니다. 선택하면 gVisor의 사용자 공간 커널을 실행하는 runsc를 붙여 프로그램이 호스트 커널에 직접 시스템 호출을 보내지 않도록 합니다. Drop 제작자는 gVisor가 기본 방식과 같은 샌드박스 환경을 제공하므로 사용자 경험을 유지하면서 추가 격리 계층을 선택할 수 있다고 설명합니다. 다만 gVisor는 Go로 커널을 재구현하므로 호환성 문제가 생길 수 있습니다.
Hacker News에서는 bubblewrap(bwrap)과의 차이를 묻는 질문이 나왔습니다. 제작자에 따르면 bwrap은 Flatpak 같은 도구가 활용하는 저수준 구성 요소이고, Drop은 일상적인 작업에서 직접 쓰도록 만든 고수준 도구입니다. 제작자는 처음에 runc와 crun을 통해 Drop을 구현하려 했지만, 필요한 샌드박스 설정을 맞추기 어려웠다고 답했습니다. OCI 컨테이너 런타임은 Drop과 다른 사용 범위를 갖기 때문에 필요한 기능을 추가해 달라고 요청하기도 쉽지 않았습니다. bwrap도 검토했지만, Linux API를 세밀하게 호출하는 쪽이 원하는 설정을 구현하기에 유연하다고 판단했습니다.
현재 한계와 토론
Drop은 현재 컨테이너 안에서 실행되지 않으며, 샌드박스 안에서 컨테이너를 시작하는 기능도 지원하지 않습니다. GUI 프로그램과 하드웨어 가속 지원은 사용자의 요청이 있었고, 제작자는 GUI 앱 샌드박싱을 로드맵에 올렸다고 밝혔습니다. 가상 머신(VM)을 세 번째 실행 방식으로 추가하는 방안도 검토 중이지만, 기존 배포판과 파일 구성을 동일하게 유지할 수 있을지는 아직 확실하지 않다고 설명했습니다.
댓글에서는 샌드박스마다 보호 목표가 다르다는 점도 드러났습니다. 읽기는 허용하고 현재 작업 디렉터리 밖의 쓰기만 막는 설정은 실수로 파일을 지우는 일을 줄이지만, 악성 의존성이나 프롬프트 인젝션이 SSH 키를 읽어 외부로 보내는 상황까지 막지는 못한다는 지적이 나왔습니다. 반면 VM을 이용하면 격리 경계를 더 명확하게 잡을 수 있지만, Drop은 별도 이미지를 관리하지 않고 기존 사용자 공간을 활용하는 편의성을 우선합니다. 제작자는 과거 샌드박스와 컨테이너의 보안 문제를 검토하고 있으며, root로 실행하지 않는 점도 특정 문제 유형을 줄이는 데 도움이 된다고 답했습니다.
Hacker News 반응
- @yu3zhou4 — 축하합니다, Jan! 요즘 보안 측면에서 널리 쓰이려면 꼭 필요한 것 같습니다. 작동 방식을 궁금해하는 분이라면 랜딩 페이지보다 문서 페이지가 더 자세하다고 느꼈습니다.
- @JoshTriplett — bubblewrap보다 나은 점은 프로그램과 커널 시스템 호출 사이에 격리 계층을 둔다는 것인가요?
- @mixedbit — bubblewrap은 저수준 도구이며, 직접 쓰는 고수준 샌드박스라기보다 샌드박스를 구성하는 도구라고 설명합니다. 예를 들어 Flatpak이 bubblewrap을 구성 요소로 씁니다. Drop은 저수준 설정을 조립하지 않고 일상 업무에서 직접 쓰도록 만든 고수준 도구입니다.
- @refibrillator — 저도 비슷한 작업을 하고 있습니다. 이런 생각을 하는 사람이 많다는 뜻이겠네요. README에서 유명 도구와 비교한 점은 좋습니다. 다만 보안상 차별점은 조금 더 설명이 필요해 보입니다. nsjail이나 runc도 같은 기본 요소를 쓰는데, 기존 구성 요소 위에 만들지 않고 직접 구현한 이유가 궁금합니다.
- @mixedbit — 처음에는 Drop 설정 파일을 만들어 runc나 crun에 전달하는 Python 스크립트로 시작했습니다. 필요한 샌드박스 속성을 모두 설정하는 과정에서 문제가 있었습니다. 기술적으로 해결할 수는 있었지만, 사용자가 없는 새 프로젝트가 성숙하고 널리 쓰이는 도구에 기능을 요청하기는 어려울 수 있었습니다. 그래서 세밀한 Linux API를 직접 호출하는 유연성을 택했습니다. runc는 JSON 설정을 받는 비교적 큰 단위의 API이고, bubblewrap도 명령줄을 받는 큰 단위의 API라고 볼 수 있습니다. 검증된 구성 요소를 재사용하는 장점도 있으므로 쉬운 선택은 아니었습니다.
- @messh — bwrap이나 srt와는 어떻게 다른가요? 저는 bwrap으로 모든 경로를 읽기 전용으로 두고 현재 작업 디렉터리만 쓰기 가능하게 합니다. pi 같은 코딩 에이전트도 비슷한 샌드박싱을 지원합니다.
- @mixedbit — 어디서든 읽을 수 있고 현재 디렉터리만 쓸 수 있는 설정은 잘못된 명령으로 생기는 실수를 막는 데 유용합니다. 하지만 악성 의존성이나 프롬프트 인젝션으로 인한 피해까지 막으려면 더 강한 보호가 필요합니다. 읽기 전용이어도 SSH 키가 노출될 수 있습니다. bwrap 위에 고수준 도구를 만들 수도 있지만, Drop은 에이전트뿐 아니라 격리가 필요한 다른 프로그램에도 같은 도구와 설정을 쓰도록 만든 범용 샌드박스입니다.
- @tylergetsay — 컨테이너 안에서도 작동하나요?
- @mixedbit — 아쉽지만 작동하지 않습니다. 샌드박스에서 컨테이너를 시작하는 기능도 지원하지 않습니다.
- @ec109685 — 호스트 커널을 완전히 격리하면서 네이티브 성능을 내는 경량 VM 대신 gVisor를 쓰는 주된 장점은 무엇인가요? 컨테이너 탈출 사례를 보면 격리를 제대로 구현하기가 매우 까다롭습니다.
- @mixedbit — Drop은 사용자의 작업 환경을 최대한 유지하면서 격리할 부분을 나누는 경험을 목표로 시작했습니다. 기존 배포판과 설치된 패키지를 유지하는 점이 중요합니다. VM을 세 번째 실행 방식으로 추가할 수 있을지는 아직 확실하지 않습니다. 가능하다면 호스트 커널을 잘 격리하면서 표준 Linux 커널과 호환되고, 샌드박스 안에서 컨테이너도 시작할 수 있다는 장점이 있습니다.
- @p2004a — 몇 주 전부터 Drop을 쓰고 있는데 만족스럽습니다. 편의성과 격리 사이의 균형이 좋고, 개발 전반에 기본으로 쓰고 싶습니다. 아직 해결되지 않은 문제는 Docker나 Podman Compose로 컨테이너 앱을 개발하는 일과 하드웨어 가속이 필요한 GUI 앱 개발입니다.
- @mixedbit — GUI 앱 샌드박싱을 로드맵에 올렸습니다. 네임스페이스와 gVisor에 더해 VM을 세 번째 실행 방식으로 추가하는 방안도 생각하고 있지만, 가능한지는 아직 확실하지 않습니다.
- @0cf8612b2e1e — 옵션은 많은데 무력한 기분이 듭니다. SSH 키를 훔칠 걱정 없이 악성코드를 일부러 실행할 수 있을 만큼 안전한 도구는 무엇인가요? 찾아본 도구들은 특정 조건에서만 안전하다고 말하는 것 같습니다. 가장 확실하고 쓰기 쉬운 선택은 무엇인가요?
- @chickensong — 키를 넣지 않은 VM입니다.
원문: droprun.sh / 번역·요약: Trawling