컨테이너 격리에서 시스템 콜이 중요한 이유

컨테이너는 보통 각 프로세스에 별도의 운영체제 커널을 주는 것이 아니라 호스트 커널의 시스템 콜 인터페이스를 함께 사용합니다. 네임스페이스나 자원 제한이 적용되어도 프로그램은 필요한 커널 기능을 요청해야 합니다. seccomp는 허용할 시스템 콜 경로를 제한해 커널에 노출되는 표면을 줄이는 수단입니다. 이를 켰다고 커널 취약점이 사라지거나 컨테이너가 완전한 보안 경계가 되는 것은 아닙니다. Linux 커널 문서도 시스템 콜 필터링은 그 자체로 샌드박스가 아니며, 다른 격리·접근통제와 함께 써야 한다고 명시합니다.

시스템 콜 번호와 인자를 seccomp-BPF가 검사해 허용, 오류, 종료 등 커널 응답을 선택하는 개념도

seccomp-BPF가 호출을 평가하는 방식

필터는 커널이 제공하는 seccomp_data의 시스템 콜 번호와 인자 같은 정보를 대상으로 동작하는 classic BPF 프로그램입니다. 프로세스가 호출을 내면 커널이 필터를 평가하고 ALLOW, ERRNO, TRAP, KILL, TRACE, LOG, USER_NOTIF 등 결과 중 하나를 적용할 수 있습니다. 반환 동작은 호출을 계속 실행하거나 거부·오류 반환·신호·추적·기록·사용자 공간 알림으로 처리하는 등 의미가 서로 다릅니다. 따라서 “차단”이라는 한 단어로 모든 action을 설명하면 실제 동작을 놓칩니다.

필터는 프로세스가 필요한 권한 조건을 충족한 뒤 설치하며, 추가 필터를 쌓을 수 있습니다. 허용되지 않은 필터를 자식에게 물려주지 않도록 하는 설치 조건도 커널 문서에 설명되어 있습니다. 문서는 아키텍처 식별자를 확인하지 않고 시스템 콜 번호만 비교하면 여러 호출 규약을 가진 아키텍처에서 잘못 판정할 수 있다고 경고합니다. BPF 필터는 사용자 메모리 포인터를 직접 역참조하지 못하므로, 포인터가 가리키는 내용에 대한 복잡한 정책 판단을 대신하지 않습니다.

Docker 기본 프로파일은 Docker의 특정 설정이다

Docker 문서는 현재 기본 seccomp 프로파일을 기본 허용목록으로 설명합니다. 안내 페이지에 따르면 이 프로파일은 300개가 넘는 호출 중 약 44개를 막는 중간 수준의 보호와 넓은 호환성 사이의 선택입니다. 숫자와 차단 목록은 제품 문서의 현재 설명이며 다른 런타임, 배포판, 릴리스에 그대로 적용되는 고정 규칙은 아닙니다. 문서에는 ptrace, reboot, setns처럼 기본 목록에서 빠진 호출의 예와 각 제한의 이유가 나옵니다. 호출이 빠졌다고 모든 경로의 위험이 해소되는 것은 아닙니다.

커널에 seccomp 지원이 없거나 Docker 빌드가 해당 기능을 포함하지 않으면 동작 조건이 달라집니다. Docker는 컨테이너 실행 시 기본 프로파일을 사용하고 --security-opt로 다른 프로파일을 지정할 수 있다고 설명하지만, 기본 프로파일을 변경하는 것은 권장하지 않는다고 안내합니다. 사용자 정의 규칙은 애플리케이션의 실제 호출 요구와 호스트의 보안 설계를 함께 검토해야 하며, Docker 문서만으로 다른 플랫폼의 기본값을 추론할 수 없습니다.

전문가 관점: 거부 정책과 격리의 나머지 층을 함께 확인하기

seccomp의 장점은 각 호출 경계에서 작고 명시적인 규칙을 적용할 수 있다는 데 있습니다. 한편 모든 syscall 인자나 호출 뒤의 애플리케이션 의미를 판단하는 범용 정책 엔진은 아닙니다. 커널 문서가 강조하듯 논리적 동작과 정보 흐름을 통제하려면 다른 커널 보안 기능도 고려해야 합니다. Docker 프로파일 역시 넓은 호환성을 위해 허용목록을 제공하며, 예외를 추가하면 공격 표면과 서비스 호환성이 함께 달라집니다.

구성 검토에서는 어떤 호출이 어떤 이유로 허용되거나 거부되는지, 프로세스와 자식에 필터가 어떻게 적용되는지, 로그나 오류 action이 운영 환경에서 어떤 결과를 내는지 확인합니다. 정책을 바꾼다면 비운영 환경에서 대표 작업을 시험하고 필요한 접근이 유지되는지 검증해야 합니다. 이 절차는 안전을 보장하는 완성된 보안 감사가 아니라, 한 격리 계층의 동작과 의존성을 확인하는 출발점입니다.

출처