리눅스 Landlock 설정 - 샌드박스

Landlock 리눅스 샌드박스 이해

Landlock은 리눅스 애플리케이션이 스스로 접근 가능한 리소스를 선언하고
커널 수준에서 샌드박싱을 적용할 수 있게 해주는 리눅스 샌드박스 보안 API임
비권한(unprivileged) 기반으로 동작하며, 기존 SELinux·AppArmor보다 단순하고 개발자 친화적임
데스크톱·서버·엔터프라이즈 환경에서 세분화된 리눅스 샌드박스를 구현할 수 있는 새로운 도구로 주목받는 중임

Landlock 리눅스 샌드박스는 리눅스 커널에 도입된 비교적 새로운 보안 메커니즘으로, 애플리케이션이 “내가 앞으로 접근할 수 있는 자원은 이 범위로만 제한하겠다”고 스스로 선언하고 그 이후의 권한을 커널 수준에서 잠그는 방식의 무권한 샌드박스(unprivileged sandbox) 기능이다.

기존의 SELinux·AppArmor·seccomp가 주로 관리자나 배포판 정책 중심으로 동작하는 반면, Landlock 리눅스 샌드박스는 애플리케이션 개발자 입장에서 직접 쓰기 쉬운 방어 계층을 목표로 한다.

1. Landlock 개념과 설계 철학

Landlock은 한 문장으로 요약하면 다음과 같다.

애플리케이션이 스스로 “이 디렉터리·파일·포트만 쓰겠다”고
명시적 허용 목록(allowlist)을 선언하고, 나머지는 기본 차단하는
리눅스 샌드박스 API임

설계 철학은 OpenBSD의 unveil(), pledge()와 유사하다. 즉, “필요한 리소스만 허용하고 나머지는 차단하는 최소 권한 원칙”을 리눅스에서도 커널 레벨에서 강제하자는 접근이다.

• Linux Security Module(LSM)로 구현
• Linux 커널 5.13부터 사용 가능
• 기존 LSM과 함께 동작 가능한 stackable LSM
• 애플리케이션 단위의 자기 제한(self-restriction)에 초점

2. 기존 리눅스 보안 메커니즘과의 차이

리눅스에는 이미 다양한 보안 메커니즘이 존재하지만, 각자 뚜렷한 한계를 갖고 있다.

• Containerization(Docker, Podman 등)
  └ 서비스 격리에는 강력하지만 데스크톱 앱에는 과한 경우가 많음
  └ --privileged 설정처럼 잘못 쓰면 격리를 쉽게 무력화
  
• Flatpak / Snap
  └ GUI 앱 배포에는 적합하지만, CLI 도구에는 오히려 불편할 수 있음
  └ 권한 범위가 넓게 설정되는 경우도 많음
  
• Firejail 등 래퍼형 샌드박스
  └ 앱별 프로파일 관리 필요, 사용자가 매번 명시적으로 호출해야 함
  
• seccomp
  └ 시스템 콜 단위 필터링에는 강력하지만 정책 작성이 복잡함
  └ 잘못 구성하면 정상 동작도 막거나, 블랙리스트식 필터링이 허점을 만들 수 있음
  
• SELinux / AppArmor
  └ 매우 강력하지만 정책 언어가 어렵고, 관리자·배포판 수준의 정책 관리가 필요
  └ 일부 배포판에서는 기본 비활성화 상태이기도 함
  

Landlock 리눅스 샌드박스는 여기서 “애플리케이션이 직접, 비권한으로, 코드 안에서” 샌드박스를 구성할 수 있다는 점이 가장 큰 차별점이다.

3. Landlock 작동 방식 개요

Landlock은 LSM으로 구현되며, 애플리케이션 코드에서 다음 흐름으로 사용한다.

• 정책에 포함할 객체(디렉터리·파일·소켓 등)를 커널에 알려줌
• 해당 객체에 대해 어떤 접근 권한(읽기·쓰기·실행 등)을 허용할지 지정
• landlock_restrict_self()를 호출해 현재 스레드와 자식 프로세스에 정책 적용
• 한 번 제한되면 해당 프로세스 계열에서는 권한을 되돌릴 수 없음

Landlock 정책의 특징은 다음과 같다.

• Transient restriction: 정책은 프로세스가 살아 있는 동안에만 적용되고, 종료 시 사라짐
• 계층(layer) 구조: 최대 16개 계층 중첩 가능, 하위 계층에서 권한을 더 줄일 수 있음
• 역방향 불가: 한 번 제거된 권한은 어떤 계층에서도 복원 불가
• 비권한(unprivileged): root 권한 없이도 일반 앱이 자체 샌드박스 구성 가능
• ABI 버전 관리: 구형 커널에서는 가능한 기능만 사용하도록 ABI 버전 협상 지원
• Stackable LSM: SELinux, AppArmor와 병행 사용 가능

4. 정책 모델: Handled accesses와 Access grants

Landlock 리눅스 샌드박스는 크게 두 가지 개념으로 정책을 정의한다.

• Handled accesses
  └ 어떤 종류의 작업을 제한할지 범주를 지정한다.
  └ 예: 파일 읽기, 파일 쓰기, 디렉터리 생성, 삭제 등
  
• Access grants
  └ 허용할 객체를 명시적으로 지정하는 허용 목록이다.
  └ 예: /home/user는 읽기 전용, /tmp는 읽기/쓰기 허용
  

즉, Landlock은 “이런 작업들에 대해, 이 경로·자원에 한해서만 허용”하는 식으로 화이트리스트 기반의 리눅스 샌드박스를 구현한다.

정책은 계층적으로 쌓을 수 있다. 상위 계층에서 이미 차단한 권한은 하위 계층에서 되살릴 수 없고, 하위 계층은 추가로 제한을 더 걸 수 있을 뿐이다.

5. 사용 예시: 웹 서버·데스크톱 앱·개발 도구

Landlock 리눅스 샌드박스는 예측 가능한 파일 접근 패턴을 가진 애플리케이션에 특히 잘 맞는다.

• 웹 서버
  └ /var/www/html과 /tmp만 접근 가능하도록 제한
  └ 취약점이 있어도 커널이 강제로 나머지 경로 접근을 막아줌
  
• PDF 리더, 이미지 뷰어, 문서 편집기
  └ 현재 열려 있는 파일과 임시 디렉터리 정도만 허용
  └ 데스크톱 악성 문서 공격에 대한 방어 계층으로 활용 가능
  
• FTP/HTTP 서버
  └ 정해진 루트 디렉터리와 로그 디렉터리만 접근도록 설정
  └ 공격자가 쉘을 따더라도 정책 밖의 경로는 커널이 차단
  
• 개발 도구·빌드 시스템
  └ npm·빌드 스크립트가 현재 프로젝트 디렉터리만 접근하도록 제한
  └ post-install 스크립트 악용으로 홈 디렉터리를 훑는 공격을 완화
  

Rust·Go·Haskell 등 여러 언어에서 Landlock 바인딩이 제공되고 있으며, /usr, /etc, /dev를 읽기 전용으로, /home, /tmp를 읽기/쓰기 허용하는 식의 예제 코드도 이미 공유되고 있다.

6. 리눅스 샌드박싱 현황과 Landlock의 위치

리눅스는 그동안 “상대적으로 안전하다”는 인식 덕분에 데스크톱 샌드박싱이 느리게 발전해 왔지만, 실제로는 다음과 같은 문제들이 존재한다.

• 신뢰되지 않은 바이너리를 쉽게 실행할 수 있음
• 인터넷에서 가져온 스크립트를 직접 실행하는 문화
• 비밀번호 없는 sudo 설정 등 과도한 편의성
• 일반 앱이 $HOME 내 민감한 파일에 자유롭게 접근 가능
• X11 환경에서는 키 입력 감시, 윈도우 훔쳐보기 가능
• 임의 포트 바인딩과 네트워크 통신이 넓게 허용되는 구조

컨테이너, Flatpak, Firejail 등 여러 방어 수단이 있지만, 대부분은 관리자나 배포판, 혹은 숙련된 사용자가 따로 관리해야 한다는 공통점이 있다.

Landlock 리눅스 샌드박스는 이 공백을 메우는 존재로, “개발자가 직접, 자기 애플리케이션에 샌드박스를 내장하는 방식”을 제공한다.

7. 실전 활용 사례: 텔레메트리 차단과 bwrap 샌드박스

실제 사용자 피드백에서는 Landlock 리눅스 샌드박스를 활용해 원치 않는 텔레메트리와 네트워크 연결을 차단한 사례가 언급된다.

• 특정 포트만 수신하도록 제한하고, 나머지 네트워크 연결은 모두 차단
• 파일 시스템 접근은 그대로 두고, 네트워크만 Landlock으로 제어
• dmesg에 차단된 연결 로그가 찍혀 감사(audit)용으로도 활용

또 다른 사례로, 게임 런처나 인디 게임들을 bwrap과 함께 샌드박싱하는 시도도 있다. 최소 권한으로 실행하려다 보니 설정이 까다롭지만, Landlock 기반 도구가 더 늘어나면 이런 작업이 훨씬 쉬워질 것이라는 의견이 많다.

npm 프로젝트를 격리하기 위해 bwrap을 사용한 예처럼, 기존 네임스페이스·컨테이너 기술과 Landlock을 조합하는 방향도 현실적인 활용 방식이다.

8. C API·seccomp·TCP 제한 등 기술적 논의

Landlock 리눅스 샌드박스 도입 이후, 개발자 커뮤니티에서는 다음과 같은 논의가 이어지고 있다.

• 공식 C 라이브러리 문제
  └ 커널에는 이미 Landlock 시스템 콜(uapi)이 존재하지만, └ glibc·musl 같은 표준 C 라이브러리가 아직 래퍼를 제공하지 않는다는 지적
  └ 실제로는 직접 헤더를 만들고 syscall을 호출해도 문제는 없으며, 여러 커뮤니티 래퍼와 예제 코드가 존재
• seccomp와의 상호작용
  └ seccomp 필터가 Landlock 시스템 콜을 차단할 수 있는지, 오래된 seccomp 정책이 새로운 시스템 콜에 어떤 영향을 줄지에 대한 질문
  └ 잘 작성된 seccomp 정책은 지원하지 않는 시스템 콜에 대해 -ENOSYS를 반환해 “기능 미지원”처럼 처리하므로, Landlock과 병행할 때도 이 패턴을 따르는 것이 권장됨
• 네트워크 제한 범위
  └ 현재 Landlock이 TCP 소켓만 제한하고 UDP·raw 소켓에는 직접 적용되지 않는 점을 우려하는 의견
  └ raw 소켓은 자체적으로 높은 권한이 필요하고, iptables 등으로 UID 기반 차단이 가능하다는 점에서 보완적으로 사용해야 한다는 시각

이런 논의는 Landlock 리눅스 샌드박스가 아직 진화 중인 기술이며, 다른 보안 메커니즘과 함께 종합적으로 설계해야 한다는 점을 보여준다.

9. 알려진 한계와 위협 모델

Landlock은 리눅스 샌드박스 도구로서 강력한 잠재력을 갖고 있지만, 구조적으로 감안해야 할 한계도 존재한다.

• 디렉터리 생성 관련 이슈
  └ 아직 존재하지 않는 디렉터리에 대해 규칙을 추가했을 때, 나중에 해당 디렉터리가 생성되면 접근이 차단되지 않는 사례가 보고됨
  └ 설계 상 허점이 될 수 있어 정책 설계 시 주의 필요
• 위협 모델의 범위
  └ Landlock 리눅스 샌드박스는 악성코드 자체를 봉쇄하는 도구가 아니다.
  └ 정상 애플리케이션에 취약점이 발생했을 때, 그 프로세스가 시스템 전체로 퍼지지 못하도록 자기 권한을 미리 줄여놓는 용도에 가깝다.
• 기존 MAC과의 역할 분담
  └ ~/.ssh 접근을 전역적으로 막는 것처럼 시스템 전체 정책을 다루려면 여전히 SELinux·AppArmor 같은 MAC 모델이 필요하다.
  └ Landlock 리눅스 샌드박스는 “앱이 스스로를 잠그는 API”라는 점을 기억해야 한다.

정리하면, Landlock은 기존 리눅스 보안 도구를 대체하는 것이 아니라 “정상 앱이 자기 자신을 방어하는 추가 계층”으로 이해하는 것이 맞다.

10. 엔터프라이즈·데스크톱에서의 적용 가능성

엔터프라이즈 환경에서 Landlock 리눅스 샌드박스는 다음과 같은 방식으로 활용될 수 있다.

• 고권한 데몬 프로세스의 장기 실행 시, 접근 범위를 필요한 디렉터리·포트로만 제한
• 클라우드 콘솔·SaaS·내부 도구가 브라우저 기반 인증을 사용한다면, 관련 에이전트·도구에 Landlock을 적용해 세션 탈취 가능성을 줄임
• 컨테이너 안에서도 비특권 모드에서 동작 가능하므로, 런타임 방화벽 없이 네트워크·파일 접근을 한 번 더 잠그는 용도로 사용

커널 차원에서는 향후 다음과 같은 기능이 추가·확장되는 중이다.

• Supervisor 모드: 사용자 공간에서 접근 허용/거부를 상호작용적으로 결정하는 모드
• Socket 제한 강화: 소켓 종류·포트에 대한 세밀한 제어
• TSYNC 전파 옵션: 프로세스 내 모든 스레드에 제한을 자동 전파
• 상속 제어 옵션: 상위 디렉터리 권한이 하위로 무조건 상속되지 않도록 제어

이런 기능들이 안정화되면, Landlock 리눅스 샌드박스는 리눅스 데스크톱과 엔터프라이즈 환경 모두에서 실질적인 기본 샌드박스 계층으로 자리 잡을 가능성이 있다.

11. 정리: Landlock을 어떻게 받아들여야 할까

Landlock 리눅스 샌드박스는 완벽한 만능 보안 솔루션은 아니지만, 리눅스 보안 생태계에서 오랫동안 비어 있었던 자리를 채워 주는 도구다.

• 비권한 기반, 애플리케이션 중심, 최소 권한 원칙을 따르는 샌드박스
• 기존 컨테이너·MAC·seccomp를 대체하는 것이 아니라 보완하는 계층
• 개발자가 코드 안에서 직접 Landlock을 호출해 자기 앱을 제한하는 패턴에 적합

리눅스를 개발·운영 플랫폼으로 사용하는 조직이라면, 새로운 애플리케이션 설계 단계에서부터 Landlock 리눅스 샌드박스 적용을 고려하는 것이 앞으로의 보안 수준을 한 단계 끌어올리는 좋은 출발점이 될 수 있다.