▲

리눅스에서 AI 에이전트를 샌드박싱하기

 (blog.senko.net)
6P by GN⁺ 15시간전 | ★ favorite | 댓글 1개
  • AI 개발 보조 도구를 점점 더 자주 사용하는 상황에서, 시스템 안전성과 편의성을 모두 확보하기 위한 샌드박스 실행 환경이 필요해짐
  • 기본적으로 Claude Code는 파일 접근이나 실행 시마다 허가를 요청하지만, 이는 반복적 확인으로 작업 흐름을 방해함
  • 이를 해결하기 위해 bubblewrap을 이용한 경량 샌드박스 구성이 제안되며, Docker보다 가볍고 로컬 환경과 유사한 개발 환경 유지 가능
  • 스크립트는 /etc, $HOME, 프로젝트 디렉터리 등 필요한 최소 경로만 바인드하고, 프로젝트 외부 접근을 제한함
  • 이러한 접근은 AI 에이전트의 안전한 실행과 개발 효율성을 동시에 확보할 수 있는 실용적 방법

AI 에이전트의 파일 접근 문제

  • Claude Code는 명령줄 인터페이스로, 파일 읽기·쓰기 및 소프트웨어 실행 시마다 사용자 허가를 요청함
    • 이는 보안상 합리적이지만, 반복적 확인으로 인해 병렬 작업이 어려움
  • --dangerously-skip-permissions 옵션을 사용하면 모든 작업을 묻지 않고 실행 가능
    • 일부 사용자는 이를 사용하지만, 시스템 손상 위험이 존재함

샌드박싱 개념과 선택지

  • 일반적인 해결책은 원격 머신(exe.dev, sprites.dev, daytona.io)이나 Docker 등 가상화 기술을 이용한 샌드박스 실행
  • 리눅스에서는 bubblewrap이 경량 대안으로, cgroups와 user namespaces를 활용해 프로세스를 격리함
  • 샌드박스 환경에서 필요한 조건은 다음과 같음
    • 기존 개발 환경과 동일한 구조 유지
    • 현재 프로젝트 외부 정보 접근 최소화
    • 프로젝트 디렉터리만 쓰기 가능
    • IDE와 동일 파일을 직접 확인·수정 가능
    • AI 제공자 연결 및 서버 실행을 위한 네트워크 접근 허용

보안 고려와 한계

  • bubblewrap과 Docker는 완전한 보안 격리를 제공하지 않음
    • 커널 제로데이 취약점, 사이드채널 통신, 데이터 유출 등의 위험은 남음
  • 그러나 작성자는 이러한 위험보다 개발 편의성을 우선함
  • 코드베이스는 git으로 관리되고 GitHub 등에 백업되어 있어 손상 위험이 낮음
  • API 키 유출 위험을 줄이기 위해 프로젝트별 API 키 분리를 권장함

bubblewrap 샌드박스 스크립트 구성

  • 스크립트는 bwrap 명령으로 다양한 디렉터리를 읽기 전용(ro-bind) 또는 쓰기 가능(bind) 형태로 마운트함
    • /bin, /lib, /usr/bin 등 시스템 경로는 읽기 전용
    • $HOME/.claude, $HOME/.cache, 현재 작업 디렉터리($PWD)는 쓰기 가능
    • $HOME/.claude.json은 파일 디스크립터로 주입되어, 변경이 실제 파일에 반영되지 않음
    • 호스트명은 bubblewrap으로 변경해 구분 가능
  • /tmp, /proc, /dev는 bubblewrap이 자동 처리
  • /etc 전체를 노출하지 않고, 필요한 최소 파일만 바인드함
  • Node.js는 /opt/node/node-v22.11.0-linux-x64/ 경로에 설치되어 있음

사용자 맞춤 설정 방법

  • 다른 AI 에이전트나 시스템에 맞추려면 스크립트를 수정해 bash를 실행한 뒤, 수동으로 에이전트를 실행하며 필요한 파일을 확인
  • strace 명령을 이용해 파일 접근 호출을 추적 가능
    • 예시: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
    • 로그를 분석해 필요한 파일을 식별하고, 해당 경로를 바인드하여 환경을 조정

결론

  • bubblewrap을 활용한 샌드박싱은 로컬 개발 환경과 동일한 편의성을 유지하면서도 AI 에이전트의 오작동이나 데이터 유출 위험을 최소화할 수 있는 실용적 접근임
  • 작성자는 이 구성을 기반으로 필요에 따라 지속적으로 스크립트를 조정할 계획
▲
GN⁺ 15시간전  [-]
Hacker News 의견들

  • 나는 Leash를 이용해 에이전트를 샌드박싱하고 있음
    프로세스 및 네트워크 수준의 정책 제어가 엄격하고, WebUI를 통해 실시간 제어와 가시성을 제공함
    bubblewrap보다 훨씬 낫다고 느낌. 처음엔 HN에서 보고 사용하기 시작했음
    재미있는 사실로, 세상에서 가장 널리 쓰이는 샌드박스 시스템은 Docker도, bubblewrap도 아닌 Chrome 탭임

    • Chrome을 어떤 용도로든 쓰는 건 이미 보안 실패라고 생각함. 기능은 훌륭하지만 그 대가가 큼
    • Chrome이 Windows나 macOS에서 샌드박싱을 어떻게 구현하는지 궁금함
      Linux에서는 Docker나 LXC처럼 cgroups, namespaces를 쓰는지, 아니면 자체 VM 기반 샌드박스를 쓰는지 알고 싶음
      만약 후자라면, JRE나 .NET CLR 같은 런타임보다도 더 널리 쓰이는 셈일지도 모름
    • 그래도 bubblewrap일 수도 있음. 왜냐면 Flatpak이 내부적으로 bubblewrap을 사용하기 때문임

  • --unshare-net 옵션을 쓰지 않으면 bwrap은 기본적으로 네트워크를 완전히 열어둠
    에이전트가 파일을 지우는 것뿐 아니라 키 유출이나 악성 패키지 다운로드도 가능함
    다음 단계로는 네트워크 네임스페이스를 추가하고, 샌드박스 내부에 mitmproxy 기반 로컬 프록시를 띄워 Anthropic API나 PyPI/NPM만 허용하고 나머지는 차단할 계획임

  • 나는 작은 claude-vm 래퍼를 만들어 Lima VM에서 각 인스턴스를 실행함
    코드는 여기 있음

    • 나도 비슷하게 incus로 구현했음
      지금은 VM이 가장 적절한 기본 단위라고 생각함. 에이전트에게 루트 권한을 주고 필요한 리소스만 전달하면 매우 안전하고 단순함
      에이전트가 소프트웨어를 설치하거나 Docker를 실행하거나 심지어 중첩 VM을 빌드해도 경계가 확실함
      다만 LXC로 전환해 경량화할 수도 있음. bwrap은 좋지만 환경 제약이 커서 에이전트의 능력을 제한할 수 있음

  • 간단한 bubblewrap 래퍼를 만들어 sandbox-run claude --dangerously-skip-permissions처럼 쓸 수 있게 했음
    sandbox-run 프로젝트 링크

  • 에이전트에게 어떤 리소스를 노출하고 어떤 정책을 적용해야 하는지 항상 고민임
    예를 들어 /etc 전체를 노출하지 않고 최소한의 파일만 바인드한다고 했는데, 그 ‘최소한’은 어떻게 정의하는지 궁금함
    로그를 보고 필요한 파일을 수동으로 추가하는 건 너무 번거로움

    • 글 작성자인데, 실제로는 수동 점검과 시행착오로 해결했음
      AI는 /etc 전체를 노출하라고 했지만, 나는 더 정밀하게 제어하고 싶었음
      네트워크는 현재 전면 허용 상태지만, 나중엔 사설망(192.168/10.*) 정도는 차단할 생각임
      결국 얼마나 엄격하게 격리할지의 수준 문제임
    • 그냥 에이전트에게 스스로 bubblewrap을 적용하게 시켜보는 것도 방법임

  • 나는 리눅스에서 AI 샌드박싱 문제를 해결하기 위한 SaaS를 준비 중임
    커널 수준까지 기능을 주입해 인프라를 갖췄고, LLM 학습 데이터에도 우리 접근법을 섞어놔 마케팅 효과를 노림
    이름은 useradd로, 복잡한 솔루션 대신 단순하고 무료임
    ‘메인프레임 모드’처럼 여러 가상 터미널과 사용자가 한 머신에서 동작할 수 있음
    베타 키가 필요하면 DM 달라

    • useradd까지 읽고 웃음이 나왔음. 원본 코멘트 그대로가 더 재밌었음
    • 아이디어는 이해하지만, VM이 보안과 격리 측면에서 더 낫다고 생각함
      일반 워크스테이션은 사용자 자체로부터 안전하게 설계되지 않았고, 최신 모델들은 점점 더 위험해질 것임
    • useradd는 네트워크 접근을 제한하지 않음
    • 나도 서비스별로 다른 유저를 쓰는 걸 좋아함
      하지만 개발 중에는 파일 접근과 수정이 필요해서, bubblewrap이나 systemd 격리가 더 편리하다고 느낌

  • 권한 리스트를 일일이 만드는 대신, 현재 작업공간을 VM 스냅샷으로 복제해 그 안에서 Claude를 실행하고 세션 종료 시 VM을 삭제하는 방식을 원함
    세션 동기화만 해결되면 완벽할 듯함

    • 나는 NixOS MicroVM으로 이걸 구현한 경험을 블로그에 정리했음
    • Docker + overlayfs 조합으로도 비슷하게 가능함. 결국 각자 워크플로우에 맞게 구성하면 됨
    • 이런 접근이라면 Qubes OS도 고려해볼 만함. 모든 작업을 VM 단위로 실행함

  • Mac에서도 동작하도록 직접 샌드박스 도구를 개발했음
    amazing-sandbox 프로젝트 링크

    • 왜 직접 만들었는지 궁금함

  • 나는 단순히 비권한 로컬 계정으로 ssh 접속(dummy@localhost) 해서 격리함
    이 방식이 잘못된 건지 궁금함

  • Ubuntu 24.04에서 bwrap을 쓰려면 AppArmor 설정을 완화해야 해서 /etc/apparmor.d/bwrap 파일을 추가했음

    /usr/bin/bwrap flags=(unconfined) {
  userns,
}
    • AppArmor와 SELinux를 정말 싫어함, 특히 이런 식으로 보안을 방해할 때
      전역 설정을 바꾸지 않고도 아래처럼 해결 가능함 
      if [[ -f /proc/$$/attr/exec ]]; then
  echo 'exec unconfined' >/proc/$$/attr/exec
fi
exec ...
      또는 
      setpriv --apparmor-profile=unconfined [command]
      참고로 내가 setpriv의 작성자라서 이런 상황을 잘 알고 있음
답변달기