Grok Build · Sandbox Profiles

다섯 가지 샌드박스 Profile

workspace, devbox, read-only, strict, off는 파일 시스템과 서브프로세스 네트워크에 대한 서로 다른 capability 집합을 정의합니다. 이름은 방향을 제공하지만, 실제 경계는 파싱된 capability set을 확인해야 합니다.

학습 목표

ProfileName과 SandboxProfile에서 읽기/쓰기 및 네트워크 경계를 판단하고, custom extends를 올바르게 구성하며, 플랫폼 지원 및 강등 조건을 식별할 수 있습니다.

TEACHING DIAGRAM

Profile은 다차원 능력 프리셋입니다

수평 위치는 기억을 돕기 위한 것입니다. devbox, workspace, strict의 실제 차이는 기본 읽기, 쓰기 가능 경로, 네트워크 정책을 동시에 포함합니다.

다섯 가지 Profile의 교육용 능력 스펙트럼 offno sandbox devboxbroad writes workspacedefault profile strictallowlisted reads read-onlyno workspace write 더 개방적더 제한적
다섯 가지 내장 Profile의 소스 코드 의미
workspace

전체 파일 시스템 기본 읽기 가능; workspace, GROK_HOME, 임시 디렉토리 쓰기 가능; 서브프로세스 네트워크 제한 없음.

default_read=true
restrict_network=false
devbox

전체 파일 시스템 기본 읽기 가능; 루트 디렉토리를 열거하여 /data와 가상 파일 시스템을 제외하고 광범위하게 쓰기 권한 부여; 네트워크 제한 없음.

/data는 읽기 가능 유지, Linux에서 bwrap으로 쓰기 보호
read-only

전체 파일 시스템 기본 읽기 가능; workspace 쓰기 불가; GROK_HOME, 임시 디렉토리, 필수 장치는 여전히 쓰기 가능.

restrict_network=true
strict

전역 기본 읽기 비활성화; 시스템 런타임 디렉토리와 workspace만 개방; workspace, GROK_HOME, 임시 디렉토리 쓰기 가능.

default_read=false
restrict_network=true
off

capability set 적용을 건너뛰고 「Sandbox disabled」를 기록합니다. none 별칭도 허용합니다.

custom extends의 기반 클래스로 사용 불가
흔히 잘못 읽는 두 가지: workspace는 여전히 작업 공간 외부 파일 읽기를 허용합니다; strict는 여전히 workspace 쓰기를 허용합니다. read-only도 실행에 필요한 최소 쓰기 디렉토리를 보존합니다. Profile 이름은 소스 코드 capability를 따라야 하며, 문자 그대로의 의미로 규칙을 보완해선 안 됩니다.
Custom Profile & 구성 경계

extends 규칙

  • custom은 기본적으로 workspace에서 시작합니다.
  • workspace, devbox, read-only, strict를 extend할 수 있습니다.
  • off/none은 extend할 수 없습니다.
  • 다른 custom profile은 extend할 수 없습니다.
  • read_only, read_write, deny는 기반 클래스에 추가됩니다. 서브프로세스 네트워크 제한이 필요할 때 custom에서 명시적으로 restrict_network=true로 설정하세요.

전역 우선 보호

시스템은 먼저 ~/.grok/sandbox.toml을 읽고, 그다음 .grok/sandbox.toml을 읽습니다. 프로젝트 구성은 새 profile 이름만 추가할 수 있습니다. 프로젝트가 이미 전역에 존재하는 동일 이름의 profile을 선언하면, merge는 entry.or_insert를 사용하여 전역 정의를 유지합니다.

crates/codegen/xai-grok-sandbox/src/profiles.rs crates/codegen/xai-grok-sandbox/src/paths.rs ProfileName load_sandbox_config merge_project_profiles
플랫폼 메커니즘 & 강등 조건

파일 시스템 제약

enforce가 활성화되고 Unix에서 실행될 때, capability set은 Landlock 또는 Seatbelt에 적용됩니다. macOS deny는 Seatbelt 규칙을 사용합니다; Linux 서브경로 read-deny는 bwrap bind-over도 필요합니다.

네트워크 제약

메인 프로세스 네트워크는 모델 API 접근을 위해 열려 있습니다. restrict_network는 현재 서브프로세스 필터링을 통해 표현되며, 소스 코드의 seccomp 구현은 Linux에서 유효하고 비-Linux 함수는 no-op입니다. 플랫폼 경계는 실제 빌드 및 런타임 환경에서 검증해야 합니다.

절대화 금지: 플랫폼이 지원되지 않거나, 빌드에서 enforce가 활성화되지 않거나, apply가 실패하면 소스 코드는 경고를 기록하고 계속 실행됩니다. is_active()만이 실제 적용 여부를 반영합니다. 따라서 모든 환경이 「우회 불가능」하다고 약속할 수 없습니다.
실제 소스 코드 스냅샷
crates/codegen/xai-grok-sandbox/src/profiles.rsREAL SOURCE
pub enum ProfileName {
    #[default]
    Workspace,
    Devbox,
    ReadOnly,
    Strict,
    Off,
    Custom(String),
}

스냅샷 설명: 열거형이 완전히 보존되었습니다. 스펙트럼 다이어그램은 교육용 기억 도구이며, 실제 능력은 resolve(), essential_writable_paths(), 플랫폼 apply 결과에서 나옵니다.

수업 실습: 검토 전용 Profile 설계

요구사항: 저장소와 시스템 도구 읽기 가능, workspace 수정 불가, 임시 디렉토리 쓰기 허용, 서브프로세스 네트워크 제한, 추가로 ~/.ssh deny. 내장 기반 클래스를 선택하고, custom profile의 extends와 deny를 작성하며, 프로젝트가 사용자 전역의 동일 이름 정의를 왜 대체할 수 없는지 설명하세요.

Takeaway: 다섯 가지 Profile은 파싱 가능한 능력 템플릿입니다. 보안 평가 시 기본 읽기, 쓰기 가능 경로, deny, 서브프로세스 네트워크, 플랫폼 지원, apply 상태를 확인해야 합니다; custom 병합 규칙은 프로젝트가 동일 이름 전역 정책을 조용히 약화시키는 것을 방지합니다.