본문으로 건너뛰기
피드

Codex CLI는 에이전트를 어떻게 샌드박싱하는가 — OS 네이티브 격리 심층 분석

devops 약 8분
vote
0
댓글
북마크

Codex CLI가 Docker 없이 OS 네이티브 샌드박싱(macOS Seatbelt, Linux Landlock+seccomp)으로 코딩 에이전트의 bash 실행을 격리하는 방법을 상세히 분석함. 3가지 권한 모드, 실행 파이프라인, 플랫폼별 구현, 자식 프로세스 관리, 세션 기반 신뢰 목록까지 다룸.

  • 1

    Codex는 Read Only, Auto, Full Access 3가지 모드 지원 — Auto가 기본값으로 OS 네이티브 샌드박싱 적용

  • 2

    macOS는 Apple Seatbelt로 .git을 읽기 전용으로 보호하고 네트워크를 all-or-nothing으로 제어

  • 3

    Linux는 Landlock(파일시스템)과 seccomp-BPF(네트워크 시스템콜)를 조합하여 더 세밀한 격리 구현

  • 4

    env_clear()로 환경변수 유출 방지, PR_SET_PDEATHSIG로 고아 프로세스 방지 등 보안 세부사항이 견고함

  • 5

    세션 범위 신뢰 목록과 샌드박스 실패 시 재실행 탈출구로 사용성과 보안의 균형을 맞춤

코딩 에이전트의 보안 딜레마

  • 코딩 에이전트는 bash 접근 권한이 있어야 강력해지는데, 이게 동시에 가장 위험한 부분임 — 임의의 bash 세션이 프로덕션 자격증명 접근이나 홈 디렉토리 삭제까지 가능하게 만듦
  • 가장 안전한 방법은 가상화(컨테이너 부팅 후 제한된 범위에서 실행)인데, 실제로 이렇게 하는 사람은 거의 없음. --dangerously-skip-permissions 플래그 이름이 잘 지어졌지만 대부분 그냥 무시하고 실행함
  • Claude Code나 Cursor에서 쓰는 커맨드 화이트리스트 방식은 brittle함 — 새 디렉토리에서 명령 실행하면 cd조차 승인 필요하고, 자리를 비우면 사실상 사용 불가능함

Codex의 3가지 권한 모드

  • Read Only: 파일 읽기와 질문 답변만 가능. 편집, 명령 실행, 네트워크 접근 모두 승인 필요
  • Auto (기본값): 워크스페이스 내 파일 읽기, 편집, 명령 실행 가능. 워크스페이스 외부 접근이나 네트워크는 승인 필요
  • Full Access: 네트워크 포함 모든 권한을 승인 없이 사용 가능

ℹ️참고

> Auto 모드가 핵심임. Docker를 쓰지 않고 OS 네이티브 샌드박싱 API로 제한을 구현해서, 오버헤드 없이 꽤 강력한 격리를 달성함.

실행 파이프라인 구조

sequenceDiagram
    participant Agent as 코딩 에이전트
    participant Main as main() / arg0_dispatch_or_else
    participant Router as process_exec_tool_call
    participant Safety as assess_command_safety
    participant SB as SandboxType 라우터
    participant Mac as macOS Seatbelt
    participant Linux as Linux Landlock+seccomp
    participant None as Raw Execution

    Agent->>Main: 도구 호출 요청
    Main->>Main: 바이너리 이름 확인 (codex-linux-sandbox?)
    Main->>Router: CLI 메인 로직으로 전달
    Router->>Safety: 명령어 안전성 평가
    Safety-->>Router: Safe / NeedsApproval / Unsandboxed
    Router->>SB: SandboxType에 따라 분기
    alt macOS
        SB->>Mac: spawn_command_under_seatbelt()
        Mac->>Mac: /usr/bin/sandbox-exec 실행
    else Linux
        SB->>Linux: codex-linux-sandbox 바이너리 spawn
        Linux->>Linux: Landlock(파일시스템) + seccomp(네트워크) 적용
    else None
        SB->>None: 샌드박스 없이 직접 실행
    end

macOS 구현: Apple Seatbelt

  • /usr/bin/sandbox-exec를 하드코딩해서 사용함. Apple이 Seatbelt를 deprecated로 표시했지만 Apple 자체 시스템 소프트웨어와 웹 브라우저 등에서 여전히 광범위하게 사용 중이라 당분간 사라지지 않음
  • 정책 설정에서 쓰기 가능한 루트 디렉토리를 열거하되, .git 디렉토리는 읽기 전용으로 별도 처리함 — 에이전트가 워크스페이스는 수정할 수 있지만 git 히스토리는 건드릴 수 없게 한 설계가 영리함
  • 네트워크 접근은 전부 허용 아니면 전부 차단의 이분법적 구조임. Seatbelt가 기본적으로 deny이므로 네트워크 권한을 아예 안 넣으면 자동 차단됨

⚠️주의

> Seatbelt의 한계: 커스텀 정책 작성 시 홈 디렉토리의 dotfile이나 ~/Library 접근 차단을 놓치기 쉬움. 또한 특정 도메인/프로토콜 단위의 세밀한 네트워크 제어가 불가능함.

Linux 구현: Landlock + seccomp-BPF

  • codex-linux-sandbox라는 별도 바이너리를 서브프로세스로 spawn하여, 직렬화된 정책과 대상 명령을 파싱한 뒤 제한을 적용하고 execvp로 실제 명령을 실행함
  • Landlock (Linux 5.13+): 파일시스템 전체에 읽기 접근을 허용하되, 쓰기는 화이트리스트된 루트(+ /dev/null)로만 제한함. execvp 전에 규칙을 적용해서 대상 명령이 시작되는 시점에는 이미 샌드박싱된 상태임
  • seccomp-BPF: connect, bind, listen, sendto, sendmsg 등 네트워크 관련 시스템콜을 선택적으로 차단함 (AF_UNIX는 로컬 IPC용으로 허용). macOS Seatbelt보다 더 세밀한 제어가 가능함

자식 프로세스 관리와 보안

  • spawn_child_async에서 env_clear()로 환경변수를 완전히 초기화한 뒤 필요한 것만 다시 설정함 — 민감한 환경변수 유출을 방지하는 조치임
  • 네트워크 비활성화 시 CODEX_SANDBOX_NETWORK_DISABLED=1 환경변수를 설정해서 하위 도구들이 상태를 인식할 수 있게 함
  • Linux에서는 prctl(PR_SET_PDEATHSIG)로 부모 프로세스가 죽으면 자식 프로세스도 함께 종료되도록 보장함 — 샌드박싱된 고아 프로세스가 남아도는 것을 방지함

커맨드 화이트리스팅과 신뢰 관리

  • 모든 명령 실행 전 assess_command_safety를 통과해야 함 — 자동 실행 가능, 사용자 승인 필요, 샌드박스 없이 실행 필요의 3가지로 분류됨
  • 신뢰 목록은 세션 범위(session-scoped)로 관리됨. 한번 승인한 명령은 해당 세션 동안 계속 신뢰됨
  • 샌드박스된 명령이 권한 문제로 실패하면 샌드박스 없이 재실행할지 물어봄. 승인하면 SandboxType::None으로 재실행하는 합리적인 탈출구가 있음

디버깅 도구

  • codex debug seatbeltcodex debug landlock 명령으로 샌드박스를 통해 임의의 명령을 테스트할 수 있음
  • 메인 CLI의 --full-auto 플래그와 동일한 옵션을 지원함
  • 샌드박싱이 실제로 어떻게 동작하는지 이해하는 데 유용한 도구임

컨테이너 없이 OS 네이티브 기능만으로 실용적인 에이전트 샌드박싱을 구현할 수 있다는 점이 핵심. 기본값을 샌드박스로 설정하고 필요시 선택적으로 권한을 올리는 opt-out 설계가, 보안과 개발자 경험 사이의 균형점을 잘 잡은 사례임.

댓글

댓글

댓글을 불러오는 중...

devops

포드가 AI 데이터센터 붐 수혜주로 뜬 이유는 자동차가 아니라 ESS였다

포드의 에너지 저장 사업이 AI 데이터센터 건설 붐을 타고 새 성장축으로 주목받고 있어. 전기차 수요 둔화로 남는 배터리 생산능력을 데이터센터·전력망용 ESS로 돌리는 전략이고, EDF 북미 사업체에 2028년부터 연간 4기가와트시 규모 공급 계약까지 체결했어.

devops

클라우드 빅3 차별화 논쟁, 정작 컴퓨트·스토리지는 거의 범용재가 됐다는 얘기

클라우드 업체들은 인공지능, 데이터베이스, 전용 서비스로 차별화를 강조하지만, 대부분의 기업 워크로드는 여전히 컴퓨트와 스토리지 위에서 돌아간다는 주장이다. AWS, 애저, 구글 클라우드의 핵심 인프라는 성숙도가 높아져 실질 역량 차이가 줄었고, 아키텍트는 브랜드보다 워크로드 적합성·비용·거버넌스·운영 정합성을 봐야 한다는 내용이다.

devops

DynIP, RFC 2136·IPv6·DNSSEC 지원하는 동적 DNS 서비스 공개

DynIP는 홈랩, 엣지 라우터, 인프라 팀을 겨냥한 동적 DNS(DDNS) 서비스다. 60초 안팎의 전파, RFC 2136 TSIG 기반 라우터 업데이트, 개인 도메인 연결, IPv6와 DNSSEC 지원을 핵심 기능으로 내세운다.

devops

깃허브 액션, 내부 데이터베이스 마이그레이션 여파로 4시간 지연

깃허브에서 2026년 5월 12일 13:41부터 17:43 협정세계시까지 일부 서비스 처리 지연이 발생했음. 내부 데이터베이스 마이그레이션으로 복제 지연이 생겼고, 작업 큐에 쌓이는 요청을 처리할 워커가 부족해진 게 원인이었음.

devops

AI 강국 경쟁, 결국 전기와 데이터센터 싸움으로 간다

AI 경쟁의 핵심이 모델과 반도체만이 아니라 안정적인 전력 확보로 이동하고 있다는 분석이야. 글로벌 데이터센터 전력 사용량은 2024년 400TWh에서 2030년 800TWh, 2050년 3500TWh 이상으로 커질 전망이고, 한국도 AI 데이터센터와 에너지 전략을 같이 설계해야 하는 상황이야.