title = "80. 시스템 호출 차단 (Seccomp)" date: 2025-03-24 draft: false

시스템 호출 차단 (Seccomp)

핵심 인사이트 (3줄 요약)

1. 본질: Seccomp (Secure Computing mode)는 리눅스 커널에서 프로세스가 실행할 수 있는 시스템 호출 (System Call)의 범위를 제한하여, 애플리케이션의 비정상적인 동작이나 공격자가 탈취한 프로세스를 통한 2차 피해를 원천 차단하는 강력한 샌드박싱 (Sandboxing) 메커니즘이다.
2. 가치: 불필요한 시스템 호출을 차단함으로써 커널의 공격 표면 (Attack Surface)을 최소화하고, 특히 컨테이너 환경에서 컨테이너 탈출 (Container Escape)이나 권한 상승 공격을 방어하는 최후의 보안 보루 역할을 수행한다.
3. 융합: 현대의 Seccomp은 BPF (Berkeley Packet Filter) 또는 eBPF 기술과 결합하여 복잡한 인자값 필터링 및 조건부 차단을 고성능으로 수행하며, 이는 쿠버네티스 (Kubernetes)의 보안 정책 (RuntimeDefault) 및 제로 트러스트 (Zero Trust) 아키텍처의 핵심 요소로 자리 잡고 있다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

• 개념: Seccomp (Secure Computing mode)는 프로세스가 운영체제 커널에 서비스를 요청할 때 사용하는 시스템 호출 인터페이스에 일종의 "필터링 방화벽"을 설치하는 기술이다. 기본적으로 리눅스 커널은 수백 개의 시스템 호출을 제공하지만, 대부분의 일반적인 애플리케이션은 그중 10~20% 정도만 사용한다. Seccomp은 사용하지 않는 나머지 위험한 호출들을 잠금으로써 프로세스의 자유도를 제한한다.

• 필요성: 만약 웹 서버나 컨테이너가 해킹당해 공격자가 쉘(Shell) 권한을 얻더라도, Seccomp이 적용되어 있다면 공격자는 mount, reboot, ptrace와 같이 시스템을 장악하는 데 필요한 핵심 명령어를 실행할 수 없다. 즉, 프로세스의 권한이 탈취되어도 "할 수 있는 일"을 물리적으로 제한하여 피해를 국지화하는 것이 목적이다.

• 💡 비유: Seccomp은 은행 창구의 "방탄유리"와 같다. 직원이 손님과 대화하고 돈을 주고받는(필수 호출) 것은 허용하지만, 손님이 창구를 넘어 안으로 들어오거나 금고를 여는 행위(위험한 호출)는 유리 벽으로 막아버리는 것과 같다.

• 등장 배경:

  1. 커널 취약점 공격의 증가: 사용자 공간의 앱은 안전하더라도, 커널 자체의 버그를 악용하는 시스템 호출 공격이 빈번해졌다.
  2. 클라우드 및 멀티테넌트 환경: 하나의 커널을 여러 사용자가 공유하는 환경에서 한 명의 사용자가 전체 시스템을 붕괴시키는 것을 막아야 했다.
  3. 심층 방어 (Defense in Depth) 전략: 방화벽이나 인증만으로는 부족하며, 실행 중인 프로세스의 행동 자체를 커널 수준에서 규제해야 한다는 보안 철학이 대두되었다.

프로세스가 커널에 요청을 보낼 때 Seccomp 필터가 어떻게 개입하여 이를 검증하는지를 시각화하면 다음과 같다.

┌────────────────────────────────────────────────────────────────────┐
│                  Seccomp 필터링 아키텍처                           │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  [ 사용자 공간 (User Space) ]                                      │
│  ┌────────────────────────────────────────────────────────┐        │
│  │   애플리케이션 (Web Server, Container, DB)             │        │
│  └───────────────────────────┬────────────────────────────┘        │
│                              │ 1. 시스템 호출 요청 (e.g. open)     │
│  [ 커널 공간 (Kernel Space) ] ▼                                    │
│  ┌────────────────────────────────────────────────────────┐        │
│  │  [ Seccomp Filter Engine (BPF) ]  ◀── 2. 정책 대조       │      │
│  │  ┌──────────────────────────────┐                      │        │
│  │  │  Allow List: read, write...  │                      │        │
│  │  │  Deny List: reboot, mount... │                      │        │
│  │  └──────────────┬───────────────┘                      │        │
│  │                 │                                      │        │
│  │     3-A. 허용   │           3-B. 거부 (Kill/Error)      │       │
│  │         ▼       │               ▼                      │        │
│  │  ┌──────────────┴───┐       ┌───────────────────────┐  │        │
│  │  │ 실제 커널 서비스 실행 │       │ 프로세스 종료 / 실패 반환 │  │
│  │  └──────────────────┘       └───────────────────────┘  │        │
│  └────────────────────────────────────────────────────────┘        │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 위 아키텍처는 애플리케이션과 커널 사이의 게이트키퍼로서 Seccomp의 역할을 보여준다. 프로세스가 open()이나 execve()와 같은 시스템 호출을 실행하면, 커널은 해당 코드를 즉시 실행하지 않고 Seccomp 엔진에 먼저 전달한다. 엔진은 BPF(Berkeley Packet Filter) 형태의 정책을 조회하여, 해당 호출이 허용 목록에 있는지 확인한다. 만약 금지된 호출이 감지되면 커널은 즉시 해당 프로세스를 종료(SIGKILL)시키거나 오류(EPERM)를 반환하여 시스템을 보호한다. 이 과정의 핵심은 필터링 로직이 커널 내부에서 매우 빠르게 수행되어야 한다는 점이며, 이를 위해 효율적인 바이트코드 형태의 BPF가 사용된다.

• 📢 섹션 요약 비유: 출입증이 없는 사람이 보안 구역에 들어가려 할 때, 입구의 검문소에서 신분증을 확인하고 통과시키거나 즉시 퇴장시키는 보안 절차와 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

구성 요소 및 필터링 모드

시스템 호출 필터링 메커니즘 (Allow/Deny List)

Seccomp은 단순히 번호만 보는 것이 아니라, 호출 시 전달되는 인자값(Argument)까지 검사하여 정교한 제어를 수행한다.

┌──────────────────────────────────────────────────────────────────┐
│                  Seccomp BPF 필터링 로직 예시                    │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  [요청 데이터 구조]                                              │
│  - NR (Syscall Number)                                           │
│  - ARCH (Architecture: x86_64 등)                                │
│  - Instruction Pointer                                           │
│  - ARGS[0..5] (파라미터 값들)                                    │
│                                                                  │
│  [필터링 의사결정 트리]                                          │
│  1. 아키텍처가 맞는가?  ── (No) ──▶  [SECCOMP_RET_KILL]          │
│  2. NR == __NR_write?  ── (Yes) ─▶  [SECCOMP_RET_ALLOW]          │
│  3. NR == __NR_open?   ── (Yes) ─▶  [인자 검사 시작]             │
│     └─ ARGS[1] & O_CREAT? ─ (Yes) ─▶ [SECCOMP_RET_ERRNO]         │
│  4. 그 외 모든 호출      ──────────▶  [SECCOMP_RET_KILL]         │
│                                                                  │
│  결과: 쓰기는 허용하지만, 파일을 새로 만드는 open은 차단함       │
└──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이 도식은 Seccomp 필터가 내리는 논리적 판단 과정을 보여준다. 가장 먼저 아키텍처(x86, ARM 등)를 검사하는 이유는 공격자가 서로 다른 아키텍처의 시스템 호출 번호를 섞어서 필터를 우회하는 '아키텍처 스위칭 공격'을 막기 위해서다. 그 후 호출 번호(NR)를 대조하고, 필요한 경우 인자값(ARGS)을 비트 연산으로 검사한다. 예를 들어 open() 호출은 허용하되 파일을 생성하는 O_CREAT 플래그는 금지함으로써, 기존 파일은 읽을 수 있지만 새 파일은 만들 수 없는 정교한 권한 제어가 가능하다. 이러한 세밀한 필터링은 공격자가 악성 파일을 생성하여 시스템을 감염시키는 경로를 효과적으로 차단한다.

eBPF 기반 Seccomp 필터링 흐름

최근에는 기존 BPF보다 강력한 eBPF를 활용하여 성능과 유연성을 동시에 확보하는 추세다.

[애플리케이션 실행]
    ↓
[prctl(PR_SET_SECCOMP) 호출] (프로세스 스스로 제약 조건 설정)
    ↓
[eBPF 프로그램 로드] (커널 내 검증기(Verifier)가 안전성 확인)
    ↓
[시스템 호출 인터셉트] (Syscall Entry Point에서 가로채기)
    ↓
[eBPF Maps 참조] (동적으로 변경되는 차단 목록 확인)
    ↓
[결과 결정 및 반환] (허용 시 커널 실행, 거부 시 즉시 반환)

[다이어그램 해설] 이 흐름도는 Seccomp이 어떻게 적용되고 실행되는지를 보여준다. 중요한 점은 prctl 시스템 호출을 통해 프로세스가 '스스로' 보안 제약을 건다는 것이다. 이는 일단 초기화가 끝나고 위험한 작업을 수행하기 직전에 최소 권한 상태로 자발적으로 들어가는 방식이다. 또한 eBPF Maps를 사용하면 필터링 규칙을 하드코딩하지 않고 실시간으로 업데이트할 수 있어, 이상 징후가 발견된 특정 IP나 파일 경로에 대해 즉각적인 차단이 가능하다. 이 과정에서 커널 내의 '검증기(Verifier)'는 eBPF 코드가 커널을 멈추게 하거나 무한 루프에 빠지지 않도록 보장하여 시스템 안정성을 유지한다.

• 📢 섹션 요약 비유: 현장 요원(프로세스)이 위험한 임무에 들어가기 전, 스스로 무전기 이외의 장비는 쓰지 않겠다고 서약하고(prctl), 본부(커널)가 그 규칙을 실시간으로 감시하는 것과 같습니다.

Ⅲ. 융합 비교 및 다각도 분석

Seccomp vs AppArmor / SELinux

Seccomp은 "무엇을 할 수 있는가(행위)"를 제한하고, SELinux/AppArmor는 "무엇에 접근할 수 있는가(대상)"를 제한한다. 현대의 보안 시스템은 이 두 가지를 상호 보완적으로 사용한다. 예를 들어 컨테이너 보안에서 Seccomp은 위험한 syscall 실행을 막고, AppArmor는 컨테이너 외부 파일 시스템 접근을 막는 이중 방어막을 형성한다.

• 📢 섹션 요약 비유: Seccomp이 칼이나 총을 쓰지 못하게 손을 묶는 것이라면, SELinux는 특정 방에 들어가지 못하게 문을 잠그는 것과 같습니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오

1. 시나리오 — 컨테이너 탈출 (Container Escape) 방어: 공격자가 컨테이너 내의 취약점을 이용해 mount 시스템 호출로 호스트의 루트 디렉토리를 연결하려는 시도. 기술사적 판단으로, 쿠버네티스 포드(Pod)에 RuntimeDefault Seccomp 프로파일을 적용하여 mount, ptrace, kexec_load 등 시스템 전체에 영향을 주는 호출을 사전에 차단함으로써 탈출 시도를 무력화해야 한다.

2. 시나리오 — 제로 데이 (Zero-day) 취약점 대응: 아직 패치되지 않은 커널 취약점이 특정 시스템 호출(예: unshare)을 통해 노출된 상황. 긴급 조치로 운영 중인 애플리케이션에서 해당 syscall이 불필요하다면, Seccomp 프로파일을 즉시 수정 배포하여 취약점 실행 경로를 차단함으로써 패치 전까지의 '보안 골든 타임'을 확보해야 한다.

도입 체크리스트

• 기술적: 애플리케이션이 구동 시 반드시 필요한 syscall 목록을 strace 도구로 전수 조사하였는가? (누락 시 앱 크래시 발생)
• 운영·보안적: Seccomp 위반 로그를 감시하여 정상적인 앱 업데이트로 인한 syscall 변화인지, 실제 공격 시도인지 구분하는 모니터링 체계가 있는가?

안티패턴

• Privileged 컨테이너 사용: 컨테이너를 --privileged 모드로 실행하면 Seccomp을 포함한 모든 보안 장치가 무력화된다. 이는 보안적으로 매우 위험하며, 반드시 필요한 기능이 있다면 특정 'Capability'만 개별적으로 부여하는 것이 정석이다.

• 📢 섹션 요약 비유: 열쇠 꾸러미 전체를 주는 것(Privileged)보다, 꼭 필요한 방문 열쇠 하나만 주는 것이 훨씬 안전한 관리 방법입니다.

Ⅴ. 기대효과 및 결론

정량/정성 기대효과

미래 전망

• 자동 프로파일 생성 (Seccomp Recording): 개발자가 일일이 syscall 목록을 적지 않아도, 테스트 단계에서 앱의 동작을 학습하여 최적의 Seccomp 프로파일을 자동으로 생성해 주는 도구가 보편화될 것이다.

• 하드웨어 가속 Seccomp: CPU 하드웨어 수준에서 특정 syscall의 권한을 하드코딩하거나 가속화하여, 필터링 오버헤드를 0에 가깝게 줄이는 기술이 하이엔드 서버 프로세서에 도입될 예정이다.

• 📢 섹션 요약 비유: 스스로를 절제하는 규칙(Seccomp)이 가장 강력한 보호막이 되어, 복잡한 소프트웨어 세상의 안전을 지키는 핵심 기술로 계속 발전할 것입니다.

📌 관련 개념 맵 (Knowledge Graph)

👶 어린이를 위한 3줄 비유 설명

1. 컴퓨터 프로그램이 나쁜 짓을 하지 못하게 손을 묶어두는 **"안전 벨트"**와 같아요.
2. 프로그램이 꼭 해야 하는 일(글쓰기, 읽기)은 허용해주지만, 무서운 일(컴퓨터 끄기, 망가뜨리기)은 "절대 못 하게 막아버려요."
3. 도둑이 프로그램의 열쇠를 훔쳐 가도, 안전벨트 때문에 "컴퓨터 전체를 망가뜨릴 수 없게" 지켜준답니다!