▲

리눅스에 Landlock 적용하기

 (blog.prizrak.me)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 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을 직접 적용해 보안 수준을 강화할 수 있음
▲
GN⁺ 4일전  [-]
Hacker News 의견
  • 나는 Landlock를 이용해 원치 않는 텔레메트리를 차단했음
    C로 간단한 프로그램을 작성해 특정 포트 하나만 수신하도록 하고, 나머지 네트워크 연결은 모두 차단했음
    sandboxer.c 예제를 참고했으며, 파일 접근 제한은 건드리지 않고 네트워크만 제어함
    dmesg에서 차단된 연결이 표시되는데, 아마 audit 기능 덕분인 듯함
    이 도구는 비특권 사용자 모드에서 작동하고, 컨테이너 안에서도 방화벽 설정 없이 잘 동작함
    단, 악의적인 프로그램을 완전히 막는 용도로는 적합하지 않다고 생각함
    • 소스 코드를 공유해줄 수 있는지 궁금함
  • Landlock이 완벽하진 않음
    이슈 #28과 관련 메일 스레드를 보면, 샌드박스 규칙이 존재하지 않는 디렉터리를 참조할 수 없다는 문제가 있음
    예를 들어 ~/.ssh가 아직 없을 때 규칙을 추가하면, 나중에 디렉터리가 생성되더라도 접근이 차단되지 않음
    즉, 보안적으로 허점이 생길 수 있음
  • 나는 itch.io 게임들을 bwrap으로 샌드박싱해보는 중임
    최소 권한으로 실행하려니 꽤 까다로움
    “Microlandia”는 실행이 안 되지만, 다른 Unity 게임들은 잘 돌아감
    Landlock 기반 도구들이 더 많아져서 이런 작업이 쉬워지길 기대함
  • 컨테이너 런타임에서 Landlock의 지원 상태가 궁금함
    CRI들이 자체 인터페이스를 정의하려는 것 같지만, 커널 지원보다 항상 늦을 수밖에 없음
    대부분의 인프라 담당자가 앱별로 샌드박스 정책을 유지보수하진 않을 것 같음
    애플리케이션이 직접 Landlock을 사용하는 게 더 현실적이라고 봄
    • runc 이슈, runtime-spec 이슈를 언급하며,
      런타임이 시스템 콜을 그냥 통과시키면 앱이 스스로 잠그는 걸 신뢰해야 하는 문제가 생긴다고 설명함
    • Landlock은 원래 컨테이너 런타임용이 아니라, 다른 목적을 가진 기능이라고 생각함
  • 의료기기 개발자로서 이런 접근이 매우 반가움
    내부적으로 비슷한 API를 사용해 중요 프로세스 관리를 하고 있음
    이런 연구가 규제 산업에도 큰 도움이 될 것임
  • “공식 C 라이브러리가 없다”는 말이 이상하게 들림
    커널 기능이라면 당연히 C API가 먼저일 텐데 왜 없는지 궁금함
    • 커널의 기본 인터페이스는 syscall(uapi) 임
      libc는 그 위에 얹힌 계층일 뿐이고, 아직도 많은 syscall이 libc에 래퍼 없이 존재함
    • 여기서 말하는 건 glibc나 musl 같은 표준 C 라이브러리를 의미함
      직접 헤더를 만들어 _syscallN 매크로로 호출할 수도 있음
    • C API가 없어도 큰 문제는 없음
      landbox 같은 간단한 래퍼를 쓰면 되고,
      Rust나 Go도 C FFI를 노출할 수 있음
      커널의 sandboxer.c 예제를 참고하면 충분함
    • man7 문서에 대부분의 내용이 정리되어 있음
    • 커널 개발자는 유저랜드 소프트웨어를 직접 만들지 않기 때문에 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 문서도 존재함
    단순히 추상화 계층을 원한다는 뜻인지 궁금함
    • libc가 syscall 번호 관리나 부수 효과를 처리해주는 역할을 하므로,
      glibc가 아직 Landlock 인터페이스를 제공하지 않는 건 의외임
      아마 비리눅스 호환성 문제 때문일 것 같음
답변달기