# 리눅스에 Landlock 적용하기

> Clean Markdown view of GeekNews topic #24725. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=24725](https://news.hada.io/topic?id=24725)
- GeekNews Markdown: [https://news.hada.io/topic/24725.md](https://news.hada.io/topic/24725.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-12-01T04:36:43+09:00
- Updated: 2025-12-01T04:36:43+09:00
- Original source: [blog.prizrak.me](https://blog.prizrak.me/post/landlock/)
- Points: 1
- Comments: 1

## Topic Body

- **Landlock**은 애플리케이션이 접근 가능한 리소스를 명시적으로 선언해, 커널 수준에서 **자체 샌드박싱**을 수행하도록 하는 **리눅스 보안 API**임  
- 기존 **SELinux**나 **AppArmor**보다 단순하며, **개발자 권한 없이** 런타임에 정책을 생성하고 적용할 수 있음  
- 정책은 접근 가능한 파일·디렉터리·포트 등을 **명시적 허용 목록(allowlist)** 형태로 정의하며, **계층적 제한**을 통해 점진적 보안 강화 가능  
- **Rust, Go, Haskell** 등에서 바인딩이 제공되며, GUI 앱·서버·데스크톱 프로세스 등 다양한 환경에서 **세분화된 접근 제어** 구현 가능  
- 리눅스 보안 생태계에서 **간단하고 실용적인 무권한 샌드박스 도구**로서, 향후 **데스크톱 보안 강화의 핵심 구성요소**로 주목받고 있음   
  
---  
  
### Landlock 개요  
- **Landlock**은 리눅스 애플리케이션이 자신이 접근할 수 있는 리소스를 명시적으로 선언하도록 하는 **API**  
  - OpenBSD의 `unveil()` 및 `pledge()` 개념과 유사하며, “필요한 리소스만 허용하고 나머지는 차단”하는 원칙 기반  
- 기존 리눅스 보안 메커니즘보다 이해와 통합이 쉬운 **개발자 친화적 방어 계층** 제공  
- 목적은 접근 가능한 소개와 함께 **Landlock 사용을 장려**하는 것임  
  
### 작동 방식  
- **Linux Security Module(LSM)** 형태로, **Linux 5.13**부터 사용 가능  
- **SELinux**나 **AppArmor**와 달리, **프로세스 단위의 일시적 제한(transient restriction)** 적용  
  - 정책은 런타임에 생성되어 현재 스레드 및 자식 프로세스에만 적용되고, 프로세스 종료 시 사라짐  
- 정책 구성 요소  
  1. **Handled accesses**: 제한할 작업 범주(예: 파일시스템 읽기/쓰기)  
  2. **Access grants**: 허용할 객체의 명시적 목록  
- 예시 정책  
  - `/home/user` 읽기 전용  
  - `/tmp` 읽기/쓰기  
  - 포트 `2222` 바인딩 허용  
- `landlock_restrict_self()` 호출 시 해당 스레드와 자식 프로세스가 **영구적으로 제한 영역**에 진입  
  - 제한은 **해제 불가**, 최대 **16개 계층(layer)** 중첩 가능  
  - 하위 계층은 접근을 더 줄일 수 있으나, 상위 계층에서 제거된 권한은 복원 불가  
- **비권한(unprivileged)** 방식으로, 일반 애플리케이션도 자체 샌드박싱 가능  
- **ABI 버전 관리**를 통해 구형 커널에서도 가능한 범위 내에서 동작  
- **Stackable LSM**으로, SELinux나 AppArmor와 병행 사용 가능  
  
### 사용 이유  
- **예측 가능한 파일 접근 패턴**을 가진 애플리케이션에 적합  
  - 예: 웹 서버가 `/var/www/html`과 `/tmp`만 접근하도록 제한  
- **관리자 개입이나 시스템 전역 설정 불필요**, 코드 내에서 직접 정책 정의 가능  
- **권한 상승 없이 사용 가능**, 대부분의 프로그램에 손쉽게 통합 가능  
- **Rust, Go, Haskell**용 바인딩 존재, `unveil` 스타일의 래퍼 프로젝트도 다수  
- 공식 C 라이브러리는 아직 없으나, 여러 비공식 구현 사용 가능  
- Rust 예시 코드에서는 `/usr`, `/etc`, `/dev`를 읽기 전용으로, `/home`, `/tmp`를 읽기/쓰기 가능하도록 설정  
  
### 리눅스 샌드박싱 현황과 필요성  
- 리눅스 사용 증가와 함께 **데스크톱 대상 악성코드**도 증가  
- 리눅스의 상대적 안전성은 **시장 점유율과 기술 장벽** 덕분이지, 구조적 안전성 때문은 아님  
- 일반 배포판의 문제점  
  - 신뢰되지 않은 바이너리 실행 가능  
  - 인터넷에서 스크립트를 직접 실행 가능  
  - 비밀번호 없는 sudo 사용  
  - 일반 애플리케이션이 `$HOME` 내 민감 파일 접근 가능  
  - X11 환경에서 키 입력 감시 가능  
  - 임의 포트 바인딩 가능  
  
#### 기존 보안 도구의 한계  
- **Containerization (Docker, Podman)** : 서비스 격리에 적합하지만 데스크톱 앱에는 부적합, `--privileged` 옵션으로 격리 무력화 사례 존재  
- **Flatpak / Snap**: GUI 앱에 적합하나 권한 범위 과도, CLI 도구에는 부적합  
- **Firejail**: 앱별 프로파일 필요, 매 실행 시 명시적 호출 필요  
  
#### 개발자 관점의 기존 메커니즘  
- **seccomp**: 강력하지만 설정이 복잡하고 블랙리스트 방식은 취약  
- **SELinux**: 강력하지만 복잡하며 관리자 정책 필요, 기본 비활성화된 배포판 다수  
- **AppArmor**: SELinux보다 단순하지만 여전히 관리자 프로파일 필요, 일부 배포판에서 비활성화  
  
#### Landlock의 장점 요약  
- **비권한**, **애플리케이션 중심**, **통합 용이**, **기본 차단(deny-by-default)**  
- **Linux 5.13 이후 광범위 지원**, **하위/상위 호환성 유지**  
- 완벽하지는 않지만, **단순하고 독립적인 무권한 샌드박스 도구**로서 공백을 메움  
  
### Landlock의 적용 가능성  
- **고권한 데몬 프로세스**의 장기 실행 시, Landlock으로 접근 범위 제한 가능  
- **PDF 리더, 이미지 뷰어, 웹 브라우저, 워드 프로세서** 등은 열린 파일만 접근하도록 제한 가능  
- **FTP/HTTP 서버**는 필요한 파일만 접근하도록 설정 가능  
  - 예: nginx가 root로 실행 중이라도 공격자가 쉘을 획득해도 정책 외 파일 접근 불가  
- **Supervisor 제안**이 도입되면, **안드로이드 유사 권한 시스템**을 리눅스 데스크톱에 구현 가능  
  - GUI 및 권한 저장 시스템과 결합 시, **보다 안전한 사용자 경험** 실현 가능  
  
### Landlock의 진행 중 기능 개발  
- **Supervise Mode**: 사용자 공간에서 접근 허용/거부를 상호작용적으로 결정, 안드로이드식 권한 프롬프트 유사  
- **Socket Restrictions**: 프로세스가 사용할 수 있는 소켓 종류·포트에 대한 세밀한 제어  
- **LANDLOCK_RESTRICT_SELF_TSYNC**: 제한을 프로세스 내 모든 스레드에 전파  
- **LANDLOCK_ADD_RULE_QUIET**: 특정 객체에 대한 감사 로그 메시지 억제  
- **LANDLOCK_ADD_RULE_NO_INHERIT**: 상위 디렉터리 권한이 하위로 상속되지 않도록 방지, 파일시스템 제어 세분화  
  
### 요약  
- **Landlock**은 단순하고 비권한 기반의 **기본 차단형 샌드박스 메커니즘**  
- 이해와 통합이 용이하며, **리눅스 데스크톱 및 애플리케이션 보안 향상**에 큰 잠재력 보유  
- 개발자는 애플리케이션에 Landlock을 직접 적용해 **보안 수준을 강화**할 수 있음

## Comments



### Comment 46998

- Author: neo
- Created: 2025-12-01T04:36:44+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=46090969) 
- 나는 **Landlock**를 이용해 원치 않는 텔레메트리를 차단했음  
  C로 간단한 프로그램을 작성해 특정 포트 하나만 수신하도록 하고, 나머지 네트워크 연결은 모두 차단했음  
  [`sandboxer.c` 예제](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c)를 참고했으며, 파일 접근 제한은 건드리지 않고 네트워크만 제어함  
  `dmesg`에서 차단된 연결이 표시되는데, 아마 **audit 기능** 덕분인 듯함  
  이 도구는 **비특권 사용자 모드**에서 작동하고, 컨테이너 안에서도 방화벽 설정 없이 잘 동작함  
  단, 악의적인 프로그램을 완전히 막는 용도로는 적합하지 않다고 생각함
  - 소스 코드를 공유해줄 수 있는지 궁금함
- Landlock이 완벽하진 않음  
  [이슈 #28](https://github.com/landlock-lsm/linux/issues/28)과 [관련 메일 스레드](https://lore.kernel.org/all/CAG48ez1O0VTwEiRd3KqexoF78WR+cmP5bGk5Kh5Cs7aPepiDVg@mail.gmail.com/)를 보면, 샌드박스 규칙이 **존재하지 않는 디렉터리**를 참조할 수 없다는 문제가 있음  
  예를 들어 `~/.ssh`가 아직 없을 때 규칙을 추가하면, 나중에 디렉터리가 생성되더라도 접근이 차단되지 않음  
  즉, 보안적으로 허점이 생길 수 있음
- 나는 itch.io 게임들을 **bwrap**으로 샌드박싱해보는 중임  
  최소 권한으로 실행하려니 꽤 까다로움  
  “Microlandia”는 실행이 안 되지만, 다른 Unity 게임들은 잘 돌아감  
  Landlock 기반 도구들이 더 많아져서 이런 작업이 쉬워지길 기대함  
  - [bubblewrap 프로젝트](https://github.com/containers/bubblewrap)  
  - [내 실행 스크립트 예시](https://codeberg.org/dannyfritz/dotfiles/src/commit/383430085660a7af936c93344d6499c24e028cae/bin/run-game)  
  - [Microlandia 게임 페이지](https://explodi.itch.io/microlandia)
  - 나도 npm 프로젝트를 격리하려고 bwrap을 써봤음  
    ```
    bwrap --unshare-pid --dev-bind / / --tmpfs /home --bind "$(pwd)" "$(pwd)" bash
    ```  
    꽤 잘 작동하지만, **네트워크 네임스페이스**를 미리 지정할 수 있으면 좋겠다는 생각이 듦
- 컨테이너 런타임에서 Landlock의 **지원 상태**가 궁금함  
  CRI들이 자체 인터페이스를 정의하려는 것 같지만, 커널 지원보다 항상 늦을 수밖에 없음  
  대부분의 인프라 담당자가 앱별로 샌드박스 정책을 유지보수하진 않을 것 같음  
  애플리케이션이 직접 Landlock을 사용하는 게 더 현실적이라고 봄
  - [runc 이슈](https://github.com/opencontainers/runc/issues/2859), [runtime-spec 이슈](https://github.com/opencontainers/runtime-spec/issues/1110)를 언급하며,  
    런타임이 시스템 콜을 그냥 통과시키면 앱이 스스로 잠그는 걸 **신뢰해야 하는 문제**가 생긴다고 설명함
  - Landlock은 원래 **컨테이너 런타임용**이 아니라, 다른 목적을 가진 기능이라고 생각함
- 의료기기 개발자로서 이런 접근이 매우 반가움  
  내부적으로 비슷한 API를 사용해 **중요 프로세스 관리**를 하고 있음  
  이런 연구가 규제 산업에도 큰 도움이 될 것임
- “공식 C 라이브러리가 없다”는 말이 이상하게 들림  
  커널 기능이라면 당연히 C API가 먼저일 텐데 왜 없는지 궁금함
  - 커널의 기본 인터페이스는 **syscall(uapi)** 임  
    libc는 그 위에 얹힌 계층일 뿐이고, 아직도 많은 syscall이 libc에 래퍼 없이 존재함
  - 여기서 말하는 건 glibc나 musl 같은 **표준 C 라이브러리**를 의미함  
    직접 헤더를 만들어 `_syscallN` 매크로로 호출할 수도 있음
  - C API가 없어도 큰 문제는 없음  
    [landbox](https://codeberg.org/git-bruh/landbox) 같은 간단한 래퍼를 쓰면 되고,  
    Rust나 Go도 C FFI를 노출할 수 있음  
    커널의 [sandboxer.c 예제](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/samples/landlock/sandboxer.c)를 참고하면 충분함
  - [man7 문서](https://man7.org/linux/man-pages/man7/landlock.7.html)에 대부분의 내용이 정리되어 있음
  - 커널 개발자는 **유저랜드 소프트웨어**를 직접 만들지 않기 때문에 C API가 없는 것임
- Landlock이 TCP 소켓만 제한하고, **UDP나 raw 소켓**은 막지 않는다는 점에 주의해야 함
  - 그건 꽤 큰 **보안 허점**처럼 보임. 이유가 뭘까 궁금함
  - raw 소켓은 권한이 필요하고, **iptables**로 UID 기반 차단도 가능함  
    Landlock과는 다르지만 보완적으로 쓸 수 있음
  - 그래도 꽤 큰 구멍처럼 느껴짐
  - 이상한 제약이지만, 알아둬서 다행임
- Landlock이 `/sys` 설정 대신 **새로운 syscall**을 추가한 게 흥미로움  
  아마 **비특권 원칙** 때문일 것임  
  seccomp로 Landlock syscall을 차단할 수 있는지도 궁금함  
  오래된 seccomp 정책이 Landlock 번호를 포함하지 않으면 SIGSYS가 날 수도 있지 않을까?
  - 다른 LSM들도 점점 syscall 기반으로 전환 중임  
    파일시스템 기반 API는 **footgun**이 많고, dirfd 기반 접근 제어엔 syscall이 더 적합함  
    잘 작성된 seccomp 필터는 -ENOSYS를 반환해서 단순히 “지원 안 함”처럼 보이게 함
  - seccomp로 Landlock syscall을 제한할 수는 있지만, 실용성은 낮음  
    Landlock은 기존 권한을 더 제한할 뿐, 새 권한을 부여하지 않기 때문임
- 나는 이제 막 리눅스 보안에 관심을 가지기 시작했음  
  맥에서 벗어나 리눅스로 완전히 옮기려 준비 중인데, **malware 방어**에 Landlock이 어떤 도움이 되는지 궁금함  
  예를 들어 `~/.ssh` 접근을 자동으로 거부하는 환경을 만들고 싶음  
  또, 이걸로 **앱 런처**를 만들 수 있는지도 알고 싶음
  - Landlock의 위협 모델은 **악성코드 자체**가 아니라, 정상 앱의 **코드 실행 취약점**임  
    앱이 스스로 필요 없는 권한을 제한해 공격자가 시스템을 장악하지 못하게 하는 용도임
  - `~/.ssh` 접근 차단 같은 건 **AppArmor**나 **SELinux** 같은 MAC 모델이 필요함  
    Landlock은 앱이 스스로 혹은 자식 프로세스를 제한할 때 유용함  
    예를 들어 npm이 post-install 스크립트를 빌드 디렉터리로만 제한하는 식임  
    OpenBSD의 **pledge**처럼 앱 개발자가 직접 사용하는 API임  
    다만 Linux는 생태계가 분산되어 있어 적용이 느릴 것임  
    그동안은 **래퍼나 런처** 형태로 쓰는 게 현실적임  
  - 패키지 매니저가 빌드 스크립트용 정책을 지정하거나, 사용자가 직접 래퍼를 써야 함  
    결국 **프로그램이 자기 권한을 아는 경우**에만 효과적임
  - macOS와 iOS의 **sandboxing**과 거의 동일한 개념임  
    앱이 실행 초기에 필요한 리소스만 화이트리스트로 지정하고 나머지는 차단함  
    악성 프로그램 방어용이 아니라, **자기 프로세스 보호용**임
- “공식 C 라이브러리가 없다”는 말이 웃기게 들림  
  이미 표준 라이브러리에 syscall이 있는데, 굳이 별도 라이브러리가 필요한가?  
  [man7 문서](https://man7.org/linux/man-pages/man7/landlock.7.html)도 존재함  
  단순히 **추상화 계층**을 원한다는 뜻인지 궁금함
  - libc가 syscall 번호 관리나 부수 효과를 처리해주는 역할을 하므로,  
    glibc가 아직 Landlock 인터페이스를 제공하지 않는 건 의외임  
    아마 **비리눅스 호환성** 문제 때문일 것 같음