Kernel Lockdown LSM은 root조차 실행 중인 커널을 수정하지 못하게 막는 리눅스 보안 모듈입니다. Linux 6.17에서 5.4 이후 처음으로 정식 메인테이너를 확보하며 다시 활발히 개발되기 시작했습니다. 두 모드 차이, Secure Boot 연동, KSPP Kconfig, MOK 서명까지 실전 예제로 정리.
업데이트: 2026년 7월 19일
Kernel Lockdown LSM은 root 권한과 커널 메모리 사이에 명확한 경계를 강제하는 리눅스 보안 모듈로, 활성화되면 root조차 실행 중인 커널을 수정하거나 커널 내부의 기밀 정보를 추출할 수 없습니다. Linux 5.4에서 도입된 이후 오랫동안 유지보수가 정체되어 있었으나, Linux 6.17에서 Nicolas Bouchinet과 Xiu Jianfeng이 새로운 메인테이너로 합류하면서 다시 활발하게 개발되기 시작했습니다. 이 글은 커널 Lockdown LSM의 두 가지 모드(integrity/confidentiality), Secure Boot와의 연동, 부팅 파라미터와 sysfs를 통한 활성화 방법, KSPP 권장 Kconfig까지 커널 6.17 기준으로 정리합니다.
none, integrity, confidentiality의 세 상태를 가지며 /sys/kernel/security/lockdown에서 확인할 수 있습니다.none → integrity → confidentiality로만 진행되고 되돌릴 수 없습니다.integrity로 강제하는 경우가 많습니다.CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y와 CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y 조합을 권장합니다.Kernel Lockdown은 "root와 커널 코드 실행 권한의 구분"을 강제하기 위해 만들어진 Linux Security Module입니다. 전통적으로 리눅스에서 root는 사실상 커널과 같은 신뢰 수준을 가졌습니다. /dev/mem에 직접 쓰거나, 서명되지 않은 모듈을 로드하거나, kexec으로 임의 이미지를 부팅하거나, MSR에 값을 쓰는 방식으로 root는 언제든 커널 메모리에 임의 코드를 주입할 수 있었죠. Lockdown LSM은 이 경로들을 정책적으로 차단합니다. UEFI Secure Boot로 부팅 체인의 무결성을 보장했다면, Lockdown은 부팅 이후 실행 중인 커널의 무결성을 지키는 보완적 계층입니다.
구조적으로 Lockdown은 다른 LSM(SELinux, AppArmor, Yama 등)과 함께 LSM 스택에 등록됩니다. 초기화 순서는 lsm= 커맨드라인 파라미터 혹은 CONFIG_LSM으로 결정되며, Lockdown은 kmalloc()이 호출 가능해지기 전에 매우 이른 시점에 활성화되어야 하기 때문에 순서를 정확히 지정해야 합니다. 저는 실무에서 커스텀 커널을 빌드할 때 항상 lockdown을 첫 번째로 두는 습관을 들였습니다. 초기 부팅 중 발생하는 위험 동작(예: 조기 kexec)을 놓치지 않기 위함입니다.
Lockdown LSM은 Linux 5.4에서 병합된 이후 사실상 유지보수가 없는 상태였습니다. 버그가 발견되어도 담당자가 없어 반영이 늦어지거나, 새로 등장한 커널 경로(예: BPF의 새 기능)에 Lockdown 훅이 추가되지 않는 문제가 이어졌죠. 2026년 8월에 태그된 Linux 6.17에서는 두 가지 큰 변화가 있습니다.
ORPHAN에서 정식 유지보수 상태로 바뀌었습니다. 5.4 이후 처음입니다.같은 사이클에서 SELinux에는 neveraudit 플래그가 추가되어 permissive 배포에서 audit 로그 스팸을 줄일 수 있게 되었습니다. 세 LSM(Lockdown, AppArmor, SELinux)이 동시에 진전을 낸 것은 오랜만입니다. 저처럼 매년 kernel 릴리스 노트를 훑는 사람에게 6.17은 "LSM 부활" 릴리스로 기억될 겁니다.
이 두 모드는 자주 혼동되지만, 위협 모델이 다릅니다. Integrity는 "root가 커널을 수정하지 못하게" 만들고, Confidentiality는 여기에 "root가 커널로부터 정보를 뽑아가지 못하게"를 더합니다.
| 기능 | none | integrity | confidentiality |
|---|---|---|---|
| 서명되지 않은 모듈 로드 | 허용 | 차단 | 차단 |
| kexec으로 서명되지 않은 이미지 부팅 | 허용 | 차단 | 차단 |
| hibernation (swap 암호화 없음) | 허용 | 차단 | 차단 |
/dev/mem, /dev/kmem, /dev/port 접근 | 허용 | 차단 | 차단 |
MSR 쓰기 (/dev/cpu/*/msr) | 허용 | 차단 | 차단 |
커널 메모리 읽기 (/proc/kcore) | 허용 | 허용 | 차단 |
| BPF로 커널 메모리 dump | 허용 | 허용 | 차단 |
| kprobes / 특정 tracepoint 기반 정보 노출 | 허용 | 허용 | 차단 |
| 커스텀 ACPI 테이블 로드 | 허용 | 차단 | 차단 |
서버 워크로드에서 저는 integrity를 기본값으로 권장합니다. Confidentiality는 perf·bpftrace·kprobes를 강하게 제한하기 때문에 관측 스택이 함께 무력화됩니다. FIPS/CC 인증 환경, 부팅 후 원격 attestation이 필요한 IoT 게이트웨이, 하드웨어 보안 모듈을 다루는 서버라면 Confidentiality가 정답이지만, 일반 애플리케이션 서버에서 Confidentiality를 켜면 관측성 팀에서 하루 안에 롤백 요청이 옵니다.
한 가지 중요한 특성은 단방향 래칫(one-way ratchet)입니다. 부팅 중 none이었다면 integrity로 올릴 수 있고, integrity였다면 confidentiality로 올릴 수 있지만, 반대 방향은 재부팅 없이 불가능합니다. 이는 정책 다운그레이드 공격을 원천 봉쇄하기 위한 설계입니다.
활성화 경로는 세 가지입니다. 부팅 파라미터, sysfs, Kconfig(빌드 시). 실무에서 저는 세 가지를 조합해서 씁니다.
GRUB을 쓰는 배포판이라면 /etc/default/grub의 GRUB_CMDLINE_LINUX에 다음을 추가합니다.
# /etc/default/grub
GRUB_CMDLINE_LINUX="lockdown=integrity lsm=lockdown,integrity,yama,apparmor,bpf"변경 후 부트로더를 재생성해야 반영됩니다.
# Debian/Ubuntu
sudo update-grub
# Fedora/RHEL
sudo grub2-mkconfig -o /boot/grub2/grub.cfgLockdown은 언제든 더 엄격한 상태로만 승격할 수 있습니다. 현재 상태 확인과 승격은 다음과 같습니다.
# 현재 상태 확인 (괄호 안이 활성 상태)
cat /sys/kernel/security/lockdown
# 예: none [integrity] confidentiality
# integrity → confidentiality 승격 (root 권한 필요)
echo confidentiality | sudo tee /sys/kernel/security/lockdown
# 다운그레이드는 실패합니다
echo none | sudo tee /sys/kernel/security/lockdown
# tee: /sys/kernel/security/lockdown: Operation not permitted커스텀 커널을 빌드한다면 다음 옵션을 세팅해 부트로더 조작으로도 상태를 낮출 수 없게 만들 수 있습니다.
# .config 발췌
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
# 아래 셋 중 정확히 하나만 선택
# CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
# CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY=y
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y
# LSM 순서 (lockdown이 반드시 포함되어야 함)
CONFIG_LSM="landlock,lockdown,yama,integrity,apparmor,bpf"Cloudflare의 프로덕션 커널 하드닝 문서가 이 접근을 잘 설명합니다. 그들은 부트로더 조작 리스크를 낮추기 위해 FORCE_INTEGRITY를 컴파일 타임에 못박아둡니다. 인프라 팀이 부트 파라미터를 실수로 지워도 Lockdown이 꺼지지 않는다는 뜻입니다.
결론부터: 가능합니다. Lockdown과 Secure Boot는 독립적인 계층입니다. 다만 Secure Boot가 활성화되어 있으면 Fedora, RHEL, Ubuntu, Debian 같은 주요 배포판이 자동으로 Lockdown을 integrity로 설정합니다. shim → GRUB → 커널의 서명 체인이 확인된 상태에서 root가 사후에 커널 무결성을 깨는 것을 방지하려는 정책적 결합입니다.
반대로 Secure Boot 없이 Lockdown만 활성화하는 시나리오도 흔합니다. 예를 들어 자체 서명 UEFI 키가 없는 온프렘 서버, coreboot 기반 하드웨어, 컨테이너 호스트 등에서 부트 이후 root의 커널 조작 경로만 막고 싶은 경우입니다. 이때는 앞서 본 lockdown=integrity 파라미터로 충분합니다. Lockdown 자체가 부트 파라미터 무결성을 보장하지는 못한다는 점만 기억하세요. 그 부분은 measured boot 또는 remote attestation의 영역입니다.
운영 관점에서는 방화벽·서비스 계층 하드닝과 함께 배치할 때 시너지가 큽니다. 저는 systemd 서비스 샌드박싱과 nftables 방화벽 하드닝을 먼저 완료한 뒤 Lockdown을 올리는 순서를 선호합니다. 애플리케이션 레벨 침해가 있어도 커널 무결성 계층까지는 뚫기 어렵게 만드는 방어 심층화 전략입니다.
Lockdown 훅은 커널 트리 곳곳에 흩어져 있어 전체 목록을 유지하기가 쉽지 않습니다. 다행히 kernel_lockdown(7) man 페이지에 릴리스별로 정리되어 있습니다. Linux 6.17 기준으로 자주 부딪히는 항목을 정리했습니다.
kexec_load()(레거시)는 완전 차단, kexec_file_load()는 서명 검증 후 허용됩니다.acpi_rsdp, 커스텀 SSDT 삽입 등이 차단됩니다.msr 모듈, io_uring의 특정 opcode가 영향을 받습니다.bpf_probe_write_user는 integrity에서, bpf_probe_read_kernel의 일부 사용 패턴은 confidentiality에서 제한됩니다. eBPF 기반 관측 스택을 쓴다면 이 부분을 반드시 사전 테스트하세요.커널 로그에는 다음과 같은 메시지가 남습니다. 트러블슈팅의 첫 단서입니다.
$ dmesg | grep -i lockdown
[ 1.234567] Kernel is locked down from EFI Secure Boot mode; see man kernel_lockdown.7
[ 842.512044] Lockdown: nvidia: unsigned module loading is restricted; see man kernel_lockdown.7Linux Kernel Self-Protection Project(KSPP)는 Lockdown 외에도 수십 개의 하드닝 옵션을 권장합니다. 저는 새 커널을 빌드할 때마다 Alexander Popov의 kernel-hardening-checker로 확인합니다. Kconfig, 커맨드라인, sysctl 세 축을 모두 검사해 주는 유일한 도구입니다.
# 설치 (Python 3.7+)
pip3 install --user kernel-hardening-checker
# 현재 실행 중인 커널의 하드닝 상태 종합 점검
sudo kernel-hardening-checker \
-c /boot/config-$(uname -r) \
-l /proc/cmdline \
-s /proc/sys
# Lockdown 관련 라인만 필터
sudo kernel-hardening-checker \
-c /boot/config-$(uname -r) \
-l /proc/cmdline | grep -i lockdownLockdown과 함께 적용하면 효과가 큰 KSPP 권장 sysctl은 다음과 같습니다.
# /etc/sysctl.d/99-kspp-hardening.conf
# kexec 아예 봉인 (Lockdown과 중복이지만 이중 방어)
kernel.kexec_load_disabled = 1
# 전체 ASLR
kernel.randomize_va_space = 2
# 모든 PTRACE_ATTACH 차단
kernel.yama.ptrace_scope = 3
# 사용자 네임스페이스 봉인 (컨테이너 런타임이 없다면)
user.max_user_namespaces = 0
# TTY 라인 디시플린 자동 로딩 차단 (CVE-2017-2636 계열)
dev.tty.ldisc_autoload = 0적용 후 sudo sysctl --system으로 반영합니다. 컨테이너 호스트라면 user.max_user_namespaces = 0은 빼야 합니다. runc·Podman이 rootless 모드에서 사용 불가가 됩니다.
Lockdown을 켰을 때 90%의 실운영 이슈는 서명되지 않은 모듈 로드 실패입니다. 특히 NVIDIA 드라이버, VirtualBox, ZFS on Linux, 사내 자체 모듈이 문제가 됩니다. 두 가지 해결책이 있습니다.
Secure Boot·Lockdown을 유지하면서 특정 모듈을 신뢰하는 방법입니다.
# 1. 자체 서명용 키 쌍 생성
openssl req -new -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
-subj "/CN=MyOrg Module Signing/" \
-keyout MOK.priv -out MOK.der -outform DER
# 2. MOK에 공개키 등록 (재부팅 후 shim에서 승인 필요)
sudo mokutil --import MOK.der
# 3. 모듈 서명
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file \
sha256 MOK.priv MOK.der /lib/modules/$(uname -r)/extra/nvidia.ko
# 4. 로드 시도
sudo modprobe nvidia
dmesg | tail -5Debian/Ubuntu에서는 /etc/dkms/framework.conf.d/에 서명 스크립트를 등록하면 DKMS가 모듈을 빌드할 때마다 자동으로 서명합니다.
# /etc/dkms/framework.conf.d/mok-signing.conf
sign_tool="/etc/dkms/sign_helper.sh"#!/bin/sh
# /etc/dkms/sign_helper.sh
/usr/src/linux-headers-$(uname -r)/scripts/sign-file \
sha256 /root/MOK.priv /root/MOK.der "$@"스크립트에 실행 권한을 부여하고 (chmod +x) MOK 개인키의 파일 권한을 0600으로 제한하세요. 프로덕션에서는 개인키를 호스트에 두지 말고 HSM 또는 원격 서명 서비스로 옮기는 것을 권장합니다.
모듈 로드 오류가 계속된다면 keyctl list %:.builtin_trusted_keys와 keyctl list %:.platform으로 커널이 인식하는 키 목록을 확인합니다. MOK로 등록한 키는 .platform 키링에 나타나야 정상입니다.
파일 시스템 소유·프로세스 시그널·네트워크 설정·서비스 관리 등 모든 userspace 권한은 그대로 유지됩니다. 사라지는 것은 커널 메모리·모듈·펌웨어를 통해 커널 실행 컨텍스트로 진입하는 경로뿐입니다. 즉 시스템 관리는 정상적으로 가능하지만, root가 커널 자체를 재프로그래밍할 수는 없습니다.
네, LSM 스택 프레임워크가 도입된 이후 여러 LSM을 동시에 활성화할 수 있습니다. CONFIG_LSM 문자열에 lockdown,yama,apparmor,bpf 순으로 나열하면 됩니다. 서로 다른 계층(커널 무결성 vs. MAC 정책)을 담당하기 때문에 중복이 아니라 상호 보완입니다.
둘 다 함께 쓰는 것이 안전합니다. kexec_load_disabled=1은 kexec 호출 자체를 봉인하고, Lockdown은 서명되지 않은 이미지의 kexec 부팅만 막습니다. 라이브 마이그레이션이나 kdump 크래시 덤프를 쓴다면 kexec을 완전히 봉인할 수 없으므로 Lockdown의 서명 검증에 의존하게 됩니다.
완전히 잃지는 않습니다. 프로세스 단위 perf stat, ps, vmstat 같은 도구는 정상 동작합니다. 잃는 것은 커널 메모리 덤프에 접근하는 perf record -a --call-graph=dwarf, /proc/kcore 기반 크래시 분석, kprobes로 커널 함수 파라미터를 읽는 스크립트입니다. Tetragon처럼 정책 기반으로 필터링하는 도구는 대체로 문제없이 동작합니다.
/sys/kernel/security/lockdown을 노드 익스포터로 긁어 Prometheus에 올리는 것이 가장 간단합니다. 또한 dmesg에서 Lockdown:으로 시작하는 라인은 정책 위반 시도를 나타내므로, 이를 SIEM으로 포워딩하면 root 권한 남용 시도를 조기 탐지할 수 있습니다.
재부팅해서 lockdown=none으로 진입하는 것이 원칙입니다. 단방향 래칫 특성상 런타임 다운그레이드가 불가능하기 때문입니다. 프로덕션에서 이 절차가 부담스럽다면, 스테이징 노드에 별도의 debug 커널(Kconfig에서 FORCE_NONE)을 준비해두고 문제 재현용으로만 사용하는 패턴이 실용적입니다.