커널 보안 (Kernel Security)

커널 보안을 공격 표면 축소와 권한 경계 강제 관점에서 종합적으로 심층 분석합니다. LSM 프레임워크와 SELinux/AppArmor/Landlock 정책 모델, seccomp-bpf 시스템 콜(System Call) 필터링, credentials·capabilities 권한 체계, namespace/cgroup와 결합한 격리(Isolation) 강화, KASLR/SMEP/SMAP/CFI 등 하드닝 기법, Audit·trace 기반 침해 추적, 컨테이너(Container)·서버 운영에서의 정책 배포와 예외 처리, 성능과 보안의 균형점을 찾는 실무 전략까지 다룹니다.

커널 보안 아키텍처 개요

Linux 커널의 보안 모델은 전통적인 DAC(Discretionary Access Control)에서 출발하여, MAC(Mandatory Access Control), 그리고 이를 유연하게 지원하는 LSM(Linux Security Modules) 프레임워크로 발전해왔습니다. 커널 보안은 하드웨어, 커널, 사용자 공간의 3계층 구조로 이루어져 있으며, 각 계층이 독립적이면서도 상호 보완적인 방어선을 형성합니다.

보안 계층 구조

리눅스 보안은 종심 방어(Defense in Depth) 원칙에 따라 여러 계층의 보안 메커니즘이 중첩되어 동작합니다. 한 계층이 우회되더라도 다음 계층에서 공격을 차단할 수 있도록 설계되어 있습니다.

커널 보안 모델의 핵심 원칙

리눅스 커널 보안은 다음 세 가지 핵심 원칙을 기반으로 합니다:

보안 메커니즘 종합

security/ 소스 트리 구조

접근 제어 메커니즘 상세

리눅스 커널의 접근 제어는 DAC → Capabilities → MAC → seccomp의 4단계로 구성됩니다. 각 단계는 이전 단계를 보완하며, 시스템 콜 처리 경로에서 순차적으로 검사됩니다.

DAC (임의적 접근 제어)

DAC(Discretionary Access Control)는 UNIX의 전통적인 접근 제어 모델로, 파일 소유자가 접근 권한을 결정합니다. 모든 파일과 디렉터리에 rwx(읽기/쓰기/실행) 권한이 소유자(owner), 그룹(group), 기타(others) 3범주에 대해 설정됩니다.

# 실습 예제: DAC 권한 확인 및 ACL 설정

# 파일 권한 상세 확인
ls -la /etc/shadow
# -rw-r----- 1 root shadow ... /etc/shadow

# POSIX ACL 확인
getfacl /etc/passwd

# 특정 사용자에 ACL 추가
setfacl -m u:webadmin:rx /var/www/html

# ACL이 설정된 파일은 ls -l에서 + 표시
ls -la /var/www/html
# drwxr-xr-x+ 2 root root ... /var/www/html

# umask 확인 (보안 권장값: 0027)
umask
# 0022 (기본) → 새 파일: 644, 새 디렉터리: 755

DAC vs MAC 비교

seccomp-bpf 시스템 콜 필터링

seccomp(Secure Computing)은 프로세스의 공격 표면(Attack Surface)을 줄이는 가장 직접적인 메커니즘입니다. 불필요한 시스템 콜을 차단함으로써, 커널 취약점의 도달 가능 경로를 물리적으로 제거합니다.

/* 실습 예제: seccomp-bpf 필터 설치 (libseccomp 사용) */

#include <seccomp.h>
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    /* 기본 동작: 모든 시스템 콜 거부 (KILL) */
    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_KILL);

    /* 필요한 시스템 콜만 화이트리스트 */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(brk), 0);

    /* write() 시스템 콜에 인자 기반 조건 추가 */
    /* fd == 1 (stdout)인 경우만 허용, stderr는 차단 */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
                     SCMP_A0(SCMP_CMP_EQ, STDOUT_FILENO));

    /* 필터 로드 (이후 해제 불가) */
    seccomp_load(ctx);
    seccomp_release(ctx);

    /* 이 시점부터 허용된 시스템 콜만 사용 가능 */
    write(STDOUT_FILENO, "Hello, sandboxed world!\n", 24);

    /* open() 시도 시 SIGSYS로 프로세스 종료됨 */
    /* open("/etc/passwd", O_RDONLY);  ← SIGKILL */

    return 0;
}

컨테이너 런타임에서 기본 적용되는 seccomp 프로파일은 약 300개 이상의 시스템 콜 중 위험한 약 50개를 차단합니다:

LSM (Linux Security Modules) 프레임워크

LSM은 커널에 보안 정책을 플러그인 형태로 삽입할 수 있는 프레임워크입니다. 시스템 콜 경로의 핵심 지점에 보안 훅(security hook)을 배치하여, 접근 제어(Access Control) 결정을 LSM 모듈에 위임합니다. security_hook_heads 구조체(Struct)에 약 230개의 훅 포인트(파일·프로세스(Process)·소켓(Socket)·IPC 등)가 정의되며, SELinux·AppArmor·Landlock 등이 훅을 등록합니다. 여러 LSM을 동시에 활성화하는 LSM 스태킹도 지원하며, 모든 LSM이 허용해야 접근이 승인됩니다(AND 로직).

LSM 프레임워크의 내부 구조·훅 디스패치(Dispatch) 메커니즘·스태킹 설정에 대한 상세 내용은 LSM 프레임워크를 참고하세요.

주요 LSM 모듈 비교

SELinux

SELinux(Security-Enhanced Linux)는 NSA가 개발한 MAC 시스템으로, Type Enforcement(TE), RBAC, MLS/MCS 모델을 결합한 가장 포괄적인 리눅스 보안 프레임워크입니다. RHEL, Fedora, CentOS 등에서 기본 활성화되며, 보안 컨텍스트(user:role:type:level)를 기반으로 모든 프로세스와 자원의 접근을 제어합니다.

SELinux 보안 컨텍스트

모든 프로세스, 파일, 소켓, IPC 객체에 보안 컨텍스트(Security Context)가 할당됩니다. 형식은 user:role:type:level이며, 접근 제어 결정에서 type이 가장 중요합니다.

# 실습 예제: SELinux 보안 컨텍스트 확인

# 프로세스의 SELinux 컨텍스트 확인
ps -eZ | grep httpd
# system_u:system_r:httpd_t:s0  1234 ?  00:00:01 httpd

# 파일의 SELinux 컨텍스트 확인
ls -Z /var/www/html/index.html
# system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

# SELinux 모드 확인
getenforce
# Enforcing (차단) / Permissive (로깅만) / Disabled (비활성)

# AVC 거부 로그 확인
sudo ausearch -m avc -ts recent

# 거부된 접근을 허용하는 정책 모듈 생성
sudo ausearch -m avc -ts recent | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

AppArmor

AppArmor는 경로(path) 기반 MAC 시스템으로, SELinux보다 설정이 간단하며 Ubuntu, SUSE, Debian 등에서 기본 사용됩니다. 프로그램별 프로파일을 정의하여 파일, 네트워크, capability 접근을 제어하고, enforce(차단) 또는 complain(로깅) 모드로 동작합니다.

# 실습 예제: AppArmor 프로파일 관리

# AppArmor 상태 확인
sudo aa-status
# 출력: 로드된 프로파일 수, enforce/complain 모드 구분

# 프로파일 모드 전환
sudo aa-enforce /usr/sbin/nginx     # enforce 모드 (위반 차단)
sudo aa-complain /usr/sbin/nginx    # complain 모드 (위반 로깅만)

# 프로파일 자동 생성 (학습 모드)
sudo aa-genprof /usr/bin/myapp
# 프로그램 실행 후 F를 눌러 학습 종료, S로 저장

# 프로파일 예시 (/etc/apparmor.d/usr.sbin.nginx)
# /usr/sbin/nginx {
#   /var/www/html/** r,          # 웹 콘텐츠 읽기
#   /var/log/nginx/** w,         # 로그 쓰기
#   /run/nginx.pid rw,           # PID 파일
#   capability net_bind_service,  # 80/443 포트 바인드
#   network inet stream,          # TCP 소켓
#   deny /etc/shadow r,           # 패스워드 파일 읽기 차단
# }

SMACK (Simplified Mandatory Access Control Kernel)

SMACK은 라벨 기반 MAC으로, SELinux보다 훨씬 단순한 subject object access 3-tuple 규칙 모델을 제공합니다. IoT 디바이스, 임베디드 시스템(Tizen 등)에서 주로 사용됩니다.

# SMACK 규칙 예시 (Tizen 플랫폼)

# 규칙 형식: subject_label object_label access
# /etc/smack/accesses 파일에 정의

# WebApp이 MediaFiles를 읽기만 허용
WebApp MediaFiles r

# System이 모든 대상에 읽기/쓰기/실행 허용
System _ rwx

# 프로세스 라벨 확인
cat /proc/self/attr/current
# System

# 파일 라벨 확인
getfattr -n security.SMACK64 /path/to/file

Landlock

Landlock은 커널 5.13에서 도입된 비특권(unprivileged) 샌드박싱 LSM으로, 일반 사용자가 root 권한 없이 프로세스의 파일시스템(Filesystem)/네트워크 접근을 제한할 수 있습니다. 3단계 API로 동작하며, 적용 후 되돌릴 수 없는 단방향 보안 모델입니다.

Landlock 3단계 API

/* 실습 예제: Landlock 샌드박스 설정 (비특권 사용자) */

#include <linux/landlock.h>
#include <sys/syscall.h>
#include <fcntl.h>

int main(void)
{
    /* 1단계: 규칙셋 생성 — 제한할 접근 유형 선언 */
    struct landlock_ruleset_attr attr = {
        .handled_access_fs =
            LANDLOCK_ACCESS_FS_READ_FILE |
            LANDLOCK_ACCESS_FS_WRITE_FILE |
            LANDLOCK_ACCESS_FS_EXECUTE,
    };
    int ruleset_fd = syscall(SYS_landlock_create_ruleset,
                            &attr, sizeof(attr), 0);

    /* 2단계: 허용 규칙 추가 — /usr과 /tmp만 접근 허용 */
    struct landlock_path_beneath_attr path_attr;
    path_attr.allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                               LANDLOCK_ACCESS_FS_EXECUTE;
    path_attr.parent_fd = open("/usr", O_PATH | O_CLOEXEC);
    syscall(SYS_landlock_add_rule, ruleset_fd,
            LANDLOCK_RULE_PATH_BENEATH, &path_attr, 0);
    close(path_attr.parent_fd);

    /* 3단계: 규칙셋 적용 — 이후 되돌릴 수 없음 */
    prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);  /* 필수 */
    syscall(SYS_landlock_restrict_self, ruleset_fd, 0);
    close(ruleset_fd);

    /* 이후 /etc/shadow 접근 시도 → -EACCES */
    open("/etc/shadow", O_RDONLY);  /* 실패 */

    return 0;
}

seccomp-bpf

seccomp(Secure Computing)은 프로세스가 호출할 수 있는 시스템 콜을 제한하는 커널 보안 메커니즘입니다. Strict 모드와 Filter 모드(cBPF)를 지원하며, 필터 체인은 누적되어 점점 더 제한적으로만 변경됩니다. 컨테이너 런타임에서 시스템 콜 격리의 핵심 기술로 사용됩니다.

seccomp 동작 모드

seccomp 반환값과 우선순위

Credentials & Capabilities

Linux 커널에서 모든 보안 결정의 기반이 되는 것은 struct cred입니다. 프로세스의 UID/GID, capability 세트(5종: inheritable, permitted, effective, bounding, ambient), LSM 보안 데이터가 모두 이 구조체에 집중됩니다. Credential은 COW(Copy-on-Write) 방식으로 관리되며, prepare_creds()로 복사 후 수정하고 commit_creds()로 원자적(Atomic) 교체합니다.

Capability 시스템

Linux capability는 전통적인 root 특권을 약 41개의 독립 비트로 분리합니다. 기초 개념은 Linux Containers 페이지를 참조하세요.

Capability 5종 세트 관계

파일 Capability 관리

# 파일에 capability 부여 (setuid 대체)
sudo setcap cap_net_bind_service=ep /usr/bin/myserver
# e = effective, p = permitted, i = inheritable

# 파일 capability 확인
getcap /usr/bin/myserver

# 프로세스의 현재 capability 확인
cat /proc/self/status | grep Cap
# CapInh / CapPrm / CapEff / CapBnd / CapAmb

# capsh로 디코딩
capsh --decode=000001ffffffffff

커널 하드닝

리눅스 커널은 KASLR, KPTI, kCFI, SMEP/SMAP, Stack Protector, FORTIFY_SOURCE, Lockdown LSM, Spectre/Meltdown 방어 등 다양한 하드닝 기술을 제공합니다. 이러한 기술들은 4개 계층(하드웨어 → 컴파일러 → 메모리 → 접근 제어)의 종심 방어(defense in depth) 구조를 형성하여, 취약점이 존재하더라도 익스플로잇 성공 확률을 크게 낮춥니다.

하드닝 4계층 구조

# 실습 예제: 현재 시스템의 하드닝 상태 점검

# CPU 보안 기능 확인
cat /proc/cpuinfo | grep -oE '(smep|smap|nx|ibrs|stibp|ssbd|cet)' | sort -u

# Spectre/Meltdown 완화 상태
grep . /sys/devices/system/cpu/vulnerabilities/*

# 출력 예시:
# /sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
# /sys/devices/system/cpu/vulnerabilities/spectre_v1:Mitigation: usercopy/swapgs ...
# /sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpoline ...

# Lockdown 모드 확인
cat /sys/kernel/security/lockdown
# [none] integrity confidentiality

# 모듈 서명 검증 상태
cat /proc/sys/kernel/tainted
# 0이면 서명되지 않은 모듈 없음

Audit 서브시스템

Linux Audit 서브시스템은 커널 수준에서 보안 관련 이벤트를 기록하는 프레임워크입니다. 시스템 콜, 파일 접근, 네트워크 연결, 사용자 인증 등 거의 모든 커널 활동을 감사할 수 있으며, PCI-DSS, HIPAA, SOX 등 보안 컴플라이언스 인증의 필수 요구사항을 충족합니다.

Audit 구성 요소

# 실습 예제: Audit 규칙 설정

# 현재 감사 규칙 확인
sudo auditctl -l

# /etc/passwd 파일 변경 감시
sudo auditctl -w /etc/passwd -p wa -k passwd_changes
# -w: 감시 경로, -p wa: 쓰기+속성변경 감시, -k: 검색 키

# 특정 시스템 콜 감시 (execve — 프로그램 실행 추적)
sudo auditctl -a always,exit -F arch=b64 -S execve -k exec_tracking

# 특정 사용자의 파일 접근 감시
sudo auditctl -a always,exit -F arch=b64 -S open,openat -F auid=1000 -k user1000_access

# 감사 로그 검색
sudo ausearch -k passwd_changes -ts recent

# 감사 보고서 생성
sudo aureport --summary
sudo aureport --auth   # 인증 이벤트 보고서

IMA/EVM 및 Lockdown

IMA(Integrity Measurement Architecture)와 EVM(Extended Verification Module)은 파일 무결성(Integrity)을 보장합니다. Lockdown LSM은 커널의 자체 변경을 방지합니다. 이 세 기술은 부팅부터 런타임까지의 신뢰 체인(chain of trust)을 구성하는 핵심 요소입니다.

신뢰 체인 (Chain of Trust)

부팅부터 런타임까지의 신뢰 체인은 다음과 같이 구성됩니다:

UEFI Secure Boot (펌웨어)
    │ 서명 검증
    ▼
GRUB/systemd-boot (부트로더)
    │ 서명 검증
    ▼
vmlinuz (커널 이미지)
    │ 모듈 서명 검증 (CONFIG_MODULE_SIG)
    ├─ 커널 모듈 (.ko)
    │
    │ IMA/EVM 검증
    ├─ 시스템 바이너리 (/usr/bin/*)
    ├─ 공유 라이브러리 (/usr/lib/*)
    ├─ 설정 파일 (/etc/*)
    │
    │ dm-verity
    ├─ 읽기 전용 파티션 (/, /usr)
    │
    │ fs-verity
    └─ 개별 파일 (APK, 정책 파일)

보안 관련 커널 설정 종합

보안 기능별 성능 영향 요약

KASLR/KPTI/CFI 통합 방어

KASLR(주소 랜덤화), KPTI(페이지 테이블(Page Table) 격리), kCFI(제어 흐름 무결성)는 각각 독립된 공격 벡터를 차단하며, 세 기술이 동시에 활성화될 때 종심 방어 구조를 형성합니다.

LSM 훅 호출 체인: sys_open → security_file_open

사용자 공간에서 open() 시스템 콜을 호출하면, 커널 내부에서 여러 단계를 거쳐 최종적으로 LSM 보안 훅이 실행됩니다. 이 경로를 정확히 이해하면 LSM 정책이 어느 시점에서, 어떤 정보를 기반으로 접근 제어 결정을 내리는지 파악할 수 있습니다.

호출 경로 개요

파일 열기 시스템 콜의 보안 훅 호출 경로는 다음과 같습니다:

사용자 공간: open("/etc/passwd", O_RDONLY)
    │
    ▼
sys_openat()                     /* fs/open.c */
    │
    ▼
do_sys_openat2()                 /* fs/open.c */
    │
    ▼
do_filp_open()                   /* fs/namei.c */
    │
    ▼
path_openat()                    /* fs/namei.c - 경로 해석 + 파일 열기 */
    │
    ├─ link_path_walk()          /* 디렉터리 순회: security_inode_permission() */
    │
    ├─ do_open()                 /* 최종 열기 단계 */
    │     │
    │     ▼
    │   vfs_open()               /* fs/open.c */
    │     │
    │     ▼
    │   security_file_open()     /* security/security.c - LSM 훅 디스패치 */
    │     │
    │     ▼
    │   call_int_hook(file_open, file)
    │     │
    │     ├─ selinux_file_open()
    │     ├─ apparmor_file_open()
    │     └─ (기타 등록된 LSM)
    │
    └─ 파일 디스크립터 반환

핵심 포인트는 AND 로직입니다. 등록된 모든 LSM 모듈이 0을 반환해야 접근이 허용되며, 하나라도 음수 에러 코드를 반환하면 즉시 해당 에러가 호출자에게 전파됩니다.

security_file_open() 구현 분석

security/security.c에 정의된 security_file_open()의 핵심 구현입니다:

/* security/security.c — 파일 열기 LSM 훅 디스패치 */

int security_file_open(struct file *file)
{
    int ret;

    /* 1. LSM 훅 체인 순회 — 모든 등록 모듈의 file_open 호출 */
    ret = call_int_hook(file_open, file);

    /* 2. 하나라도 거부하면 즉시 에러 반환 */
    if (ret)
        return ret;

    /* 3. fsnotify — 파일 열기 이벤트 통지 (inotify, fanotify) */
    return fsnotify_perm(file, MAY_OPEN);
}

call_int_hook 매크로 내부

call_int_hook()은 LSM 프레임워크의 핵심 디스패치 매크로로, 등록된 모든 보안 모듈의 훅을 순차 호출합니다:

/* security/security.c — 정수 반환 훅 디스패치 매크로 (간소화) */

#define call_int_hook(FUNC, ...) ({                  \
    int RC = LSM_RET_DEFAULT(FUNC);                  \
    struct security_hook_list *P;                     \
                                                         \
    hlist_for_each_entry(P,                            \
            &security_hook_heads.FUNC, list) {           \
        RC = P->hook.FUNC(__VA_ARGS__);                  \
        if (RC != 0)                                   \
            break;                                      \
    }                                                    \
    RC;                                                  \
})

SELinux의 file_open 훅 구현

SELinux가 file_open 훅에서 수행하는 접근 검사의 핵심 흐름입니다:

/* security/selinux/hooks.c — SELinux file_open 훅 (간소화) */

static int selinux_file_open(struct file *file)
{
    struct file_security_struct *fsec = selinux_file(file);
    struct inode_security_struct *isec;
    struct inode *inode = file_inode(file);
    u32 sid = current_sid();           /* 현재 프로세스의 SID */
    u32 av = file_to_av(file);         /* 파일 모드 → AV 비트 변환 */

    isec = inode_security(inode);

    /* AVC(Access Vector Cache)에서 결정 조회 또는 계산 */
    return avc_has_perm(sid, isec->sid, isec->sclass, av, NULL);
}

struct cred 필드 심층 분석

struct cred는 Linux 커널에서 프로세스의 모든 보안 자격증명을 담는 핵심 구조체입니다. UID/GID, capability 세트, 네임스페이스 정보, LSM 보안 블롭이 모두 이 하나의 구조체에 집중되어 있으며, 커널의 모든 접근 제어 결정이 이 구조체를 기반으로 이루어집니다.

필드별 상세 분석

다음은 include/linux/cred.h에 정의된 struct cred의 주요 필드입니다:

/* include/linux/cred.h — struct cred 정의 (간소화) */

struct cred {
    atomic_long_t   usage;          /* 참조 카운트 */

    /* ── UID/GID 세트 ── */
    kuid_t          uid;            /* 실제 UID (real) */
    kgid_t          gid;            /* 실제 GID (real) */
    kuid_t          suid;           /* 저장된 set-user-ID (saved) */
    kgid_t          sgid;           /* 저장된 set-group-ID (saved) */
    kuid_t          euid;           /* 유효 UID (effective) — 접근 결정 기준 */
    kgid_t          egid;           /* 유효 GID (effective) */
    kuid_t          fsuid;          /* 파일시스템 UID — VFS 접근 검사용 */
    kgid_t          fsgid;          /* 파일시스템 GID */

    /* ── 보안 비트 ── */
    unsigned        securebits;     /* SECBIT_* 플래그 (NOROOT, NO_SETUID_FIXUP 등) */

    /* ── Capability 세트 (5종) ── */
    kernel_cap_t    cap_inheritable; /* exec 시 자식에게 전달 가능 */
    kernel_cap_t    cap_permitted;   /* 프로세스가 보유 가능한 최대 집합 */
    kernel_cap_t    cap_effective;   /* 현재 실제로 적용되는 집합 */
    kernel_cap_t    cap_bset;        /* Bounding set — cap_permitted 상한 */
    kernel_cap_t    cap_ambient;     /* exec 시 자동 상속 (4.3+) */

    /* ── 사용자/네임스페이스 참조 ── */
    struct user_struct    *user;      /* 사용자별 자원 추적 (프로세스 수 제한 등) */
    struct user_namespace *user_ns;   /* 자격증명이 속한 user namespace */
    struct group_info    *group_info; /* 보조 그룹 목록 */

    /* ── LSM 보안 블롭 ── */
    struct lsm_blob_sizes *security;  /* LSM별 보안 데이터 (SELinux SID 등) */

    /* ── RCU 보호 ── */
    struct rcu_head       rcu;        /* RCU grace period 후 해제 */
} __randomize_layout;               /* 구조체 레이아웃 랜덤화 */

Credential COW 생명주기: prepare_creds → commit_creds

커널은 credential을 COW(Copy-on-Write) 방식으로 관리합니다. 보안 속성을 변경하려면 반드시 새 복사본을 만들고, 수정 후 원자적으로 교체해야 합니다:

/* kernel/cred.c — credential 변경 패턴 */

/* 1단계: 현재 cred의 복사본 생성 */
struct cred *new = prepare_creds();
if (!new)
    return -ENOMEM;

/* 2단계: 복사본에서 원하는 필드 수정 */
new->euid = make_kuid(new->user_ns, 1000);
new->cap_effective = cap_drop(new->cap_effective, CAP_SYS_ADMIN);

/* 3단계: 보안 검사 (LSM이 변경을 허용하는지) */
int ret = security_prepare_creds(new, current_cred(), GFP_KERNEL);
if (ret) {
    abort_creds(new);    /* 실패 시 복사본 해제 */
    return ret;
}

/* 4단계: 원자적 교체 — rcu_assign_pointer(task->cred, new) */
commit_creds(new);
/* 이 시점 이후 현재 태스크의 보안 속성이 변경됨 */
/* 이전 cred는 RCU grace period 후 해제 */

override_creds / revert_creds 패턴

커널 내부에서 일시적으로 다른 자격증명으로 작업해야 할 때 사용하는 패턴입니다. NFS 서버, 파일시스템 데몬 등에서 활용됩니다:

/* 일시적 credential 변경 패턴 */

const struct cred *old_cred;
struct cred *new_cred;

new_cred = prepare_creds();
new_cred->fsuid = make_kuid(new_cred->user_ns, 0);  /* root로 파일 접근 */

/* 현재 태스크의 주관적 cred만 교체 (real_cred는 유지) */
old_cred = override_creds(new_cred);

/* 이 구간에서는 root 권한으로 파일 접근 수행 */
vfs_open(...);

/* 원래 credential로 복귀 */
revert_creds(old_cred);
put_cred(new_cred);

seccomp-BPF 필터 내부 경로

seccomp-BPF는 시스템 콜 진입점에서 BPF 필터를 실행하여 호출 허용/거부를 결정합니다. 이 섹션에서는 커널 내부에서 필터가 실행되는 정확한 경로와 struct seccomp_filter의 구조를 분석합니다.

필터 실행 경로

사용자 공간: write(fd, buf, len)
    │
    ▼
syscall_enter_from_user_mode()   /* arch/x86/entry/common.c */
    │
    ├─ syscall_trace_enter()
    │     │
    │     ▼
    │   __secure_computing()     /* kernel/seccomp.c — 진입점 */
    │     │
    │     ├─ (strict 모드) → 허용 목록 검사 (read/write/exit/sigreturn만)
    │     │
    │     └─ (filter 모드) → seccomp_run_filters()
    │           │
    │           ▼
    │         BPF_PROG_RUN(filter→prog, &sd)
    │           │
    │           ├─ SECCOMP_RET_ALLOW  → 시스템 콜 계속 진행
    │           ├─ SECCOMP_RET_KILL   → SIGSYS로 프로세스 종료
    │           ├─ SECCOMP_RET_TRAP   → SIGSYS 시그널 전달
    │           ├─ SECCOMP_RET_ERRNO  → 지정 errno 반환
    │           ├─ SECCOMP_RET_TRACE  → ptrace 트레이서에 통지
    │           ├─ SECCOMP_RET_LOG    → 허용 + 로그 기록
    │           └─ SECCOMP_RET_USER_NOTIF → 감독자 프로세스에 위임
    │
    ▼
do_syscall_64()                  /* 실제 시스템 콜 핸들러 실행 */

struct seccomp_filter 분석

seccomp 필터는 BPF 프로그램과 메타데이터를 담은 연결 리스트 구조입니다:

/* kernel/seccomp.c — seccomp 필터 구조체 (간소화) */

struct seccomp_filter {
    refcount_t          refs;       /* 참조 카운트 (fork 시 공유) */
    refcount_t          users;      /* task 연결 수 */
    bool                log;        /* 로깅 활성화 여부 */
    struct action_cache cache;      /* Bitmap 캐시 — syscall별 빠른 판정 */
    struct seccomp_filter *prev;    /* 부모 필터 (연결 리스트) */
    struct bpf_prog     *prog;      /* 컴파일된 cBPF 프로그램 */
    struct notification  *notif;     /* USER_NOTIF 데이터 (NULL이면 미사용) */
};

필터 평가 코드 분석

seccomp_run_filters()는 필터 체인을 순회하며 가장 엄격한 결과를 채택합니다:

/* kernel/seccomp.c — 필터 체인 실행 (간소화) */

static u32 seccomp_run_filters(const struct seccomp_data *sd,
                                struct seccomp_filter **match)
{
    u32 ret = SECCOMP_RET_ALLOW;
    struct seccomp_filter *f;

    /* 현재 태스크의 필터 체인을 자식→부모 순으로 순회 */
    for (f = READ_ONCE(current->seccomp.filter); f; f = f->prev) {
        u32 cur_ret = bpf_prog_run_pin_on_cpu(f->prog, sd);

        /* 더 엄격한(낮은 우선순위) 결과를 채택 */
        if ((cur_ret & SECCOMP_RET_ACTION_FULL) <
            (ret & SECCOMP_RET_ACTION_FULL)) {
            ret = cur_ret;
            *match = f;
        }
    }

    return ret;
}

seccomp_data: BPF 필터 입력

BPF 필터가 검사할 수 있는 데이터는 struct seccomp_data로 제한됩니다:

/* include/uapi/linux/seccomp.h */

struct seccomp_data {
    int   nr;                  /* 시스템 콜 번호 */
    __u32 arch;                /* AUDIT_ARCH_* 아키텍처 식별자 */
    __u64 instruction_pointer; /* 시스템 콜 진입 시 IP */
    __u64 args[6];             /* 시스템 콜 인자 6개 */
};

LSM 프레임워크 내부 구조

LSM 프레임워크의 핵심은 security_hook_heads 전역 구조체와, 각 LSM 모듈이 훅을 등록하는 security_add_hooks() 함수입니다. 이 섹션에서는 훅 등록과 디스패치의 내부 메커니즘을 분석합니다.

security_hook_heads 구조

security_hook_heads는 약 230개의 보안 훅 포인트를 정의하는 전역 구조체입니다. 각 훅 포인트는 hlist_head(해시 리스트 헤드)로, 여러 LSM 모듈의 콜백이 연결 리스트로 등록됩니다:

/* security/security.c — 보안 훅 헤드 전역 구조체 */

struct security_hook_heads {
    struct hlist_head binder_set_context_mgr;
    struct hlist_head binder_transaction;
    /* ... */
    struct hlist_head file_permission;
    struct hlist_head file_alloc_security;
    struct hlist_head file_open;          /* ← security_file_open()이 순회하는 리스트 */
    /* ... */
    struct hlist_head task_alloc;
    struct hlist_head cred_prepare;
    struct hlist_head cred_free;
    /* ... ~230개 훅 포인트 */
} __lsm_ro_after_init;               /* 초기화 후 읽기 전용 (보안 강화) */

security_hook_list 구조체

각 LSM 모듈이 등록하는 개별 훅 엔트리는 security_hook_list 구조체입니다:

/* include/linux/lsm_hooks.h — 개별 훅 엔트리 */

struct security_hook_list {
    struct hlist_node     list;   /* 연결 리스트 노드 */
    struct hlist_head     *head;  /* 소속 훅 헤드 포인터 */
    union security_list_options hook; /* 실제 콜백 함수 포인터 (유니온) */
    const struct lsm_id  *lsmid; /* LSM 식별자 (이름, ID) */
} __randomize_layout;

security_add_hooks() 등록 메커니즘

LSM 모듈이 부팅 시 자신의 훅들을 프레임워크에 등록하는 함수입니다:

/* security/security.c — LSM 훅 등록 */

void __init security_add_hooks(struct security_hook_list *hooks,
                              int count,
                              const struct lsm_id *lsmid)
{
    int i;

    for (i = 0; i < count; i++) {
        hooks[i].lsmid = lsmid;
        hlist_add_tail_rcu(&hooks[i].list, hooks[i].head);
    }
}

SELinux 훅 등록 예시

SELinux가 부팅 시 약 200개의 훅을 등록하는 코드 패턴입니다:

/* security/selinux/hooks.c — SELinux 훅 배열 및 등록 */

static struct security_hook_list selinux_hooks[] __ro_after_init = {
    /* 파일 훅 */
    LSM_HOOK_INIT(file_permission, selinux_file_permission),
    LSM_HOOK_INIT(file_alloc_security, selinux_file_alloc_security),
    LSM_HOOK_INIT(file_open, selinux_file_open),
    /* 프로세스 훅 */
    LSM_HOOK_INIT(task_alloc, selinux_task_alloc),
    LSM_HOOK_INIT(cred_prepare, selinux_cred_prepare),
    LSM_HOOK_INIT(cred_free, selinux_cred_free),
    /* 소켓 훅 */
    LSM_HOOK_INIT(socket_create, selinux_socket_create),
    LSM_HOOK_INIT(socket_connect, selinux_socket_connect),
    /* ... 약 200개 */
};

static const struct lsm_id selinux_lsmid = {
    .name = "selinux",
    .id = LSM_ID_SELINUX,
};

static int __init selinux_init(void)
{
    /* ... 초기화 ... */
    security_add_hooks(selinux_hooks,
                       ARRAY_SIZE(selinux_hooks),
                       &selinux_lsmid);
    return 0;
}

LSM 스태킹과 호출 순서

커널 부팅 파라미터 lsm=으로 LSM 활성화 순서를 지정합니다. 이 순서가 곧 훅 호출 순서입니다:

# 기본 LSM 순서 (배포판별 상이)
lsm=lockdown,capability,landlock,yama,apparmor,selinux,bpf

# 현재 활성 LSM 확인
cat /sys/kernel/security/lsm
# 출력: lockdown,capability,landlock,yama,apparmor

# CONFIG_LSM 기본값 (빌드 시 결정)
# CONFIG_LSM="lockdown,capability,landlock,yama,integrity,apparmor"

Capability 검사 경로: capable() 내부

커널에서 특권 작업을 수행하기 전에는 반드시 capable() 또는 ns_capable()을 호출하여 현재 프로세스가 해당 capability를 보유하는지 검사합니다. 이 검사는 POSIX capability 시스템과 LSM 프레임워크를 모두 거치는 다단계 과정입니다.

호출 체인 분석

커널 코드: capable(CAP_NET_ADMIN)
    │
    ▼
ns_capable(&init_user_ns, CAP_NET_ADMIN)
    │
    ▼
ns_capable_common(&init_user_ns, CAP_NET_ADMIN, CAP_OPT_NONE)
    │
    ├─ 1. cap_capable() 호출      /* POSIX capability 비트 검사 */
    │     │
    │     ├─ user namespace 계층 확인
    │     ├─ cap_raised(cred->cap_effective, cap) 비트 테스트
    │     └─ 0 (보유) 또는 -EPERM (미보유)
    │
    ├─ 2. security_capable() 호출  /* LSM 추가 검사 */
    │     │
    │     └─ call_int_hook(capable, cred, ns, cap, opts)
    │           ├─ selinux_capable()   → AVC 정책 검사
    │           └─ apparmor_capable()  → 프로파일 검사
    │
    └─ 최종 결과: 0 (허용) 또는 -EPERM (거부)

capable() / ns_capable() 구현 분석

/* kernel/capability.c — capability 검사 코어 */

bool capable(int cap)
{
    return ns_capable(&init_user_ns, cap);
}

bool ns_capable(struct user_namespace *ns, int cap)
{
    return ns_capable_common(ns, cap, CAP_OPT_NONE);
}

static bool ns_capable_common(struct user_namespace *ns,
                              int cap, unsigned int opts)
{
    int ret;

    /* CAP 번호 유효성 검사 */
    if (unlikely(!cap_valid(cap)))
        return false;

    /* 1단계: POSIX capability 비트 검사 */
    ret = cap_capable(current_cred(), ns, cap, opts);

    /* 2단계: LSM 추가 검사 (cap_capable 통과 시에만) */
    if (!ret)
        ret = security_capable(current_cred(), ns, cap, opts);

    /* 3단계: Audit 기록 (실패 시 포함) */
    if (!ret && !(opts & CAP_OPT_NOAUDIT))
        current_audit_context()->...;  /* 감사 로그 */

    return !ret;  /* 0이면 true(보유), 음수면 false(미보유) */
}

cap_capable(): namespace 인식 비트 검사

cap_capable()은 user namespace 계층을 고려한 capability 비트 검사를 수행합니다:

/* security/commoncap.c — POSIX capability 비트 검사 (간소화) */

int cap_capable(const struct cred *cred,
               struct user_namespace *targ_ns,
               int cap, unsigned int opts)
{
    struct user_namespace *ns = targ_ns;

    /* user namespace 계층을 거슬러 올라가며 검사 */
    for (;;) {
        /* cred의 user_ns가 대상 ns와 같으면 비트 검사 */
        if (ns == cred->user_ns)
            return cap_raised(cred->cap_effective, cap) ?
                   0 : -EPERM;

        /* 초기 namespace까지 올라왔으면 실패 */
        if (ns == &init_user_ns)
            return -EPERM;

        /* ns를 생성한 프로세스가 부모 ns에서 CAP을 가졌는지 */
        if (ns->level <= cred->user_ns->level)
            return -EPERM;

        /* 부모 namespace로 이동 */
        ns = ns->parent;
    }
}

execve() 시 capability 계산

프로세스가 execve()로 새 프로그램을 실행할 때, capability 세트는 다음 공식에 의해 재계산됩니다:

여기서 P()는 프로세스, F()는 파일, P'()는 exec 후의 새 값을 나타냅니다.

capability 디버깅 실전

# 프로세스의 capability 세트 확인
cat /proc/$$status | grep -i cap
# CapInh: 0000000000000000   (inheritable)
# CapPrm: 000001ffffffffff   (permitted)
# CapEff: 000001ffffffffff   (effective)
# CapBnd: 000001ffffffffff   (bounding)
# CapAmb: 0000000000000000   (ambient)

# 비트마스크 → 이름 변환
capsh --decode=000001ffffffffff

# 특정 capability로 프로그램 실행 (capsh)
capsh --caps="cap_net_bind_service+eip" -- -c "/usr/bin/myserver"

# BPF 프로그램의 CAP_BPF 사용 추적 (ftrace)
echo 1 > /sys/kernel/debug/tracing/events/capability/cap_capable/enable
cat /sys/kernel/debug/tracing/trace_pipe | grep CAP_BPF

# Audit 로그에서 capability 사용 검색
ausearch -m SYSCALL --comm nginx -k cap_check

메모리 보호 메커니즘

커널 메모리 보호는 익스플로잇의 성공 확률을 낮추는 완화(Mitigation) 기술입니다. 취약점 자체를 제거하지는 않지만, 공격자가 취약점을 이용하여 코드 실행이나 권한 상승에 성공하는 것을 극도로 어렵게 만듭니다.

KASLR (커널 주소 공간 배치 랜덤화)

KASLR(Kernel Address Space Layout Randomization)은 부팅 시 커널 코드와 데이터의 기본 주소를 무작위로 배치합니다. 공격자가 가젯(Gadget) 주소를 예측하는 것을 방지하여 ROP(Return-Oriented Programming) 공격을 어렵게 만듭니다.

# 실습 예제: KASLR 활성화 확인

# KASLR 활성화 여부 확인 (nokaslr 부팅 파라미터 사용 시 비활성화)
cat /proc/cmdline | grep -o 'nokaslr' || echo "KASLR enabled"

# 커널 기본 주소 확인 (root 필요, KASLR 활성화 시 부팅마다 변경)
# 주의: /proc/kallsyms는 비특권 사용자에게 0으로 표시됨
sudo cat /proc/kallsyms | head -5

# KPTI 활성화 확인
dmesg | grep -i "page table isolation"
# 출력 예: Kernel/User page tables isolation: enabled

# kptr_restrict 설정으로 커널 주소 유출 방지
cat /proc/sys/kernel/kptr_restrict
# 0: 제한 없음, 1: 비특권 사용자에게 숨김, 2: 모두에게 숨김
sudo sysctl kernel.kptr_restrict=1

SMEP/SMAP (하드웨어 접근 방지)

SMEP(Supervisor Mode Execution Prevention)은 커널 모드에서 사용자 공간 코드를 실행하는 것을 하드웨어 수준에서 차단합니다. SMAP(Supervisor Mode Access Prevention)은 커널이 사용자 공간 메모리에 직접 접근하는 것을 차단합니다. 두 기능 모두 CPU의 CR4 레지스터 비트로 제어됩니다.

스택 보호 (Stack Canary)

스택 카나리(Stack Canary)는 함수의 반환 주소 앞에 랜덤 값(카나리)을 배치하여, 버퍼 오버플로 공격이 반환 주소를 덮어쓸 때 카나리 변조를 감지합니다. GCC의 -fstack-protector-strong 옵션으로 활성화됩니다.

개념 예시: 스택 카나리 메커니즘


스택 프레임 레이아웃 (CONFIG_STACKPROTECTOR_STRONG):

 높은 주소  ┌──────────────────┐
           │ 반환 주소 (RIP)    │  ← 공격 목표
           ├──────────────────┤
           │ 저장된 RBP        │
           ├──────────────────┤
           │ ★ 스택 카나리 ★   │  ← 랜덤 값 (부팅 시 생성)
           ├──────────────────┤
           │ 로컬 변수         │
           ├──────────────────┤
 낮은 주소  │ 로컬 버퍼[]       │  ← 오버플로 시작점
           └──────────────────┘

함수 종료 시 카나리 값 검사:
  if (canary != __stack_chk_guard)
      __stack_chk_fail();  → panic() 또는 프로세스 종료

KFENCE (커널 메모리 오류 감지)

KFENCE(Kernel Electric Fence)는 프로덕션 환경에서도 사용 가능한 저오버헤드 메모리 오류 감지기입니다. Slab 할당에서 버퍼 오버플로, Use-After-Free(UAF), 잘못된 해제(Double Free)를 감지합니다. KASAN보다 훨씬 낮은 오버헤드(~1%)로 동작합니다.

# KFENCE 활성화 확인 및 설정
cat /sys/module/kfence/parameters/sample_interval
# 기본값: 100 (100ms마다 하나의 할당을 KFENCE 보호 대상으로 선택)

# KFENCE 오류 발생 시 dmesg 출력 예시:
# BUG: KFENCE: out-of-bounds read in some_function+0x42/0x80
# Out-of-bounds read at 0xffff888012345000 (1b left of kfence-#73):

제어 흐름 무결성 (CFI)

CFI(Control Flow Integrity)는 간접 호출(indirect call)과 반환(return)의 대상이 유효한 함수 진입점인지 검증합니다. 함수 포인터 변조를 통한 코드 재사용 공격(ROP/JOP)을 방어합니다.

메모리 보호 기술 종합

커널 자체 보호 프로젝트 (KSPP)

KSPP(Kernel Self-Protection Project)는 리눅스 커널 자체의 공격 표면을 줄이고, 취약점이 존재하더라도 익스플로잇을 어렵게 만드는 것을 목표로 하는 업스트림 프로젝트입니다. "커널은 사용자 공간 프로세스를 보호하지만, 커널 자체도 보호해야 합니다"는 원칙에 기반합니다.

KSPP 핵심 목표

# 실습 예제: KSPP 관련 커널 설정 확인

# 현재 커널에서 KSPP 관련 설정 확인
zcat /proc/config.gz 2>/dev/null | grep -E "(STACKPROTECTOR|FORTIFY|HARDENED|RANDOMIZE|INIT_ON)" || \
  grep -E "(STACKPROTECTOR|FORTIFY|HARDENED|RANDOMIZE|INIT_ON)" /boot/config-$(uname -r)

# 권장 설정 (KSPP 체크리스트):
# CONFIG_STACKPROTECTOR_STRONG=y      — 스택 보호 (강화)
# CONFIG_FORTIFY_SOURCE=y              — 버퍼 오버플로 감지
# CONFIG_HARDENED_USERCOPY=y           — user/kernel copy 검증
# CONFIG_RANDOMIZE_BASE=y              — KASLR
# CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y    — 할당 시 0 초기화
# CONFIG_INIT_STACK_ALL_ZERO=y         — 스택 0 초기화
# CONFIG_SLAB_FREELIST_RANDOM=y        — Slab 랜덤화
# CONFIG_SLAB_FREELIST_HARDENED=y      — Slab 포인터 보호
# CONFIG_STRICT_KERNEL_RWX=y           — 커널 코드 W^X
# CONFIG_STRICT_MODULE_RWX=y           — 모듈 코드 W^X
# CONFIG_DEBUG_WX=y                    — W+X 매핑 감지 경고

# 현재 커널의 W+X 매핑 검사 결과
dmesg | grep "W+X"
# 정상: "x86/mm: Checked W+X mappings: passed, no W+X pages found."

FORTIFY_SOURCE 메커니즘

CONFIG_FORTIFY_SOURCE는 memcpy(), strcpy(), sprintf() 등 문자열/메모리 조작 함수에서 버퍼 크기를 컴파일 시점과 런타임에 검사합니다. 알려진 크기의 버퍼에 대한 오버플로를 감지하여 panic() 또는 BUG()를 호출합니다.

/* 개념 예시: FORTIFY_SOURCE가 감지하는 오류 */

struct my_struct {
    char name[16];
    int value;
};

void vulnerable_function(struct my_struct *s, const char *input)
{
    /* FORTIFY_SOURCE 활성화 시:
     * 컴파일러가 s->name의 크기(16)를 알고 있으므로,
     * strlen(input) > 16이면 런타임에 감지하여 panic() 호출
     */
    strcpy(s->name, input);  /* → __fortify_panic() if overflow */

    /* 안전한 대안 */
    strscpy(s->name, input, sizeof(s->name));  /* 커널 권장 */
}

/* FORTIFY_SOURCE가 보호하는 함수 목록:
 * memcpy, memmove, memset, memcmp, memchr
 * strcpy, strncpy, strcat, strncat, strlen, strlcpy, strlcat
 * sprintf, snprintf, vsprintf, vsnprintf
 * kmemdup, memscan
 */

초기화 강제 (정보 유출 방지)

초기화되지 않은 스택/힙 변수는 이전 실행의 민감한 데이터(포인터, 키, 자격증명)를 노출할 수 있습니다. KSPP는 모든 변수를 자동으로 0으로 초기화하는 옵션을 제공합니다.

구조체 레이아웃 랜덤화

__randomize_layout 어트리뷰트가 적용된 구조체는 빌드마다 필드 순서가 랜덤화됩니다. 공격자가 구조체 내 특정 필드의 오프셋을 예측할 수 없게 하여, 정밀한 메모리 조작을 방지합니다.

/* 개념 예시: 구조체 레이아웃 랜덤화 */

struct cred {
    atomic_long_t usage;
    kuid_t        uid;
    kuid_t        euid;
    kernel_cap_t  cap_effective;
    /* ... */
} __randomize_layout;  /* ← 빌드마다 필드 순서 변경 */

/*
 * 빌드 A: [usage, uid, euid, cap_effective, ...]
 * 빌드 B: [cap_effective, usage, euid, uid, ...]
 * 빌드 C: [euid, cap_effective, uid, usage, ...]
 *
 * 공격자가 offsetof(struct cred, cap_effective)를
 * 컴파일 없이 알 수 없음 → 정밀한 커널 익스플로잇 작성이 어려워짐
 *
 * 적용 대상: task_struct, cred, file, inode 등 핵심 구조체
 */

암호화(Crypto) 서브시스템

리눅스 커널의 Crypto API는 암호화 알고리즘을 통합된 인터페이스로 제공하는 프레임워크입니다. dm-crypt, IPsec, kTLS, 파일시스템 암호화(fscrypt), IMA 해시 등 커널 내부의 모든 암호화 연산이 이 API를 통해 이루어집니다.

Crypto API 구조

# 실습 예제: Crypto API 정보 확인

# 등록된 암호화 알고리즘 목록
cat /proc/crypto | grep -E "^name|^driver|^priority" | head -30

# AES-NI 하드웨어 가속 확인
cat /proc/crypto | grep -A 4 "aes"
# priority가 높은 것이 우선 선택됨 (예: aes-ni → 300, aes-generic → 100)

# 커널 FIPS 모드 확인
cat /proc/sys/crypto/fips_enabled
# 1이면 FIPS 140-2/3 모드 활성화 (비인증 알고리즘 사용 차단)

키 관리 (Key Retention Service)

커널 Keyring 서브시스템은 암호화 키, 인증 토큰(Token), 인증서(Certificate)를 커널 메모리에 안전하게 저장하고 관리합니다. 사용자 공간의 keyctl 명령으로 키를 추가/조회/삭제할 수 있습니다.

# 실습 예제: 커널 키링 사용

# 사용자 키링에 키 추가
keyctl add user mykey "secret_data" @u

# 키 목록 확인
keyctl show @u

# 키 읽기
keyctl read $(keyctl search @u user mykey)

# 시스템 키링의 신뢰 키 확인 (Secure Boot 인증서)
sudo keyctl list %:.builtin_trusted_keys

# 커널 모듈 서명 검증에 사용되는 키
sudo keyctl list %:.system_keyring

Integrity(무결성) 서브시스템

Integrity 서브시스템은 부팅부터 런타임까지의 신뢰 체인(Chain of Trust)을 구성합니다. 파일이 변조되지 않았음을 암호학적으로 검증하며, 원격 증명(Remote Attestation)을 통해 시스템의 무결성 상태를 외부에서 확인할 수 있게 합니다.

# 실습 예제: IMA 정책 및 상태 확인

# IMA 측정 로그 확인 (부팅 이후 측정된 파일 목록)
sudo cat /sys/kernel/security/ima/ascii_runtime_measurements | head -10
# PCR  template-hash  filedata-hash  filename-hint
# 10   sha256:abc...  sha256:def...  /usr/bin/bash

# IMA 정책 확인
sudo cat /sys/kernel/security/ima/policy

# dm-verity 상태 확인 (Android/ChromeOS)
dmsetup status | grep verity

# fs-verity 파일 설정
# fsverity enable --hash-algorithm=sha256 /path/to/file
# fsverity measure /path/to/file

dm-verity: 블록 디바이스 무결성

dm-verity는 device-mapper 타겟으로, 블록 디바이스의 모든 블록에 대한 Merkle 트리 해시를 미리 계산하고, 읽기 시점에 해시를 검증합니다. Android의 Verified Boot(AVB)과 ChromeOS의 핵심 무결성 메커니즘입니다.

# 실습 예제: dm-verity 설정

# 해시 테이블 생성 (읽기 전용 파티션)
veritysetup format /dev/sda3 /dev/sda4
# Root hash: a1b2c3d4e5f6... ← 이 값을 부팅 파라미터에 전달

# dm-verity 활성화
veritysetup open /dev/sda3 verified-root /dev/sda4 a1b2c3d4e5f6...

# 검증된 디바이스 마운트
mount /dev/mapper/verified-root /mnt/verified

# dm-verity 상태 확인
dmsetup status verified-root
# 0 1048576 verity V 1 ... verified

fs-verity: 파일 단위 무결성

fs-verity는 개별 파일에 대한 Merkle 트리 해시를 파일 메타데이터에 저장하고, 읽기 시점에 페이지 단위로 검증합니다. dm-verity가 전체 파티션을 보호하는 것과 달리, fs-verity는 파일 단위로 선택적으로 적용됩니다.

# fs-verity 설정 (ext4/f2fs/btrfs)

# 파일에 verity 활성화
fsverity enable --hash-algorithm=sha256 /path/to/file

# verity 해시 측정
fsverity measure /path/to/file
# sha256:a1b2c3d4e5... /path/to/file

# 파일 변조 시도 시 → I/O 오류 발생
# echo "tampered" > /path/to/file  → -EIO

# IMA와 연동: fs-verity 다이제스트를 IMA 정책에 사용
# ima 정책: appraise func=BPRM_CHECK fsverity_digest=sha256:a1b2c3d4e5...

네트워크 보안

리눅스 커널의 네트워크 보안은 패킷 필터링(netfilter), 프로토콜 수준 암호화(kTLS, IPsec), 네트워크 접근 제어(SELinux netlabel) 등 여러 계층에서 동작합니다.

netfilter / nftables

netfilter는 커널의 네트워크 패킷 처리 프레임워크로, 패킷 필터링, NAT(Network Address Translation), 연결 추적(Connection Tracking)을 제공합니다. nftables는 iptables의 후속으로, 통합된 규칙 엔진과 향상된 성능을 제공합니다.

# 실습 예제: nftables 보안 규칙

# nftables 방화벽 규칙 확인
nft list ruleset

# 기본 방화벽 정책 예시
nft add table inet filter
nft add chain inet filter input '{ type filter hook input priority 0; policy drop; }'
nft add chain inet filter forward '{ type filter hook forward priority 0; policy drop; }'
nft add chain inet filter output '{ type filter hook output priority 0; policy accept; }'

# 로컬호스트(Loopback) 허용
nft add rule inet filter input iif lo accept

# 기존 연결 허용
nft add rule inet filter input ct state established,related accept

# SSH (22번 포트) 접근 제한 — 특정 IP만 허용
nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 22 accept

# 속도 제한 (Rate Limiting) — SYN flood 방어
nft add rule inet filter input tcp dport 80 ct state new limit rate 25/second accept

# 로깅 규칙
nft add rule inet filter input log prefix "DROP: " drop

kTLS (커널 TLS)

kTLS(Kernel TLS)는 TLS 레코드 계층의 암호화/복호화를 커널에서 처리하여, 사용자 공간과 커널 사이의 데이터 복사를 줄이고 sendfile() 같은 zero-copy 최적화를 가능하게 합니다. 사용자 공간 라이브러리(OpenSSL, GnuTLS)가 TLS 핸드셰이크를 완료한 후, 세션 키를 setsockopt(SOL_TLS)으로 커널에 전달하여 이후 데이터 전송/수신의 암호화를 커널이 담당합니다.

# kTLS 활성화 확인
cat /proc/net/tls_stat
# TlsCurrTxSw    0
# TlsCurrRxSw    0
# TlsTxSw        145232

# nginx에서 kTLS 활성화 (nginx 1.21.4+, OpenSSL 3.0+)
# ssl_conf_command Options KTLS;  ← nginx.conf에 추가

SELinux 네트워크 라벨링

SELinux는 netlabel과 labeled IPsec을 통해 네트워크 패킷에 보안 컨텍스트를 부여하고, 네트워크 수준의 MAC을 실현합니다.

# SELinux 네트워크 정책 예시

# 네트워크 인터페이스 라벨 확인
seinfo --netifcon

# 포트 라벨 확인 — 어떤 도메인이 어떤 포트를 사용할 수 있는지
semanage port -l | grep http
# http_port_t    tcp    80, 81, 443, 488, 8008, 8009, 8443, 9000

# 커스텀 포트에 HTTP 라벨 추가
sudo semanage port -a -t http_port_t -p tcp 8080

# SECMARK — iptables/nftables와 SELinux 통합
# 패킷에 SELinux 컨텍스트 태깅
iptables -t security -A INPUT -p tcp --dport 80 \
    -j SECMARK --selctx system_u:object_r:http_packet_t:s0

IPsec 및 WireGuard

커널 수준의 네트워크 암호화는 IPsec(xfrm 프레임워크)과 WireGuard(Noise 프로토콜 기반) 두 가지가 주로 사용됩니다.

보안 취약점 대응

리눅스 커널의 보안 취약점 보고와 패치 배포는 security@kernel.org 메일링 리스트를 통해 조율됩니다. 2024년부터 CVE 할당이 kernel.org CNA(CVE Numbering Authority)를 통해 직접 이루어지며, 취약점 처리 프로세스가 체계화되었습니다. 커널 취약점은 공격 표면의 크기와 커널의 특권 수준 때문에 다른 소프트웨어보다 더 심각한 보안 영향을 미칩니다.

CVE 처리 프로세스

주요 커널 취약점 유형

주요 익스플로잇 기법과 완화

커널 취약점 익스플로잇은 일반적으로 다음 단계를 거칩니다. 각 단계에서 방어 기술이 개입하여 성공 확률을 낮춥니다.

CVE 추적 및 패치 관리

# 실습 예제: 커널 취약점 확인 및 대응

# 현재 커널 버전 확인
uname -r

# 알려진 CPU 취약점 상태 확인
grep . /sys/devices/system/cpu/vulnerabilities/*

# 커널 보안 공지 확인 (kernel.org)
# https://www.kernel.org/category/releases.html

# 특정 CVE의 패치 여부 확인
# git log --grep="CVE-2024-" --oneline 커널_소스_디렉터리

# 커널 라이브 패치 상태 확인 (kpatch/livepatch)
ls /sys/kernel/livepatch/ 2>/dev/null
cat /sys/kernel/livepatch/*/enabled 2>/dev/null

# 배포판별 보안 업데이트 확인
# RHEL/CentOS:
yum updateinfo list security 2>/dev/null
# Ubuntu/Debian:
apt list --upgradable 2>/dev/null | grep -i security

보안 설정 가이드

프로덕션 환경에서 커널 보안을 강화하기 위한 sysctl 설정과 커널 컴파일 옵션을 정리합니다.

sysctl 보안 설정

# 실습 예제: 보안 sysctl 일괄 적용

# /etc/sysctl.d/99-security.conf 파일 생성
cat <<'SYSCTL_EOF' | sudo tee /etc/sysctl.d/99-security.conf
# === 커널 보안 ===
kernel.kptr_restrict = 1
kernel.dmesg_restrict = 1
kernel.perf_event_paranoid = 3
kernel.unprivileged_bpf_disabled = 1
kernel.yama.ptrace_scope = 1
kernel.randomize_va_space = 2

# === BPF 보안 ===
net.core.bpf_jit_harden = 2

# === 네트워크 보안 ===
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.tcp_syncookies = 1
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

# === 파일시스템 보안 ===
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
fs.protected_fifos = 2
fs.protected_regular = 2
SYSCTL_EOF

# 적용
sudo sysctl --system

부팅 파라미터 보안 설정

커널 명령줄 파라미터(/proc/cmdline)를 통해 부팅 시점에 보안 설정을 제어할 수 있습니다.

# /etc/default/grub에 보안 부팅 파라미터 추가
GRUB_CMDLINE_LINUX="lockdown=integrity lsm=lockdown,capability,landlock,yama,apparmor \
    init_on_alloc=1 slab_nomerge page_alloc.shuffle=1 vsyscall=none debugfs=off \
    randomize_kstack_offset=on"

# 적용
sudo update-grub  # Debian/Ubuntu
sudo grub2-mkconfig -o /boot/grub2/grub.cfg  # RHEL/Fedora

커널 컴파일 보안 옵션 체크리스트

컨테이너 보안 아키텍처

컨테이너는 Linux 커널의 여러 보안 메커니즘을 조합하여 격리를 구현합니다. 단일 기술이 아닌 Namespace + Cgroup + seccomp + LSM + Capabilities의 다층 보안 모델이 컨테이너의 격리 경계를 형성합니다.

컨테이너 격리 메커니즘

컨테이너 기본 Capability (Docker/Podman)

컨테이너 런타임은 기본적으로 root 컨테이너에도 제한된 Capability만 부여합니다:

# 실습 예제: 컨테이너 보안 설정

# 모든 capability 차단 후 필요한 것만 추가
docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE nginx

# seccomp 프로파일 지정
docker run --security-opt seccomp=custom-profile.json myapp

# read-only 루트 파일시스템
docker run --read-only --tmpfs /tmp myapp

# user namespace 활성화 (rootless)
podman run --userns=keep-id myapp

# 컨테이너의 보안 상태 확인
docker inspect --format '{{.HostConfig.SecurityOpt}}' container_name
docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.CapDrop}}' container_name

User Namespace와 Capability 격리

User namespace는 UID/GID 매핑과 Capability 격리를 제공하여 rootless 컨테이너의 핵심을 이룹니다. User namespace 내부의 root(uid 0)는 해당 namespace 내에서만 capability를 갖고, 호스트에서는 일반 사용자로 동작합니다.

개념 예시: User namespace 기반 권한 격리


호스트: uid=1000 (일반 사용자)
  │
  └─ unshare(CLONE_NEWUSER) → User namespace 생성
       │
       ├─ /proc/self/uid_map: "0 1000 1"
       │   → ns 내부 uid 0 = 호스트 uid 1000
       │
       ├─ ns 내부: uid=0, cap_effective=ALL
       │   → mount, chroot 등 가능 (ns 내부에서만)
       │
       └─ 호스트 관점: uid=1000, 일반 사용자
           → 호스트 자원에 대한 권한 없음

capable(CAP_SYS_ADMIN) 호출 시:
  1. ns_capable(current_user_ns, CAP_SYS_ADMIN) → true (ns 내부)
  2. ns_capable(init_user_ns, CAP_SYS_ADMIN) → false (호스트)
  → 결과는 검사 대상 namespace에 따라 달라짐

보안 모니터링과 침해 감지

커널 보안 메커니즘은 사전 방어(Prevention)뿐 아니라 감지(Detection)와 대응(Response)도 포함합니다. 런타임 보안 모니터링은 eBPF, Audit, ftrace를 기반으로 합니다.

모니터링 접근 방식

커널 보안 모니터링은 크게 세 가지 접근 방식으로 나뉩니다:

커널 기반 보안 모니터링 도구

# 실습 예제: eBPF 기반 보안 모니터링

# bpftrace로 권한 상승 시도 감지
sudo bpftrace -e '
kprobe:commit_creds {
    $new = (struct cred *)arg0;
    $old = (struct cred *)curtask->real_cred;
    if ($new->uid.val == 0 && $old->uid.val != 0) {
        printf("ALERT: uid escalation %d -> 0, comm=%s, pid=%d\n",
               $old->uid.val, comm, pid);
    }
}'

# 커널 모듈 로드 감시
sudo bpftrace -e '
kprobe:do_init_module {
    printf("MODULE LOAD: %s by pid=%d comm=%s\n",
           str(((struct module *)arg0)->name), pid, comm);
}'

# 의심스러운 프로세스 실행 감시 (ftrace)
echo 1 > /sys/kernel/debug/tracing/events/sched/sched_process_exec/enable
cat /sys/kernel/debug/tracing/trace_pipe

커널 수준 침해 지표 (IoC)

최신 보안 기술 동향

리눅스 커널 보안은 지속적으로 발전하고 있으며, 최근에는 io_uring 보안 강화, eBPF 기반 보안, Rust 언어 도입이 주요 화제입니다.

io_uring 보안

io_uring은 고성능 비동기 I/O 인터페이스이지만, 커널 내에서 많은 시스템 콜을 대신 실행하므로 보안 표면이 매우 넓습니다. seccomp 필터를 우회하여 제한된 시스템 콜을 io_uring을 통해 실행할 수 있는 문제가 보고되어, 보안이 중요한 환경에서는 io_uring 사용을 제한하는 것이 권장됩니다.

# io_uring 제한 설정 (커널 6.6+)
# 0: 모두 허용, 1: 비특권 사용자 차단, 2: 완전 비활성화
sudo sysctl kernel.io_uring_disabled=2

# 컨테이너 환경에서 io_uring 차단 (seccomp 프로파일)
# docker run --security-opt seccomp=io_uring_blocked.json ...

eBPF 보안

eBPF(extended Berkeley Packet Filter)는 강력한 커널 프로그래밍 능력을 제공하지만, 동시에 보안 위험을 내포합니다. 검증기(verifier) 우회 취약점이 발견되면 커널 메모리를 읽고 쓸 수 있으므로, 비특권 eBPF 사용을 제한하는 것이 중요합니다.

Rust 도입과 메모리 안전성

리눅스 커널 6.1부터 Rust 언어 지원이 공식 도입되었습니다. Rust의 소유권(Ownership) 시스템과 빌림 검사(Borrow Checker)는 C 코드에서 빈번한 메모리 오류(UAF, 버퍼 오버플로, 초기화되지 않은 변수)를 컴파일 시점에 차단합니다.

현재 Rust로 작성된 커널 구성요소는 초기 단계이며, 주로 드라이버(예: Apple GPU 드라이버, Android Binder IPC) 개발에 활용되고 있습니다. 핵심 서브시스템(스케줄러, 메모리 관리)의 Rust 전환은 장기적 과제입니다.

// 개념 예시: Rust 커널 모듈의 안전성

// C 코드에서 흔한 UAF 패턴:
//   struct cred *old = current_cred();
//   put_cred(old);        /* 해제 */
//   old->uid;             /* ← UAF! 컴파일 오류 없음 */

// Rust에서는 소유권 시스템이 이를 컴파일 시점에 차단:
fn example(cred: Box<Cred>) {
    let uid = cred.uid();  // OK: cred 소유권 있음
    drop(cred);            // 명시적 해제
    // cred.uid();          // ← 컴파일 오류!
    // error[E0382]: borrow of moved value: `cred`
}

// 데이터 레이스도 타입 시스템에서 차단:
// Send + Sync 트레잇이 없는 타입은 스레드 간 공유 불가
// Arc<Mutex<T>>로 명시적 동기화 필요

공급망 보안 (Supply Chain Security)

커널과 배포판의 공급망 보안은 빌드 과정, 패키지 서명, 재현 가능 빌드(Reproducible Build)를 통해 소프트웨어 변조를 방지합니다.

커널 버전별 주요 보안 기능

보안 트러블슈팅

보안 메커니즘이 정상 동작을 차단하는 경우, 체계적인 디버깅 절차가 필요합니다. "보안을 비활성화"하는 것이 아니라 "올바른 정책을 설정"하는 것이 목표입니다.

SELinux AVC 거부 디버깅

# 1단계: AVC 거부 로그 확인
sudo ausearch -m avc -ts recent
# type=AVC msg=audit(1234567890.123:456): avc:  denied  { read }
#   for  pid=1234 comm="nginx" name="index.html"
#   scontext=system_u:system_r:httpd_t:s0
#   tcontext=system_u:object_r:default_t:s0 tclass=file

# 2단계: 문제 원인 분석 (잘못된 파일 컨텍스트인 경우가 많음)
ls -Z /var/www/html/index.html
# default_t ← 잘못된 타입. httpd_sys_content_t여야 함

# 3단계: 파일 컨텍스트 복원
sudo restorecon -Rv /var/www/html/

# 또는: 수동 컨텍스트 변경
sudo chcon -t httpd_sys_content_t /var/www/html/index.html

# 4단계: 정책 모듈이 필요한 경우
sudo ausearch -m avc -ts recent | audit2allow -m myfix
# 생성된 .te 파일을 검토한 후:
sudo ausearch -m avc -ts recent | audit2allow -M myfix
sudo semodule -i myfix.pp

# 주의: audit2allow를 무분별하게 사용하면 보안이 약화됩니다
# 반드시 생성된 규칙을 검토하고 최소 권한만 허용하세요

AppArmor 프로파일 디버깅

# 1단계: AppArmor 로그 확인
sudo journalctl -k | grep -i apparmor
# audit: type=1400 ... apparmor="DENIED" operation="open"
#   profile="/usr/sbin/nginx" name="/var/log/custom/access.log"

# 2단계: complain 모드로 전환 (차단 없이 로깅만)
sudo aa-complain /usr/sbin/nginx

# 3단계: 정상 동작 수행 후 로그에서 필요한 규칙 확인
sudo aa-logprof

# 4단계: 프로파일에 규칙 추가 후 enforce 모드로 복귀
sudo aa-enforce /usr/sbin/nginx

seccomp 차단 디버깅

# seccomp에 의한 SIGSYS 감지
dmesg | grep -i seccomp
# audit: type=1326 ... sig=31 syscall=314 compat=0 ip=0x7f... code=0x0

# syscall 번호 → 이름 변환
ausyscall 314
# io_uring_setup

# strace로 차단되는 시스템 콜 확인
strace -f -e trace=process,network ./myapp 2>&1 | grep -i seccomp

# 컨테이너에서 seccomp 프로파일 디버깅
docker run --security-opt seccomp=unconfined myapp  # 임시 비활성화 (디버깅 전용)

Capability 부족 디버깅

# Audit 로그에서 capability 거부 확인
sudo ausearch -m SYSCALL,PROCTITLE -k cap_check -ts recent

# 프로세스의 현재 capability 확인
cat /proc/$(pidof nginx)/status | grep Cap
# CapEff: 0000000000002000  ← CAP_NET_BIND_SERVICE만 있음

# 비트마스크 디코딩
capsh --decode=0000000000002000
# 0x0000000000002000=cap_net_bind_service

# 필요한 capability 추가 (systemd 서비스)
# [Service]
# CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_RAW
# AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_NET_RAW

# 또는 파일 capability 설정
sudo setcap 'cap_net_bind_service,cap_net_raw=ep' /usr/sbin/myserver

보안 점검 체크리스트

# 자동화된 보안 점검 스크립트 예시
#!/bin/bash

echo "=== 커널 보안 점검 ==="

# KASLR
if ! grep -q nokaslr /proc/cmdline 2>/dev/null; then
    echo "[OK] KASLR 활성화"
else
    echo "[WARN] KASLR 비활성화 (nokaslr 부팅 파라미터)"
fi

# kptr_restrict
kptr=$(cat /proc/sys/kernel/kptr_restrict)
if [ "$kptr" -ge 1 ]; then
    echo "[OK] kptr_restrict = $kptr"
else
    echo "[WARN] kptr_restrict = $kptr (권장: 1 이상)"
fi

# Spectre/Meltdown
for vuln in /sys/devices/system/cpu/vulnerabilities/*; do
    status=$(cat "$vuln" 2>/dev/null)
    name=$(basename "$vuln")
    if echo "$status" | grep -qi "mitigation"; then
        echo "[OK] $name: $status"
    elif echo "$status" | grep -qi "not affected"; then
        echo "[OK] $name: Not affected"
    else
        echo "[WARN] $name: $status"
    fi
done

# LSM
lsm=$(cat /sys/kernel/security/lsm 2>/dev/null)
echo "[INFO] 활성 LSM: $lsm"

echo "=== 점검 완료 ==="

관련 문서

커널 보안은 단일 기술이 아닌 여러 계층의 메커니즘이 조합되어 동작합니다. 각 하위 주제에 대한 내용은 아래 전용 문서를 참고하세요. 허브 페이지인 이 문서에서 전체적인 아키텍처와 상호 관계를 파악한 후, 개별 주제의 기술 문서로 진행하는 것이 권장됩니다.

• 커널 보안 취약점 사례 — Spectre, Meltdown, Dirty COW 등
• LSM / Seccomp — 리눅스 보안 모듈
• eBPF 보안 정책 — eBPF 기반 보안 모니터링
• Linux Crypto Framework — 커널 암호화 API
• mprotect — 메모리 보호와 접근 권한 제어
• 시스템 콜 — 시스템 콜 권한 검사
• 커널 모듈 — 모듈 서명
• Secure Boot — 부팅 보안
• Audit 서브시스템 — 커널 감사 프레임워크
• 커널 하드닝 — KASLR, CFI, Spectre/Meltdown 방어
• IMA/EVM — Measure/Appraise/Audit, 정책 문법, 템플릿, 원격증명
• Key Retention Service (키링(Keyring)) — key_type, 키링 계층, keyctl API, TPM Sealed Keys
• 기밀 컴퓨팅(Confidential Computing) — AMD SEV/TDX/ARM CCA, 메모리 암호화, 증명 프로토콜
• ARM TrustZone & OP-TEE — Secure World, TEE 프레임워크, TA 개발
• 공급망 보안(Supply Chain Security) — SLSA, 서명, 재현 가능 빌드, SBOM
• LKRG (커널 런타임 가드) — 코드 무결성, 자격증명 모니터링

외부 참고 자료

• Linux Kernel Security Subsystem Documentation — 커널 공식 보안 서브시스템 문서입니다
• Kernel Self Protection Project (KSPP) — 커널 자체 보호 프로젝트 공식 사이트입니다
• Credentials in Linux — 커널 Credentials(자격 증명) 메커니즘 공식 문서입니다
• Linux Security Module Framework — LSM 프레임워크 커널 공식 문서입니다
• LSM Admin Guide — LSM 관리자 가이드로 SELinux, AppArmor, TOMOYO, Smack 등의 설정을 다룹니다
• capabilities(7) — Linux man page — POSIX Capabilities 전체 목록과 사용법입니다
• Linux Kernel CVE Details — 리눅스 커널 CVE 취약점 데이터베이스입니다
• Linux 커널 security/ 디렉토리 — 커널 보안 서브시스템 소스 코드입니다