커널 보안 (Kernel Security)

LSM 프레임워크, SELinux, AppArmor, Landlock, seccomp-bpf, Credentials & Capabilities, 커널 하드닝, Audit 서브시스템.

1. 커널 보안 아키텍처 개요

Linux 커널의 보안 모델은 전통적인 DAC(Discretionary Access Control)에서 출발하여, MAC(Mandatory Access Control), 그리고 이를 유연하게 지원하는 LSM(Linux Security Modules) 프레임워크로 발전해왔습니다.

security/ 소스 트리 구조

2. LSM (Linux Security Modules) 프레임워크

LSM은 커널에 보안 정책을 플러그인 형태로 삽입할 수 있는 프레임워크입니다. 시스템 콜 경로의 핵심 지점에 보안 훅(security hook)을 배치하여, 접근 제어 결정을 LSM 모듈에 위임합니다.

LSM 아키텍처

/* include/linux/lsm_hooks.h */
struct security_hook_heads {
    struct hlist_head bprm_creds_for_exec;
    struct hlist_head bprm_creds_from_file;
    struct hlist_head task_alloc;
    struct hlist_head task_free;
    struct hlist_head inode_permission;
    struct hlist_head file_open;
    struct hlist_head socket_create;
    /* ... 약 230개의 훅 포인트 ... */
};

/* 각 LSM 모듈이 훅을 등록하는 구조체 */
struct security_hook_list {
    struct hlist_node         list;
    struct hlist_head         *head;
    union security_list_options hook;
    const struct lsm_id      *lsmid;
};

/* security/security.c - 글로벌 훅 헤드 */
struct security_hook_heads security_hook_heads __ro_after_init;

LSM 호출 흐름:

주요 LSM 훅 카테고리

LSM 스태킹 (Kernel 6.x+)

커널 6.x부터 여러 major LSM을 동시에 활성화할 수 있습니다 (LSM stacking). 이전에는 SELinux, AppArmor, SMACK 중 하나만 major로 사용할 수 있었습니다.

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

# 부트 커맨드라인으로 LSM 순서 지정
# lsm=lockdown,capability,landlock,yama,selinux

# 빌드 시 기본 LSM 순서 설정
# CONFIG_LSM="lockdown,capability,landlock,yama,apparmor,selinux"

3. SELinux

SELinux(Security-Enhanced Linux)는 NSA가 개발한 MAC 시스템으로, Type Enforcement(TE), RBAC(Role-Based Access Control), MLS/MCS(Multi-Level/Multi-Category Security) 모델을 결합한 가장 포괄적인 리눅스 보안 프레임워크입니다. RHEL, Fedora, CentOS 등에서 기본 활성화되며, 커널 소스 security/selinux/ 디렉토리에 약 30,000줄 이상의 코드로 구현됩니다.

Type Enforcement (TE) 모델

TE는 SELinux의 핵심 모델로, 모든 프로세스(subject)와 자원(object)에 보안 컨텍스트(security context)를 부여하고, 정책 규칙에 따라 접근을 허용/거부합니다. 프로세스의 타입을 도메인(domain), 자원의 타입을 타입(type)이라 부릅니다.

# 보안 컨텍스트 확인
ls -Z /etc/passwd
# system_u:object_r:passwd_file_t:s0 /etc/passwd

ps -eZ | grep sshd
# system_u:system_r:sshd_t:s0-s0:c0.c1023  1234 ?  sshd

# 컨텍스트 형식: user:role:type:level
# user   - SELinux 사용자 (system_u, unconfined_u 등)
# role   - 역할 (system_r, object_r, unconfined_r)
# type   - 타입/도메인 (핵심 - TE 정책의 단위)
# level  - MLS/MCS 레벨 (s0, s0:c0.c1023)

TE 모델에서 attribute는 여러 타입을 그룹화하는 메타 타입으로, 정책 작성을 간소화합니다. 예를 들어 domain attribute는 모든 프로세스 도메인을, file_type은 모든 파일 타입을 묶습니다.

# attribute 정의 및 사용
attribute domain;
attribute file_type;

# httpd_t를 domain attribute에 연결
typeattribute httpd_t domain;

# domain attribute를 사용한 일괄 규칙 (모든 도메인에 적용)
allow domain self : process { fork signal_perms };
allow domain proc_t : dir { search getattr };

보안 컨텍스트와 정책 규칙

TE 정책은 allow 외에도 여러 종류의 규칙을 지원하며, 각각 다른 목적으로 사용됩니다.

# TE 정책 규칙 형식
# allow source_type target_type : object_class { permissions };

# 예: httpd가 http_port_t에 TCP 연결 허용
allow httpd_t http_port_t : tcp_socket { name_connect };

# 예: httpd가 httpd_sys_content_t 파일을 읽기 허용
allow httpd_t httpd_sys_content_t : file { read open getattr };

# neverallow — 정책 컴파일 시 위반 검사 (런타임이 아님)
# 커널 도메인이 사용자 홈 파일에 쓰기 금지
neverallow kernel_t user_home_t : file write;

# auditallow — 허용하면서 감사 로그 기록
# (기본적으로 allow된 접근은 로그하지 않음)
auditallow admin_t shadow_t : file { read };

# dontaudit — 거부하되 감사 로그 생략 (로그 노이즈 감소)
dontaudit httpd_t etc_t : dir { getattr search };

# 타입 전이 (type transition)
# init_t가 httpd_exec_t를 실행하면 httpd_t 도메인으로 전이
type_transition init_t httpd_exec_t : process httpd_t;

RBAC (Role-Based Access Control)

RBAC는 SELinux 사용자가 어떤 역할(role)을 맡을 수 있는지, 각 역할이 어떤 도메인으로 전이할 수 있는지를 제어합니다. TE가 "프로세스가 자원에 무엇을 할 수 있는가"를 결정한다면, RBAC는 "사용자가 어떤 프로세스 도메인으로 진입할 수 있는가"를 결정합니다.

# 역할 정의
role system_r;
role sysadm_r;
role staff_r;
role user_r;

# 역할이 진입할 수 있는 도메인 지정
role system_r types { kernel_t init_t sshd_t httpd_t };
role sysadm_r types { sysadm_t passwd_t su_t };
role user_r   types { user_t user_home_t };

# 역할 전이 허용 (role allow)
# sysadm_r → system_r 전이 허용
allow sysadm_r system_r;

# 역할 전이 규칙 (role_transition)
# staff_r 사용자가 sudo_exec_t를 실행하면 sysadm_r로 전이
role_transition staff_r sudo_exec_t sysadm_r;

# SELinux 사용자 → 역할 매핑
# staff_u는 staff_r과 sysadm_r 역할을 사용 가능
user staff_u roles { staff_r sysadm_r };
user user_u  roles { user_r };

# 현재 사용자의 SELinux 컨텍스트 확인
id -Z
# staff_u:staff_r:staff_t:s0-s0:c0.c1023

# SELinux 사용자와 Linux 사용자 매핑 관리
semanage login -l
# Login Name    SELinux User   MLS/MCS Range      Service
# root          unconfined_u   s0-s0:c0.c1023     *
# __default__   unconfined_u   s0-s0:c0.c1023     *

# 특정 Linux 사용자를 제한된 SELinux 사용자에 매핑
semanage login -a -s staff_u devuser

MLS/MCS (Multi-Level Security)

MLS(Multi-Level Security)는 군사/정부 등급의 보안 모델(Bell-LaPadula)을 구현하며, sensitivity(민감도)와 category(범주) 레벨로 구성됩니다. MCS(Multi-Category Security)는 MLS의 간소화 버전으로, sensitivity를 단일 레벨(s0)로 고정하고 category만 사용합니다.

# MLS 레벨 형식: sensitivity[:category,...]
# sensitivity: s0 (가장 낮음) ~ s15 (가장 높음)
# category: c0 ~ c1023 (자원 분류)

# 예: s0         → 최저 민감도, 범주 없음
# 예: s0:c0.c255 → 최저 민감도, 범주 0~255
# 예: s3:c5,c9   → 민감도 3, 범주 5와 9

# MLS 정책 규칙 (range_transition)
# sshd가 로그인 프로세스 생성 시 사용자 MLS 범위 적용
range_transition sshd_t login_exec_t : process s0 - s15:c0.c1023;

# MLS 제약 (constraints)
# "No Write Down": 높은 레벨이 낮은 레벨에 쓰기 금지
mlsconstrain file { write append }
    ( l1 domby l2 or t1 == mlsfilewritedown );

# "No Read Up": 낮은 레벨이 높은 레벨 읽기 금지
mlsconstrain file { read getattr execute }
    ( l1 dom l2 or t1 == mlsfilereadtoclr );

도메인 전이 (Domain Transition)

도메인 전이는 프로세스가 다른 프로그램을 execve()할 때 새로운 SELinux 도메인으로 전환되는 메커니즘입니다. 이를 위해 세 가지 조건이 모두 충족되어야 합니다.

# 도메인 전이를 위한 3가지 필수 규칙

# 1. type_transition: 자동 전이 규칙 정의
# init_t가 httpd_exec_t를 실행하면 → httpd_t로 전이
type_transition init_t httpd_exec_t : process httpd_t;

# 2. allow (process transition): 소스 도메인이 대상 도메인으로 전이 허용
allow init_t httpd_t : process transition;

# 3. allow (file execute + entrypoint): 실행 파일에 대한 접근
allow init_t httpd_exec_t : file { execute open read getattr };
allow httpd_t httpd_exec_t : file entrypoint;

커널 내부 구현

SELinux의 커널 구현은 security/selinux/ 디렉토리에 위치하며, LSM 훅을 통해 커널의 모든 접근 제어 지점에 개입합니다.

/* security/selinux/include/security.h */
/* selinux_state: SELinux 전역 상태 관리 구조체 */
struct selinux_state {
    bool disabled;
    bool initialized;
    bool policycap[__POLICYDB_CAP_MAX];

    struct selinux_avc    *avc;       /* Access Vector Cache */
    struct selinux_policy __rcu *policy; /* 활성 정책 (RCU 보호) */
};

/* security/selinux/ss/policydb.h */
/* policydb: 로드된 정책의 전체 데이터베이스 */
struct policydb {
    struct symtab symtab[SYM_NUM]; /* 심볼 테이블: type, role, user, bool, ... */
    struct avtab  te_avtab;       /* TE Access Vector 테이블 */
    struct avtab  te_cond_avtab;  /* 조건부(boolean) TE 규칙 */
    struct role_trans *role_tr;   /* 역할 전이 규칙 */
    struct range_trans *range_tr; /* MLS 범위 전이 규칙 */
    struct ocontext *ocontexts[OCON_NUM]; /* 초기 SID, 포트, 네트워크 등 */
    struct genfs *genfs;        /* genfscon - 파일시스템 컨텍스트 */
    /* ... */
};

/* security/selinux/hooks.c - 주요 LSM 훅 */
/* 파일 열기 시 접근 검사 */
static int selinux_file_open(struct file *file)
{
    struct inode_security_struct *isec = selinux_inode(file_inode(file));
    return file_has_perm(current_cred(), file, file_to_av(file));
}

/* 프로세스 생성(fork) 시 보안 컨텍스트 상속 */
static int selinux_task_alloc(struct task_struct *task,
                               unsigned long clone_flags)
{
    return avc_has_perm(current_sid(), task_sid_obj(task),
                        SECCLASS_PROCESS, PROCESS__FORK, NULL);
}

/* SID (Security Identifier) 테이블 */
struct sidtab {
    union {
        struct sidtab_node  *leaf;
        struct sidtab_node **inner;
    } roots[SIDTAB_MAX_LEVEL + 1];
    u32 count;
    struct sidtab_convert_params *convert; /* 정책 리로드 시 변환 */
    spinlock_t lock;
    /* radix tree 구조 — O(1) SID → context 조회 */
};

AVC (Access Vector Cache) 심화

AVC는 SELinux 성능의 핵심으로, 정책 결정 결과를 캐싱하여 반복적인 policydb 조회를 방지합니다. 해시 테이블 기반으로 구현되며, seqlock을 사용하여 읽기 경로의 동기화 오버헤드를 최소화합니다.

/* security/selinux/avc.c */
/* AVC 엔트리 구조 */
struct avc_entry {
    u32 ssid;       /* Source SID */
    u32 tsid;       /* Target SID */
    u16 tclass;     /* Object class */
    struct av_decision avd; /* 캐싱된 결정 */
};

struct av_decision {
    u32 allowed;    /* 허용된 permission 비트마스크 */
    u32 auditallow; /* 감사 로그 대상 허용 */
    u32 auditdeny;  /* 감사 로그 대상 거부 */
    u32 seqno;      /* 정책 시퀀스 번호 */
    u32 flags;
};

/* AVC 접근 검사 흐름 */
int avc_has_perm(u32 ssid, u32 tsid,
                 u16 tclass, u32 requested,
                 struct common_audit_data *auditdata)
{
    struct av_decision avd;
    int rc;

    /* 1. AVC 해시 테이블에서 캐시 조회 (seqlock read) */
    rc = avc_has_perm_noaudit(ssid, tsid, tclass, requested,
                              0, &avd);

    /* 2. 캐시 미스 → security_compute_av()로 policydb 조회 */
    /*    결과를 AVC에 삽입 */

    /* 3. 감사 로그 출력 (거부 시 또는 auditallow 매칭 시) */
    avc_audit(ssid, tsid, tclass, requested, &avd, rc, auditdata);

    return rc;
}

# AVC 캐시 통계 확인
cat /sys/fs/selinux/avc/cache_stats
# lookups hits misses allocations reclaims frees
# 234891  231205  3686  3686  1024  960

# 캐시 히트율 계산: hits / lookups × 100
# 위 예시: 231205 / 234891 × 100 ≈ 98.4% (양호)

# AVC 캐시 수동 플러시 (정책 디버깅 시)
echo 1 > /sys/fs/selinux/avc/cache_stats

정책 컴파일 파이프라인

SELinux 정책은 텍스트 소스에서 바이너리 정책으로 컴파일되어 커널에 로드됩니다. Reference Policy를 기반으로 모듈화된 정책 관리가 가능합니다.

# 커스텀 정책 모듈 빌드 워크플로우

# 1. Type Enforcement 소스 작성 (mymodule.te)
cat > mymodule.te << 'EOF'
policy_module(mymodule, 1.0.0)
require {
    type httpd_t;
    type myapp_data_t;
    class file { read open getattr };
}
allow httpd_t myapp_data_t : file { read open getattr };
EOF

# 2. 파일 컨텍스트 정의 (mymodule.fc)
cat > mymodule.fc << 'EOF'
/opt/myapp(/.*)?  system_u:object_r:myapp_data_t:s0
EOF

# 3. 컴파일 및 패키징
checkmodule -M -m -o mymodule.mod mymodule.te
semodule_package -o mymodule.pp -m mymodule.mod -f mymodule.fc

# 4. 커널에 로드
semodule -i mymodule.pp

# 5. 로드된 모듈 확인
semodule -l | grep mymodule

# CIL 직접 사용 (SELinux 3.0+)
# .cil 파일은 Lisp-like 문법으로 checkmodule 없이 직접 로드
semodule -i mymodule.cil

SELinux 파일시스템 (selinuxfs)

/sys/fs/selinux/에 마운트되는 selinuxfs는 커널 SELinux 서브시스템과의 사용자 공간 인터페이스를 제공합니다. 정책 로드, 상태 조회, AVC 관리 등의 모든 상호작용이 이 가상 파일시스템을 통해 이루어집니다.

# selinuxfs 주요 인터페이스
ls /sys/fs/selinux/

# 상태 및 제어
/sys/fs/selinux/enforce        # 0=permissive, 1=enforcing (읽기/쓰기)
/sys/fs/selinux/disable        # SELinux 비활성화 (부팅 후 1회 쓰기)
/sys/fs/selinux/policyvers     # 지원하는 정책 바이너리 버전
/sys/fs/selinux/status         # mmap 가능한 상태 페이지 (변경 알림)

# 정책 관리
/sys/fs/selinux/load           # 바이너리 정책 로드 (쓰기 전용)
/sys/fs/selinux/policy         # 현재 로드된 정책 바이너리 (읽기 전용)
/sys/fs/selinux/checkreqprot   # mmap/mprotect 검사 방식 (deprecated)

# AVC 관리
/sys/fs/selinux/avc/
    cache_stats                # lookups, hits, misses 통계
    cache_threshold            # 캐시 크기 임계값
    hash_stats                 # 해시 체인 길이 분포

# 컨텍스트 조회/변환
/sys/fs/selinux/context        # 컨텍스트 유효성 검사
/sys/fs/selinux/access         # 접근 결정 조회 (selinux_check_access)
/sys/fs/selinux/member         # 멤버 결정 (type 결합)
/sys/fs/selinux/create         # 새 객체 컨텍스트 계산
/sys/fs/selinux/relabel        # 릴레이블 허용 여부 확인

# Boolean 관리
/sys/fs/selinux/booleans/      # 디렉토리 내 boolean별 파일
/sys/fs/selinux/commit_pending_bools # boolean 변경 커밋

# 초기 SID 매핑
/sys/fs/selinux/initial_contexts/
    kernel                     # 커널 초기 SID 컨텍스트
    unlabeled                  # 레이블 없는 객체 기본 컨텍스트
    file                       # 레이블 없는 파일 기본 컨텍스트

/* security/selinux/selinuxfs.c */
/* 사용자 공간 라이브러리(libselinux)는 이 인터페이스를 사용 */

/* 예: libselinux의 is_selinux_enabled() 구현 */
/* → /sys/fs/selinux/ 마운트 여부 확인 */
/* → /sys/fs/selinux/enforce 읽기 */

/* 예: security_compute_av() 사용자 공간 호출 */
/* → /sys/fs/selinux/access에 ssid, tsid, tclass 쓰기 */
/* → 커널이 avc_has_perm 결과 반환 */

네트워크 레이블링

SELinux는 네트워크 패킷에도 보안 레이블을 부여하여 호스트 간 MAC을 확장합니다. CIPSO(Commercial IP Security Option), NetLabel, labeled IPsec 세 가지 메커니즘을 지원합니다.

# 네트워크 레이블링 정책 규칙

# portcon — 포트에 기본 컨텍스트 할당
portcon tcp 80 system_u:object_r:http_port_t:s0
portcon tcp 443 system_u:object_r:http_port_t:s0

# nodecon — 네트워크 노드에 컨텍스트 할당
nodecon 192.168.1.0 255.255.255.0 system_u:object_r:intranet_node_t:s0

# netifcon — 네트워크 인터페이스에 컨텍스트 할당
netifcon eth0 system_u:object_r:netif_t:s0 system_u:object_r:netmsg_t:s0

# peer 레이블링 — IPsec/CIPSO 기반 원격 피어 레이블 인식
allow myapp_t remote_peer_t : peer recv;

# NetLabel 설정 (CIPSO 기반 네트워크 레이블링)

# CIPSO DOI (Domain of Interpretation) 설정
netlabelctl cipsov4 add local doi:1

# MLS 레벨을 CIPSO 태그로 매핑
netlabelctl map add domain:httpd_t protocol:cipsov4,1

# 현재 NetLabel 설정 확인
netlabelctl -p map list

# labeled IPsec 설정 (IPsec SA에 보안 레이블 연결)
# /etc/ipsec.conf에서 policy-label 지정
# → 커널 xfrm 프레임워크가 SA의 SELinux 컨텍스트 관리

# SELinux 네트워크 관련 boolean
getsebool -a | grep network
# selinuxuser_ping → off
# httpd_can_network_connect → off
# httpd_can_network_relay → off

관리 명령

# 동작 모드 확인/변경
getenforce              # Enforcing / Permissive / Disabled
setenforce 0            # Permissive로 전환 (런타임)
sestatus                # 상세 상태 정보

# AVC 거부 로그 분석 → 정책 모듈 생성
ausearch -m avc --start today | audit2allow -M mypolicy
semodule -i mypolicy.pp

# Boolean (정책 조건부 활성화)
getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on

# 파일 컨텍스트 관리
semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"
restorecon -Rv /web

# 포트 관리
semanage port -a -t http_port_t -p tcp 8080

# 특정 도메인을 permissive 모드로 설정 (전체 시스템 영향 없이)
semanage permissive -a httpd_t
# 해제
semanage permissive -d httpd_t

SELinux 디버깅 및 트러블슈팅

SELinux 문제 해결의 핵심은 AVC 거부 메시지 분석입니다. 체계적인 접근법으로 대부분의 문제를 해결할 수 있습니다.

# 1단계: AVC 거부 메시지 수집
ausearch -m avc,user_avc -ts recent
# type=AVC msg=audit(1234567890.123:456): avc:  denied  { read }
# for  pid=1234 comm="httpd" name="index.html"
# dev="sda1" ino=67890
# scontext=system_u:system_r:httpd_t:s0
# tcontext=unconfined_u:object_r:default_t:s0
# tclass=file permissive=0

# 2단계: 원인 분석 (audit2why)
ausearch -m avc -ts recent | audit2why
# 가능한 원인:
#   - Missing allow rule → 정책 규칙 부재
#   - Wrong file context → restorecon 필요
#   - Boolean off        → setsebool 필요
#   - Constrained        → MLS/RBAC 제약

# 3단계: 해결 방안 적용

# Case A: 잘못된 파일 컨텍스트
ls -Z /opt/myapp/index.html
# → default_t (잘못됨)
restorecon -Rv /opt/myapp/
# → httpd_sys_content_t (올바름)

# Case B: Boolean 비활성화
audit2why 출력에 "boolean httpd_can_network_connect" 표시 시:
setsebool -P httpd_can_network_connect on

# Case C: 커스텀 정책 필요
ausearch -m avc -ts recent | audit2allow -M myfix
# 반드시 생성된 .te 파일 검토 후 로드!
cat myfix.te     # 불필요하게 넓은 권한이 아닌지 확인
semodule -i myfix.pp

# 4단계: dontaudit 규칙이 숨긴 거부 확인
# dontaudit 비활성화하여 숨겨진 거부 메시지 표시
semodule -DB      # 모든 dontaudit 규칙 비활성화
# (문제 재현 후 로그 확인)
semodule -B       # dontaudit 규칙 복원

# 유용한 디버깅 도구
sesearch -A -s httpd_t -t httpd_sys_content_t  # 허용 규칙 검색
sesearch -D -s httpd_t                          # dontaudit 규칙 검색
seinfo -t | wc -l                               # 전체 타입 수
seinfo -r                                       # 정의된 역할 목록
seinfo -u                                       # SELinux 사용자 목록

4. AppArmor

AppArmor는 경로(path) 기반 MAC 시스템으로, 프로파일 파일에 프로그램별 접근 규칙을 정의합니다. Ubuntu, SUSE, Debian 등에서 기본 사용됩니다.

프로파일 기반 접근 제어

# /etc/apparmor.d/usr.sbin.nginx
# AppArmor 프로파일 예제

/usr/sbin/nginx {
  # 네트워크 접근
  network inet stream,
  network inet6 stream,

  # 파일 접근 규칙
  /etc/nginx/** r,           # 설정 읽기
  /var/log/nginx/** w,       # 로그 쓰기
  /var/www/** r,             # 웹 콘텐츠 읽기
  /run/nginx.pid rw,         # PID 파일
  /usr/sbin/nginx mr,        # 자기 자신 실행/mmap

  # capability
  capability net_bind_service,
  capability setuid,
  capability setgid,

  # 시그널
  signal (receive) peer=unconfined,
}

# 프로파일 관리
aa-status                    # 활성 프로파일 목록
aa-enforce /etc/apparmor.d/usr.sbin.nginx   # enforce 모드
aa-complain /etc/apparmor.d/usr.sbin.nginx  # complain(학습) 모드
aa-disable /etc/apparmor.d/usr.sbin.nginx   # 비활성화

# 새 프로파일 자동 생성 (학습 모드)
aa-genprof /usr/bin/myapp

AppArmor vs SELinux 비교

커널 구현

/* security/apparmor/ 핵심 구조체 */

struct aa_profile {
    struct aa_policy      base;
    struct aa_profile     *parent;
    struct aa_ns          *ns;
    const char           *rename;
    enum audit_mode       audit;
    long                  mode;
    struct aa_policydb    file;    /* 파일 접근 규칙 */
    struct aa_policydb    policy;  /* 정책 규칙 */
    struct aa_caps        caps;    /* capability 규칙 */
    struct aa_net_compat  *net_compat; /* 네트워크 규칙 */
};

struct aa_label {
    struct kref          count;
    int                  size;   /* 프로파일 스택 크기 */
    struct aa_profile    *vec[];  /* 프로파일 배열 (stacking) */
};

5. SMACK (Simplified Mandatory Access Control Kernel)

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

# SMACK 라벨 확인
attr -S -g SMACK64 /path/to/file
# 또는
getfattr -n security.SMACK64 /path/to/file

# SMACK 규칙 형식: subject object access
# access: r(read) w(write) x(execute) a(append) t(transmute) l(lock)
echo "WebApp DataFiles rwx" > /sys/fs/smackfs/load2
echo "System WebApp rx"     > /sys/fs/smackfs/load2

# 특수 라벨
# _     : 최소 권한 (floor label)
# ^     : 최대 권한 (hat/ceiling)
# *     : 범용 접근 (star label - 모든 읽기 허용)

6. Landlock

Landlock은 커널 5.13에서 도입된 비특권(unprivileged) 샌드박싱 LSM입니다. 일반 사용자가 root 권한 없이 프로세스의 파일시스템/네트워크 접근을 제한할 수 있습니다.

Unprivileged Sandboxing 아키텍처

Landlock은 3단계 API로 동작합니다:

1. landlock_create_ruleset() — 규칙셋 생성 (어떤 접근 유형을 제어할지 정의)
2. landlock_add_rule() — 규칙 추가 (특정 파일/디렉터리에 대한 허용 규칙)
3. landlock_restrict_self() — 현재 프로세스에 규칙셋 적용 (되돌릴 수 없음)

Landlock API

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

/* 1단계: 규칙셋 생성 */
struct landlock_ruleset_attr ruleset_attr = {
    .handled_access_fs =
        LANDLOCK_ACCESS_FS_READ_FILE |
        LANDLOCK_ACCESS_FS_READ_DIR  |
        LANDLOCK_ACCESS_FS_WRITE_FILE |
        LANDLOCK_ACCESS_FS_EXECUTE,
};

int ruleset_fd = syscall(SYS_landlock_create_ruleset,
                         &ruleset_attr, sizeof(ruleset_attr), 0);

/* 2단계: 허용 규칙 추가 (화이트리스트) */
struct landlock_path_beneath_attr path_attr = {
    .allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                      LANDLOCK_ACCESS_FS_READ_DIR,
    .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);

/* /tmp에 읽기+쓰기 허용 */
path_attr.allowed_access = LANDLOCK_ACCESS_FS_READ_FILE |
                           LANDLOCK_ACCESS_FS_WRITE_FILE;
path_attr.parent_fd = open("/tmp", 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);

/* 이후 /usr 읽기, /tmp 읽기/쓰기만 가능
   다른 경로 접근 시 -EACCES 반환 */

7. seccomp-bpf 심화

seccomp(Secure Computing)은 프로세스가 호출할 수 있는 시스템 콜을 제한하는 커널 보안 메커니즘입니다. 기초적인 BPF 필터 예제는 시스템 콜 및 Linux Containers 페이지를 참조하세요. 여기서는 커널 내부 구현, 필터 체인 메커니즘, 고급 기능을 심층적으로 다룹니다.

동작 모드

/* Strict 모드 활성화 */
prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT);
/* 이후 read/write/exit/sigreturn 외 시스템 콜 → SIGKILL */

/* Filter 모드: seccomp() 시스템 콜 사용 (Linux 3.17+) */
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);  /* 필수: 권한 상승 방지 */
seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog);
/* 또는 prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, &prog); */

커널 내부 구조

/* include/linux/seccomp.h - task_struct에 포함 */
struct seccomp {
    int                    mode;    /* SECCOMP_MODE_DISABLED/STRICT/FILTER */
    atomic_t               filter_count;  /* 필터 체인 길이 */
    struct seccomp_filter  *filter; /* BPF 필터 체인 (linked list) */
};

/* kernel/seccomp.c - 필터 노드 */
struct seccomp_filter {
    refcount_t             refs;     /* 참조 카운트 (GC용) */
    refcount_t             users;    /* task 참조 수 (fork 시 증가) */
    bool                   log;      /* SECCOMP_FILTER_FLAG_LOG */
    bool                   wait_killable_recv; /* WAIT_KILLABLE_RECV 플래그 */
    struct seccomp_filter  *prev;    /* 이전 필터 (체인) */
    struct bpf_prog        *prog;    /* 컴파일된 BPF 프로그램 */
    struct notification    *notif;   /* USER_NOTIF 알림 큐 */
    struct mutex           notify_lock;
    u32                    cache[SECCOMP_ARCH_NATIVE_NR]; /* bitmap 캐시 */
};

/* include/uapi/linux/seccomp.h - BPF 필터에 전달되는 데이터 */
struct seccomp_data {
    int      nr;            /* 시스템 콜 번호 */
    __u32    arch;          /* AUDIT_ARCH_* 아키텍처 식별자 */
    __u64    instruction_pointer; /* 호출 시점 IP 레지스터 */
    __u64    args[6];      /* 시스템 콜 인자 (최대 6개) */
};

커널 실행 경로

x86_64에서 시스템 콜 진입 시 seccomp 필터는 다음 경로로 실행됩니다:

/* 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_filter() - 최종 액션 처리 */
int __seccomp_filter(int this_syscall,
                     const struct seccomp_data *sd,
                     const bool recheck_after_trace)
{
    u32 action = seccomp_run_filters(sd, &match);
    switch (action & SECCOMP_RET_ACTION_FULL) {
    case SECCOMP_RET_KILL_PROCESS:  /* 프로세스 전체 SIGKILL */
    case SECCOMP_RET_KILL_THREAD:   /* 스레드만 SIGSYS */
    case SECCOMP_RET_TRAP:          /* SIGSYS + siginfo */
    case SECCOMP_RET_ERRNO:         /* errno 반환 (하위 16비트) */
    case SECCOMP_RET_USER_NOTIF:    /* 감독자 프로세스 알림 */
    case SECCOMP_RET_TRACE:         /* ptrace 트레이서 알림 */
    case SECCOMP_RET_LOG:           /* 로깅 후 허용 */
    case SECCOMP_RET_ALLOW:         /* 허용 */
    }
}

SECCOMP_RET_* 반환 액션 우선순위

필터 체인에서 여러 필터가 서로 다른 결과를 반환하면, 가장 제한적인(숫자가 작은) 액션이 최종 적용됩니다. 아래 목록은 우선순위 순서(높은 것부터)입니다:

/* SECCOMP_RET_ERRNO 사용 예: mount()를 EPERM으로 거부 */
BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | (EPERM & SECCOMP_RET_DATA));
/* 하위 16비트(SECCOMP_RET_DATA = 0xffff)에 errno 값 인코딩 */

/* SECCOMP_RET_TRAP: 시그널 핸들러에서 정보 확인 */
void sigsys_handler(int sig, siginfo_t *info, void *ctx) {
    /* info->si_signo  = SIGSYS */
    /* info->si_code   = SYS_SECCOMP */
    /* info->si_call_addr = 호출 위치 */
    /* info->si_syscall   = 시스템 콜 번호 */
    /* info->si_arch      = AUDIT_ARCH_* */
    /* info->si_errno     = SECCOMP_RET_DATA (필터 반환 하위 16비트) */
}

필터 체인 메커니즘

seccomp 필터는 누적(additive)됩니다. 새로운 필터를 설치하면 기존 필터 앞에 추가되며, 모든 필터가 순회됩니다. 필터는 제거할 수 없으므로 점점 더 제한적으로만 변경됩니다.

/* 필터 체인 동작 원리 */

/* 1. 첫 번째 필터 설치: {read, write, exit_group} 허용 */
seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog_allow_rwe);
/* 체인: [필터#1] → NULL */

/* 2. 두 번째 필터 추가: write를 stdout(fd=1)으로만 제한 */
seccomp(SECCOMP_SET_MODE_FILTER, 0, &prog_stdout_only);
/* 체인: [필터#2] → [필터#1] → NULL */

/* 3. 실행 시: 필터#2와 필터#1 모두 실행 */
/*    결과 = min(필터#2 결과, 필터#1 결과) */
/*    → 가장 제한적인 액션이 최종 적용 */

/* 4. fork() 시: 자식은 부모 필터 체인을 참조 공유 */
/*    자식이 새 필터를 설치하면 체인 앞에 추가 */
/*    부모 필터는 변경되지 않음 */

seccomp 플래그 상세

/* TSync: 모든 스레드에 동시 적용 */
int ret = seccomp(SECCOMP_SET_MODE_FILTER,
                  SECCOMP_FILTER_FLAG_TSYNC |       /* 스레드 동기화 */
                  SECCOMP_FILTER_FLAG_LOG,           /* 거부 시 로깅 */
                  &prog);
/* ret > 0: TSYNC 실패, 반환값 = 충돌 스레드 TID (TSYNC_ESRCH) */
/* ret = 0: 성공 */

/* NEW_LISTENER: notification fd 획득 */
int listener_fd = seccomp(SECCOMP_SET_MODE_FILTER,
                          SECCOMP_FILTER_FLAG_NEW_LISTENER, &prog);
/* listener_fd를 감독자 프로세스에 전달 (Unix domain socket 등) */

/* Spectre 완화 제어 */
seccomp(SECCOMP_SET_MODE_FILTER,
        SECCOMP_FILTER_FLAG_SPEC_ALLOW,  /* IBRS/STIBP 해제 허용 */
        &prog);

SECCOMP_RET_USER_NOTIF 심화 (사용자 공간 알림)

커널 5.0+에서 SECCOMP_RET_USER_NOTIF는 시스템 콜을 사용자 공간 감독자(supervisor)에게 위임합니다. 컨테이너 런타임(runc, containerd)에서 mount, mknod 등 특정 시스템 콜을 안전하게 에뮬레이션하는 데 사용됩니다.

/* === 감독자(supervisor) 프로세스 구현 예제 === */

/* 1. 필터 설치 시 notification fd 획득 */
int notif_fd = seccomp(SECCOMP_SET_MODE_FILTER,
                       SECCOMP_FILTER_FLAG_NEW_LISTENER, &prog);

/* 2. 알림 구조체 할당 */
struct seccomp_notif *req;
struct seccomp_notif_resp *resp;
seccomp_notify_alloc(&req, &resp);

/* 3. 알림 처리 루프 */
while (1) {
    /* 대상 프로세스의 시스템 콜 알림 수신 */
    ioctl(notif_fd, SECCOMP_IOCTL_NOTIF_RECV, req);

    /* req->id   = 고유 알림 ID */
    /* req->pid  = 호출 프로세스 PID */
    /* req->data = seccomp_data (nr, arch, args[6]) */

    /* TOCTOU 방지: 대상 프로세스가 아직 블록 상태인지 확인 */
    if (ioctl(notif_fd, SECCOMP_IOCTL_NOTIF_ID_VALID, &req->id) != 0) {
        continue;  /* 대상이 이미 종료/시그널됨 */
    }

    /* 감독자가 대신 처리하고 결과 반환 */
    resp->id    = req->id;
    resp->val   = 0;     /* 시스템 콜 반환값 */
    resp->error = 0;     /* errno (0 = 성공) */
    resp->flags = 0;     /* SECCOMP_USER_NOTIF_FLAG_CONTINUE (5.5+) */
    ioctl(notif_fd, SECCOMP_IOCTL_NOTIF_SEND, resp);
}

seccomp_notify_free(req, resp);

SECCOMP_IOCTL_NOTIF_ADDFD (5.9+)

감독자가 대상 프로세스의 fd 테이블에 파일 디스크립터를 주입할 수 있습니다. openat() 같은 시스템 콜을 에뮬레이션할 때, 감독자가 파일을 열고 그 fd를 대상 프로세스에 전달하는 데 사용됩니다.

/* 감독자가 대상 프로세스에 fd 주입 */
struct seccomp_notif_addfd addfd = {
    .id        = req->id,          /* 알림 ID */
    .flags     = SECCOMP_ADDFD_FLAG_SETFD, /* 특정 fd 번호 지정 */
    .srcfd     = supervisor_fd,    /* 감독자가 열은 fd */
    .newfd     = 3,                /* 대상 프로세스에서의 fd 번호 */
    .newfd_flags = O_CLOEXEC,      /* fd 플래그 */
};

int target_fd = ioctl(notif_fd, SECCOMP_IOCTL_NOTIF_ADDFD, &addfd);
/* target_fd = 대상 프로세스에 할당된 실제 fd 번호 */

/* 이후 resp->val = target_fd로 응답하면 */
/* 대상 프로세스는 openat()의 결과로 이 fd를 받음 */

SECCOMP_USER_NOTIF_FLAG_CONTINUE (5.5+)

감독자가 resp->flags = SECCOMP_USER_NOTIF_FLAG_CONTINUE을 설정하면, 커널이 원래의 시스템 콜을 정상적으로 실행합니다. 이를 통해 감독자는 시스템 콜을 모니터링하되, 선택적으로 허용/거부할 수 있습니다.

/* 감독자: mount()를 조건부 허용 */
if (is_safe_mount(req)) {
    resp->flags = SECCOMP_USER_NOTIF_FLAG_CONTINUE; /* 원래 syscall 실행 */
    resp->error = 0;
    resp->val   = 0;  /* CONTINUE 시 val/error 무시됨 */
} else {
    resp->flags = 0;
    resp->error = -EPERM;  /* 거부 */
    resp->val   = 0;
}
ioctl(notif_fd, SECCOMP_IOCTL_NOTIF_SEND, resp);

Bitmap 최적화와 성능

커널은 seccomp 성능을 위해 여러 최적화를 적용합니다:

/* kernel/seccomp.c - Bitmap 캐시 구현 */

/* 필터 설치 시 bitmap 사전 계산 */
static void seccomp_cache_prepare_bitmap(
    struct seccomp_filter *sfilter,
    void *bitmap, const void *bitmap_prev,
    int event_nr, int syscall_nr, struct seccomp_data *sd)
{
    /* 각 syscall 번호에 대해 BPF 프로그램 실행 */
    /* 결과가 항상 SECCOMP_RET_ALLOW이면 bitmap에 기록 */
    /* 런타임에 bitmap 검사 → BPF 실행 생략으로 빠른 경로 */
}

/* 런타임 빠른 경로 검사 */
static inline bool seccomp_cache_check_allow(
    const struct seccomp_filter *sfilter,
    const struct seccomp_data *sd)
{
    int nr = sd->nr;
    /* bitmap에서 해당 syscall이 ALLOW 확정인지 검사 */
    /* 확정이면 true 반환 → 필터 체인 순회 생략 */
}

cBPF 프로그램 구조

seccomp 필터는 classic BPF(cBPF) 명령어를 사용합니다. eBPF가 아닌 cBPF를 사용하는 이유는 seccomp이 도입될 당시(3.5) eBPF가 존재하지 않았고, 보안상 cBPF의 제한된 기능이 검증에 유리하기 때문입니다.

/* cBPF 명령어 구조 */
struct sock_filter {
    __u16  code;   /* 명령어 코드 (LD/ST/ALU/JMP/RET) */
    __u8   jt;     /* true 점프 오프셋 */
    __u8   jf;     /* false 점프 오프셋 */
    __u32  k;      /* 상수값 */
};

/* seccomp 전용 제약사항 */
/* 1. BPF_LD_ABS만 허용 (포인터 역참조 불가) */
/*    → seccomp_data 구조체 필드만 읽기 가능 */
/* 2. 반환값은 반드시 SECCOMP_RET_* 상수 */
/* 3. 프로그램 크기 제한: BPF_MAXINSNS (4096 명령어) */
/* 4. 루프 불가 (forward jump만 허용) → 정지 보장 */

/* 실용적인 seccomp BPF 필터 예제 */
struct sock_filter filter[] = {
    /* 아키텍처 검사 (x86_64 전용) */
    BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
            offsetof(struct seccomp_data, arch)),
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, AUDIT_ARCH_X86_64, 1, 0),
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),

    /* 시스템 콜 번호 로드 */
    BPF_STMT(BPF_LD | BPF_W | BPF_ABS,
            offsetof(struct seccomp_data, nr)),

    /* mount(2) 차단 → EPERM */
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_mount, 0, 1),
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM),

    /* umount2(2) 차단 → EPERM */
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_umount2, 0, 1),
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ERRNO | EPERM),

    /* kexec_load(2) 차단 → KILL */
    BPF_JUMP(BPF_JMP | BPF_JEQ | BPF_K, __NR_kexec_load, 0, 1),
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_KILL_PROCESS),

    /* 나머지 허용 */
    BPF_STMT(BPF_RET | BPF_K, SECCOMP_RET_ALLOW),
};

struct sock_fprog prog = {
    .len    = (unsigned short)(sizeof(filter) / sizeof(filter[0])),
    .filter = filter,
};

libseccomp 고수준 API

raw cBPF 대신 libseccomp 라이브러리를 사용하면 가독성 높은 필터를 작성할 수 있습니다. 아키텍처 차이도 자동 처리됩니다.

#include <seccomp.h>   /* libseccomp 헤더 */

int setup_seccomp(void) {
    /* 기본 액션: 허용 (화이트리스트 방식은 SCMP_ACT_KILL 사용) */
    scmp_filter_ctx ctx = seccomp_init(SCMP_ACT_ALLOW);
    if (!ctx) return -1;

    /* 특정 시스템 콜 차단 (블랙리스트) */
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(mount), 0);
    seccomp_rule_add(ctx, SCMP_ACT_ERRNO(EPERM), SCMP_SYS(umount2), 0);
    seccomp_rule_add(ctx, SCMP_ACT_KILL_PROCESS, SCMP_SYS(kexec_load), 0);
    seccomp_rule_add(ctx, SCMP_ACT_KILL_PROCESS, SCMP_SYS(init_module), 0);

    /* 인자 조건부 필터링: write()는 fd=1,2만 허용 */
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
                     SCMP_A0(SCMP_CMP_EQ, STDOUT_FILENO));
    seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1,
                     SCMP_A0(SCMP_CMP_EQ, STDERR_FILENO));

    /* 필터 적용 */
    seccomp_load(ctx);
    seccomp_release(ctx);
    return 0;
}

디버깅 및 모니터링

# /proc/[pid]/status에서 seccomp 상태 확인
grep Seccomp /proc/self/status
# Seccomp:        0    (disabled)
# Seccomp:        1    (strict)
# Seccomp:        2    (filter)
# Seccomp_filters: 3   (필터 체인 길이, 5.8+)

# 로깅 가능한 액션 확인/설정
cat /proc/sys/kernel/seccomp/actions_logged
# kill_process kill_thread trap errno user_notif trace log
# (ALLOW는 기본 미포함 — 로깅하면 성능 심각 저하)

echo "kill_process kill_thread trap errno log" > \
    /proc/sys/kernel/seccomp/actions_logged

# audit 로그에서 seccomp 이벤트 검색
ausearch -m SECCOMP --start today
# type=SECCOMP msg=audit(1706000000.000:789):
#   auid=1000 uid=1000 pid=12345 subj=... comm="myapp"
#   exe="/usr/bin/myapp" sig=0 arch=c000003e
#   syscall=165 compat=0 ip=0x7f... code=0x50001
#   ↑ syscall=165 = mount, code=0x50001 = ERRNO|EPERM

# strace의 seccomp 지원 (5.3+, strace 5.3+)
strace --seccomp-bpf -e trace=open,read,write ./myapp
# --seccomp-bpf: strace가 seccomp 필터를 자동 설치하여
# 추적 대상 시스템 콜만 ptrace 중단 → 오버헤드 대폭 감소

# seccomp 필터를 BPF 디스어셈블리로 확인 (drgn 디버거)
# drgn -p [pid] -c 'task = find_task(pid); ...'

8. Credentials & Capabilities

struct cred 상세

/* include/linux/cred.h */
struct cred {
    atomic_long_t  usage;
    kuid_t         uid;     /* real UID */
    kgid_t         gid;     /* real GID */
    kuid_t         suid;    /* saved set-UID */
    kgid_t         sgid;    /* saved set-GID */
    kuid_t         euid;    /* effective UID */
    kgid_t         egid;    /* effective GID */
    kuid_t         fsuid;   /* filesystem UID */
    kgid_t         fsgid;   /* filesystem GID */
    unsigned       securebits;
    kernel_cap_t   cap_inheritable; /* 상속 가능 */
    kernel_cap_t   cap_permitted;   /* 허용된 전체 */
    kernel_cap_t   cap_effective;   /* 현재 유효 */
    kernel_cap_t   cap_bset;        /* bounding set */
    kernel_cap_t   cap_ambient;     /* ambient (4.3+) */
    struct user_struct   *user;
    struct user_namespace *user_ns;
    struct ucounts        *ucounts;
    struct group_info    *group_info;
    void           *security;       /* LSM security blob */
};

Credential 생명주기

/* Credential은 COW(Copy-on-Write) 방식으로 관리 */

/* 1. 새 credential 준비 (현재 cred 복사) */
struct cred *new = prepare_creds();
if (!new)
    return -ENOMEM;

/* 2. 필드 수정 */
new->uid = make_kuid(new->user_ns, 1000);
new->cap_effective = cap_drop(new->cap_effective, CAP_SYS_ADMIN);

/* 3. 원자적 커밋 (이전 cred 해제) */
commit_creds(new);

/* 또는 변경 취소 */
abort_creds(new);

/* 현재 credential 읽기 (RCU 보호) */
const struct cred *cred = current_cred();
kuid_t uid = cred->uid;

Capability 시스템 심화

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

파일 Capability

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

# 파일 capability 확인
getcap /usr/bin/myserver
# /usr/bin/myserver cap_net_bind_service=ep

# 프로세스의 현재 capability 확인
cat /proc/self/status | grep Cap
# CapInh: 0000000000000000  (inheritable)
# CapPrm: 0000000000000000  (permitted)
# CapEff: 0000000000000000  (effective)
# CapBnd: 000001ffffffffff  (bounding set)
# CapAmb: 0000000000000000  (ambient)

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

Ambient Capabilities (4.3+)

/* Ambient capability는 execve() 시 보존되는 capability */
/* 파일 capability(xattr) 없이도 non-root 프로세스에 capability 전달 */

/* 조건: ambient cap은 permitted ∩ inheritable의 부분집합이어야 함 */
prctl(PR_CAP_AMBIENT, PR_CAP_AMBIENT_RAISE, CAP_NET_BIND_SERVICE, 0, 0);

/* no_new_privs와 함께 사용하여 권한 상승 방지 */
prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);

/* execve 후 capability 계산:
   new_permitted   = (file_permitted & cap_bset) | (file_inheritable & cap_inheritable) | cap_ambient
   new_effective   = file_effective ? new_permitted : cap_ambient
   new_inheritable = cap_inheritable
   new_ambient     = (no_new_privs || !file_caps) ? cap_ambient : 0
*/

9. 커널 하드닝

KASLR (Kernel Address Space Layout Randomization)

커널 코드, 모듈, 물리 메모리 매핑의 베이스 주소를 부팅 시 랜덤으로 배치하여, 메모리 레이아웃을 예측할 수 없게 합니다. 공격자가 커널 심볼의 정확한 주소를 알아야 하는 ROP/JOP 공격을 근본적으로 어렵게 만드는 1차 방어선입니다.

KASLR의 랜덤화 대상 영역

KASLR 부팅 시 랜덤화 과정

/* arch/x86/boot/compressed/kaslr.c */
/* 부트로더 → 압축 해제기(decompressor)에서 KASLR 처리 */

/* 1단계: 엔트로피 소스 수집 */
static unsigned long get_boot_seed(void)
{
    /* RDTSC (CPU 타임스탬프 카운터) */
    /* RDRAND/RDSEED (하드웨어 RNG, 지원 시) */
    /* i8254 타이머 카운터 */
    /* 부트로더가 전달한 시드 (EFI RNG Protocol 등) */
}

/* 2단계: 사용 가능한 물리 메모리 슬롯 탐색 */
/* e820 메모리 맵에서 커널 크기를 수용할 수 있는 영역 목록 생성 */
/* 이미 사용된 영역(initrd, 부트 파라미터 등)은 제외 */

/* 3단계: 랜덤 슬롯 선택 → 커널 재배치 */
static unsigned long find_random_virt_addr(
    unsigned long minimum,
    unsigned long image_size)
{
    /* slots = 사용 가능 슬롯 수 */
    /* random_addr = minimum + (kaslr_get_random_long() % slots) * alignment */
    /* x86_64: 2MB 정렬, arm64: 64KB 또는 2MB 정렬 */
}

FKASLR (Function-Granular KASLR)

기본 KASLR은 커널 전체를 하나의 블록으로 이동하므로, 하나의 주소만 유출되면 나머지 모든 심볼의 오프셋을 계산할 수 있습니다. FKASLR은 함수 단위로 재배치하여 이 한계를 극복합니다.

/* FKASLR: CONFIG_FG_KASLR (x86_64, 실험적) */
/* 컴파일 시 -ffunction-sections 플래그로 함수별 별도 섹션 생성 */
/* 부팅 시 각 함수 섹션을 독립적으로 랜덤 재배치 */

/* 장점: 단일 주소 유출로 다른 함수 위치 추론 불가 */
/* 단점: 부팅 시간 증가, 캐시 지역성 저하, 코드 크기 증가 */
/*        /proc/kallsyms 심볼 순서가 매 부팅마다 달라짐 */

KASLR 우회 공격과 대응

KASLR 상태 확인 및 관련 sysctl

# KASLR 상태 확인
cat /proc/cmdline | grep -o 'nokaslr\|kaslr'
dmesg | grep "KASLR"
# KASLR enabled (커널 기본 활성화)

# 커널 포인터 보호 수준
cat /proc/sys/kernel/kptr_restrict
# 0: 모든 사용자에게 심볼 주소 노출 (위험)
# 1: 비루트 사용자에게 0x0000000000000000으로 마스킹
# 2: 루트 포함 모든 사용자에게 마스킹 (권장)

# dmesg 접근 제한
sysctl kernel.dmesg_restrict=1

# 커널 텍스트 오프셋 확인 (디버깅 용도, 루트 필요)
# /proc/kallsyms에서 _text 심볼 주소 확인
grep " _text$" /proc/kallsyms
# 매 부팅마다 다른 주소가 출력됨

# 스택 오프셋 랜덤화 확인
cat /proc/sys/kernel/randomize_kstack_offset
# 1 = 활성화 (syscall 진입 시 스택 오프셋 랜덤)

KPTI (Kernel Page Table Isolation)

Meltdown (CVE-2017-5754) 취약점 완화 기술입니다. 사용자 공간에서 커널 페이지 테이블을 분리하여, 사용자 모드에서 커널 메모리를 투기적 실행으로 읽을 수 없게 합니다.

/* arch/x86/mm/pti.c */
/* 사용자 공간용과 커널 공간용 두 벌의 페이지 테이블 유지 */
/* - 사용자 PGD: 최소한의 커널 매핑 (entry/exit 코드만) */
/* - 커널 PGD: 전체 커널 메모리 매핑 */
/* syscall/인터럽트 진입 시 PGD 전환 → CR3 레지스터 교체 */

/* KPTI 성능 영향: 시스템 콜 집중 워크로드에서 1~5% 오버헤드 */
/* PCID (Process Context Identifier) 사용 시 TLB 플러시 감소 */

# KPTI 상태 확인
dmesg | grep "page tables isolation"
# Kernel/User page tables isolation: enabled

cat /sys/devices/system/cpu/vulnerabilities/meltdown
# Mitigation: PTI

SMEP/SMAP

/* SMAP 일시 비활성화 (사용자 데이터 복사 시) */
stac();  /* Set AC flag → SMAP 일시 해제 */
copy_from_user(kbuf, ubuf, len);
clac();  /* Clear AC flag → SMAP 재활성화 */

/* copy_from_user/copy_to_user 내부에서 자동 처리 */

Stack Protector

# 스택 버퍼 오버플로 감지
# CONFIG_STACKPROTECTOR=y       (기본 보호 - 취약한 함수만)
# CONFIG_STACKPROTECTOR_STRONG=y (강한 보호 - 배열/주소 사용 함수)

# 함수 프롤로그에 canary 값 삽입
# 함수 에필로그에서 canary 검증 → 변조 시 panic
# canary는 per-CPU 변수로 스레드마다 다름

CFI (Control Flow Integrity)

간접 호출(함수 포인터)의 목적지를 검증하여 ROP/JOP 공격을 차단합니다. 리눅스 커널은 수천 개의 함수 포인터(file_operations, vm_operations_struct 등)를 사용하므로, 함수 포인터 오염을 통한 제어 흐름 탈취는 커널 익스플로잇의 핵심 기법입니다. CFI는 이러한 공격을 런타임에 탐지하여 차단합니다.

CFI 기술 비교

kCFI (Kernel Control Flow Integrity) 동작 원리

kCFI는 Clang 컴파일러가 모든 간접 호출 대상 함수에 타입 해시를 프리픽스로 삽입하고, 호출 직전에 해시를 검증하는 소프트웨어 기반 CFI입니다.

/* kCFI 컴파일러 계측 예시 (개념적) */

/* 원본 코드 */
struct file_operations fops = {
    .read = my_read,
    .write = my_write,
};
filp->f_op->read(filp, buf, count, pos);

/* kCFI 계측 후 (어셈블리 수준에서 발생하는 동작) */
/*
 * 1. 컴파일러가 각 함수 앞에 4바이트 타입 해시 삽입:
 *    my_read:
 *      .long 0xDEAD1234   ← 함수 시그니처 해시 (ssize_t(*)(struct file*, char*, size_t, loff_t*))
 *      push  %rbp          ← 실제 함수 시작
 *      ...
 *
 * 2. 간접 호출 직전에 해시 검증 코드 삽입:
 *      mov   f_op(%rdi), %rax     ← 함수 포인터 로드
 *      movl  -4(%rax), %ecx       ← 대상 함수 앞의 해시 로드
 *      cmpl  $0xDEAD1234, %ecx    ← 기대 해시와 비교
 *      jne   __cfi_failure         ← 불일치 시 → BUG()/panic
 *      call  *%rax                 ← 일치 시 정상 호출
 */

FineIBT (Forward-Edge CFI with Intel IBT)

FineIBT는 Intel CET(Control-flow Enforcement Technology)의 IBT(Indirect Branch Tracking)와 kCFI를 결합한 하드웨어 가속 CFI입니다. IBT만 단독 사용 시 모든 ENDBR64 명령어가 유효한 분기 대상이 되어 보호가 약하지만, kCFI의 타입 해시 검증을 결합하면 강력한 forward-edge 보호가 가능합니다.

/* FineIBT 동작 메커니즘 (x86_64 어셈블리 수준) */
/*
 * [함수 프롤로그] (IBT + kCFI 결합)
 *   my_read:
 *     endbr64                    ← IBT: 유효한 간접 분기 대상 표시
 *     subl  $0xDEAD1234, %r10d   ← kCFI: 전달된 해시에서 기대값을 뺌
 *     jz    .Lok                  ← 0이면(일치) 정상 진행
 *     ud2                         ← 불일치 시 #UD 예외 → BUG()
 *   .Lok:
 *     push  %rbp
 *     ...
 *
 * [간접 호출 사이트]
 *     movl  $0xDEAD1234, %r10d   ← 기대 해시를 r10에 로드
 *     call  *%rax                 ← 간접 호출 (IBT가 endbr64 존재 확인)
 */

/* FineIBT 활성화 조건 */
# CONFIG_X86_KERNEL_IBT=y          ← IBT 활성화
# CONFIG_CFI_CLANG=y               ← kCFI 활성화
# CPU가 CET-IBT 지원 (Intel 12세대+, AMD Zen 4+)
# 커널이 Clang으로 빌드됨

Shadow Call Stack (arm64)

Shadow Call Stack(SCS)은 리턴 주소를 일반 스택과 분리된 별도의 그림자 스택에 저장하여, 스택 버퍼 오버플로로 인한 리턴 주소 변조를 방지하는 backward-edge CFI 기법입니다.

/* Shadow Call Stack 동작 (arm64) */
/*
 * arm64에서 x18 레지스터를 Shadow Call Stack 포인터로 예약
 * (x18은 플랫폼 레지스터, 일반 코드에서 사용 금지)
 *
 * [함수 프롤로그]
 *   str  x30, [x18], #8     ← 리턴 주소(LR)를 SCS에 push
 *   stp  x29, x30, [sp, #-16]!  ← 일반 스택에도 저장 (프레임 포인터)
 *
 * [함수 에필로그]
 *   ldr  x30, [x18, #-8]!   ← SCS에서 리턴 주소 복원
 *   ldp  x29, x30, [sp], #16
 *   ret                      ← SCS의 주소로 리턴
 *
 * 공격자가 일반 스택의 리턴 주소를 변조해도,
 * 실제 리턴은 SCS의 원본 주소를 사용하므로 ROP 공격 실패
 */

/* SCS 메모리 할당 (per-task) */
/* arch/arm64/kernel/scs.c */
#define SCS_SIZE       (1 << 10)  /* 1KB (128개 리턴 주소) */
#define SCS_GFP        (GFP_KERNEL | __GFP_ZERO)

/* 태스크 생성 시 SCS 할당, 종료 시 해제 */
/* vmalloc 영역에 할당하여 guard page로 오버플로 감지 */

CFI 위반 처리와 디버깅

# CFI 위반 시 커널 로그 예시
# CFI failure at some_function+0x42/0x100 (target: 0xffffffff81234567)
# kernel BUG at arch/x86/kernel/cfi.c:NN!

# CFI 모드 확인
dmesg | grep -i "cfi\|fineibt\|IBT"
# x86/cfi: Switching to FineIBT CFI
# 또는: x86/cfi: Using kCFI

# 모듈에서 CFI 지원 확인
modinfo some_module | grep cfi
# CFI가 활성화된 커널에서 비-CFI 모듈 로드 시
# 간접 호출이 검증 실패할 수 있음

# CONFIG_CFI_PERMISSIVE=y 사용 시 위반을 경고만 출력 (디버깅용)
# 프로덕션에서는 반드시 permissive 비활성화

FORTIFY_SOURCE

/* CONFIG_FORTIFY_SOURCE=y */
/* 컴파일 타임 + 런타임에 버퍼 오버플로 감지 */
/* memcpy, strcpy, sprintf 등의 안전한 래퍼 제공 */

/* 예: memcpy 크기가 대상 버퍼를 초과하면 */
/*     컴파일 타임: 경고/에러 */
/*     런타임: fortify_panic() 호출 → BUG() */

하드닝 CONFIG 옵션 요약

10. Audit 서브시스템

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

아키텍처

Audit 서브시스템은 커널 공간의 감사 후크(hook)와 사용자 공간의 auditd 데몬으로 구성됩니다. 커널이 이벤트를 수집하고, NETLINK_AUDIT 소켓을 통해 사용자 공간으로 전달합니다.

audit_context 생명주기

모든 감사 가능한 태스크는 task_struct->audit_context를 통해 audit_context 구조체를 갖습니다. 이 구조체는 시스템 콜 진입/종료 시 이벤트 데이터를 수집하고, 규칙 매칭 결과에 따라 로그 생성 여부를 결정합니다.

/* kernel/audit.h — audit_context 핵심 필드 */
struct audit_context {
    int                    in_syscall;     /* 시스템 콜 실행 중 여부 */
    enum audit_state       state;          /* AUDIT_STATE_{DISABLED,BUILD,RECORD} */
    enum audit_state       current_state;  /* 현재 감사 상태 */
    unsigned int           serial;         /* 이벤트 시리얼 번호 */
    int                    major;          /* 시스템 콜 번호 (NR) */
    int                    uring_op;       /* io_uring 연산 코드 */
    unsigned long          argv[4];        /* 시스템 콜 인자 (a0~a3) */
    long                   return_code;    /* 시스템 콜 반환값 */
    u64                    prio;           /* 우선순위 (에러 시 증가) */
    int                    return_valid;   /* 반환값 유효 여부 */

    /* 이름/경로 정보 */
    struct audit_names     *names;         /* 파일 이름 연결 리스트 */
    int                    name_count;     /* 이름 항목 수 */
    struct path            pwd;            /* 현재 작업 디렉토리 */

    /* IPC/소켓 감사 정보 */
    struct audit_aux_data  *aux;           /* 보조 감사 데이터 체인 */
    struct audit_aux_data  *aux_pids;      /* PID 추적 보조 데이터 */
    struct sockaddr_storage *sockaddr;     /* 소켓 주소 */
    size_t                 sockaddr_len;

    /* 필터링 */
    pid_t                  target_pid;     /* 대상 프로세스 PID */
    kuid_t                 target_auid;    /* 대상 audit UID */
    kuid_t                 target_uid;     /* 대상 실제 UID */

    /* execve 인자 (EXECVE 레코드용) */
    struct audit_tree_refs *trees;         /* 감시 트리 참조 */
    struct audit_proctitle  proctitle;      /* PROCTITLE 레코드 데이터 */
    /* ... */
};

/* kernel/auditsc.c — 시스템 콜 감사 흐름 */

/* 1. 시스템 콜 진입 시 — entry 후크 */
void __audit_syscall_entry(int major, unsigned long a1,
                           unsigned long a2, unsigned long a3,
                           unsigned long a4)
{
    struct audit_context *context = audit_context();
    if (!context)
        return;

    context->serial = 0;          /* 새 이벤트마다 리셋 */
    context->in_syscall = 1;       /* 시스템 콜 내부 마크 */
    context->current_state = state;
    context->major = major;        /* syscall NR 저장 */
    context->argv[0] = a1;         /* 인자 저장 */
    context->argv[1] = a2;
    context->argv[2] = a3;
    context->argv[3] = a4;
}

/* 2. 시스템 콜 종료 시 — exit 후크 */
void __audit_syscall_exit(int success, long return_code)
{
    struct audit_context *context = audit_context();

    context->return_valid = AUDITSC_SUCCESS;
    context->return_code  = return_code;

    /* exit 필터 리스트에서 규칙 매칭 */
    if (context->current_state == AUDIT_STATE_BUILD)
        state = audit_filter_syscall(context);

    /* RECORD 상태면 감사 레코드 생성 및 전송 */
    if (context->current_state >= AUDIT_STATE_RECORD)
        audit_log_exit();        /* → audit_log_start() + audit_log_format() */

    context->in_syscall = 0;       /* 시스템 콜 완료 */
    audit_free_names(context);     /* 이름 목록 해제 */
    audit_free_aux(context);       /* 보조 데이터 해제 */
}

커널 감사 후크

Audit 서브시스템은 커널 전반에 후크를 삽입하여 보안 관련 이벤트를 포착합니다. 주요 후크 지점:

/* fs/namei.c — VFS 경로 해석 중 감사 후크 호출 예 */
static struct dentry *__lookup_hash(
    const struct qstr *name,
    struct dentry *base, unsigned int flags)
{
    struct dentry *dentry = lookup_dcache(name, base, flags);
    if (dentry)
        return dentry;

    dentry = __lookup_slow(name, base, flags);

    /* 감사 후크: 경로 해석 결과를 audit_context에 기록 */
    if (!IS_ERR(dentry) && unlikely(audit_context()))
        __audit_inode(name, dentry, flags);

    return dentry;
}

감사 메시지 형식

감사 레코드는 type=TYPE msg=audit(EPOCH:SERIAL): FIELDS 형식을 따릅니다. 동일 이벤트의 여러 레코드는 같은 EPOCH:SERIAL 쌍으로 연결됩니다.

# 하나의 이벤트는 여러 레코드 타입으로 구성됨 (같은 serial 공유)

# SYSCALL — 시스템 콜 기본 정보
type=SYSCALL msg=audit(1706000000.123:789): arch=c000003e syscall=257
  success=yes exit=3 a0=ffffff9c a1=7ffd1234 a2=0 a3=0
  items=1 ppid=4521 pid=4523 auid=1000 uid=0 gid=0 euid=0
  suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0
  ses=3 comm="cat" exe="/usr/bin/cat"
  subj=unconfined_u:unconfined_r:unconfined_t:s0
  key="sensitive_files"

# CWD — 현재 작업 디렉토리
type=CWD msg=audit(1706000000.123:789): cwd="/home/user"

# PATH — 접근한 파일 경로 (item 번호로 순서 지정)
type=PATH msg=audit(1706000000.123:789): item=0
  name="/etc/shadow" inode=131074 dev=08:01 mode=0100640
  ouid=0 ogid=42 rdev=00:00 nametype=NORMAL
  cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0

# PROCTITLE — 프로세스 제목 (hex 인코딩)
type=PROCTITLE msg=audit(1706000000.123:789):
  proctitle=636174002F6574632F736861646F77

주요 레코드 타입

kauditd 커널 스레드

kauditd는 커널 감사 메시지를 사용자 공간 auditd로 전달하는 커널 스레드입니다. 3개의 skb 큐를 관리하며, auditd 연결 상태에 따라 메시지 처리 전략을 결정합니다.

/* kernel/audit.c — kauditd 큐 관리 */
static struct sk_buff_head audit_queue;       /* 기본 전송 큐 */
static struct sk_buff_head audit_retry_queue; /* 전송 실패 재시도 큐 */
static struct sk_buff_head audit_hold_queue;  /* auditd 부재 시 보관 큐 */

static int kauditd_thread(void *dummy)
{
    while (!kthread_should_stop()) {
        /* 1. retry 큐: 이전 전송 실패 메시지 재전송 시도 */
        kauditd_send_queue(sk, &audit_retry_queue,
                           UNICAST_RETRIES, kauditd_rehold_skb);

        /* 2. hold 큐: auditd 복귀 시 보관 메시지 전송 */
        kauditd_send_queue(sk, &audit_hold_queue,
                           UNICAST_RETRIES, kauditd_hold_skb);

        /* 3. main 큐: 새 감사 메시지 전송 */
        kauditd_send_queue(sk, &audit_queue,
                           1, kauditd_rehold_skb);

        /* 메시지 없으면 대기 (wake_up으로 깨움) */
        wait_event_freezable(kauditd_wait,
                             skb_queue_len(&audit_queue));
    }
    return 0;
}

필터 엔진

감사 규칙은 5개의 필터 리스트에 배치되며, 이벤트 발생 시 해당 리스트의 규칙을 순차 매칭합니다. 첫 매칭 규칙의 action(always/never)이 적용됩니다.

/* kernel/auditfilter.c — 필터 규칙 구조체 */
struct audit_krule {
    u32                    pflags;      /* 규칙 플래그 */
    u32                    flags;       /* AUDIT_FILTER_{TASK,EXIT,...} */
    u32                    listnr;      /* 필터 리스트 번호 */
    u32                    action;      /* AUDIT_ALWAYS 또는 AUDIT_NEVER */
    u32                    mask[AUDIT_BITMASK_SIZE]; /* syscall 비트마스크 */
    u32                    buflen;
    u32                    field_count; /* 조건 필드 수 */
    struct audit_field     *fields;     /* 필드 조건 배열 */
    struct audit_watch     *watch;      /* 파일 감시 (-w 규칙) */
    struct audit_tree      *tree;       /* 디렉토리 트리 감시 */
    struct audit_fsnotify_mark *exe;   /* 실행 파일 감시 */
    char                   *filterkey;  /* -k 키 문자열 */
    struct list_head       list;        /* 리스트 연결 */
    struct list_head       rlist;       /* 규칙 인덱스 */
};

struct audit_field {
    u32   type;    /* AUDIT_PID, AUDIT_UID, AUDIT_ARCH, ... */
    u32   val;     /* 비교 값 */
    u32   op;      /* AUDIT_EQUAL, AUDIT_NOT_EQUAL, ... */
    union {
        kuid_t uid;
        kgid_t gid;
        struct {
            char   *lsm_str;
            void   *lsm_rule;  /* LSM 규칙 (SELinux 컨텍스트 등) */
        };
    };
};

감사 규칙 유형

제어 규칙 (Control Rules)

감사 서브시스템 자체의 동작을 제어합니다.

# 감사 활성화/비활성화
auditctl -e 0     # 비활성화
auditctl -e 1     # 활성화
auditctl -e 2     # 잠금 (재부팅 전까지 규칙 변경 불가)

# 백로그 제한 (기본 64, 프로덕션에서 증가 필요)
auditctl -b 8192  # 백로그 버퍼 크기

# 실패 모드 (백로그 초과 시 동작)
auditctl -f 0     # silent — 초과분 버림
auditctl -f 1     # printk — 경고 메시지 출력 (기본값)
auditctl -f 2     # panic — 커널 패닉 (고보안 환경)

# 초당 최대 메시지 수 제한
auditctl -r 100   # 초당 100개 (0 = 무제한)

# 모든 규칙 삭제
auditctl -D

# 현재 상태 확인
auditctl -s
# enabled 1
# failure 1
# pid 1234     (auditd PID)
# backlog_limit 8192
# lost 0       (유실된 메시지 수)
# backlog 0    (현재 큐 대기 수)

파일시스템 감시 규칙 (Watch Rules)

# -w (감시 대상) -p (권한 필터) -k (검색 키)
# 권한: r=읽기, w=쓰기, x=실행, a=속성변경

# 인증 관련 파일 감시
auditctl -w /etc/passwd -p wa -k auth_files
auditctl -w /etc/shadow -p wa -k auth_files
auditctl -w /etc/group -p wa -k auth_files
auditctl -w /etc/gshadow -p wa -k auth_files
auditctl -w /etc/sudoers -p wa -k auth_files
auditctl -w /etc/sudoers.d/ -p wa -k auth_files

# PAM 설정 감시
auditctl -w /etc/pam.d/ -p wa -k pam_config

# SSH 설정 감시
auditctl -w /etc/ssh/sshd_config -p wa -k sshd_config
auditctl -w /root/.ssh/ -p wa -k root_ssh

# 시간 변경 감시 (규정 준수 필수)
auditctl -w /etc/localtime -p wa -k time_change

# 커널 모듈 관련
auditctl -w /sbin/insmod -p x -k module_load
auditctl -w /sbin/modprobe -p x -k module_load
auditctl -w /etc/modprobe.d/ -p wa -k module_config

# cron 설정 감시
auditctl -w /etc/cron.d/ -p wa -k cron_config
auditctl -w /etc/crontab -p wa -k cron_config
auditctl -w /var/spool/cron/ -p wa -k cron_config

시스템 콜 규칙 (Syscall Rules)

# 형식: -a action,filter -F field=value -S syscall -k key
# action: always (기록) / never (무시)
# filter: task, exit, user, exclude

# 프로세스 실행 추적 (모든 execve)
auditctl -a always,exit -F arch=b64 -S execve -k exec_log

# 접근 거부 감사 (EACCES, EPERM)
auditctl -a always,exit -F arch=b64 -S open -S openat -S openat2 \
  -F exit=-EACCES -k access_denied
auditctl -a always,exit -F arch=b64 -S open -S openat -S openat2 \
  -F exit=-EPERM -k access_denied

# 파일 삭제 추적
auditctl -a always,exit -F arch=b64 -S unlink -S unlinkat -S rename \
  -S renameat -k file_delete

# 시간 변경 시스템 콜 감사
auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday \
  -S clock_settime -k time_change

# 네트워크 연결 감사 (connect만)
auditctl -a always,exit -F arch=b64 -S connect -F a2!=110 -k network_connect

# 특정 UID 범위 감사 (서비스 계정 제외)
auditctl -a always,exit -F arch=b64 -S execve -F auid>=1000 \
  -F auid!=4294967295 -k user_exec

# 커널 모듈 로드/언로드
auditctl -a always,exit -F arch=b64 -S init_module -S finit_module \
  -S delete_module -k kernel_modules

# mount/umount 감사
auditctl -a always,exit -F arch=b64 -S mount -S umount2 -k mount_ops

# ptrace 감사 (디버거 연결 탐지)
auditctl -a always,exit -F arch=b64 -S ptrace -k ptrace_attach

# 네트워크 설정 변경 (sethostname, setdomainname)
auditctl -a always,exit -F arch=b64 -S sethostname -S setdomainname -k hostname

# 32비트 시스템 콜도 함께 감사 (호환성 계층)
auditctl -a always,exit -F arch=b32 -S execve -k exec_log_32bit

제외 규칙 (Exclude Rules)

# 노이즈가 많은 메시지 타입 제외
auditctl -a always,exclude -F msgtype=CWD          # CWD 레코드 제외
auditctl -a always,exclude -F msgtype=EOE          # 이벤트 종료 마커 제외
auditctl -a always,exclude -F msgtype=CRYPTO_KEY_USER # SSH 키 이벤트 제외

# 특정 프로그램의 감사 제외 (성능 최적화)
auditctl -a never,exit -F arch=b64 -S all -F exe=/usr/sbin/chronyd
auditctl -a never,exit -F arch=b64 -S all -F exe=/usr/bin/vmtoolsd

감사 도구

auditctl — 규칙 관리

# 현재 규칙 목록
auditctl -l

# 현재 상태
auditctl -s

# 규칙 삭제 (개별)
auditctl -d always,exit -F arch=b64 -S execve -k exec_log

# 모든 규칙 삭제
auditctl -D

# 규칙 파일에서 로드
auditctl -R /etc/audit/rules.d/custom.rules

ausearch — 로그 검색

# 키로 검색
ausearch -k passwd_changes --start today

# 메시지 타입으로 검색
ausearch -m SYSCALL -sc execve --start recent
ausearch -m USER_AUTH -sv no   # 인증 실패만

# auid (원래 로그인 사용자)로 검색
ausearch -ua 1000 --start today

# 특정 PID로 검색
ausearch -p 4523

# 시간 범위 검색
ausearch --start 01/15/2024 12:00:00 --end 01/15/2024 18:00:00

# 실행 파일로 검색
ausearch -x /usr/bin/passwd

# 파일 이름으로 검색
ausearch -f /etc/shadow

# 해석된 형식 출력 (-i: UID→이름, syscall→이름 변환)
ausearch -k exec_log -i --start today

# 이벤트 단위 구분자와 함께 출력
ausearch -k exec_log --format text

# CSV 형식 출력 (외부 도구 연동)
ausearch -k exec_log --format csv

# 특정 이벤트 ID로 검색
ausearch -a 789  # serial 789인 모든 레코드

# 여러 조건 AND 결합
ausearch -m SYSCALL -sc openat -k sensitive_files -sv no --start today

aureport — 보고서 생성

# 종합 요약 보고서
aureport --summary

# 인증 이벤트 보고서
aureport --auth --start this-week

# 파일 접근 보고서
aureport --file --summary

# 시스템 콜 통계
aureport --syscall --summary

# 이상 이벤트
aureport --anomaly

# 실패한 이벤트만
aureport --failed

# 실행 보고서
aureport -x --summary

# 키별 이벤트 수
aureport -k --summary

# 로그인 보고서
aureport --login --summary

# 사용자별 이벤트 수
aureport --user --summary

# 터미널별 이벤트
aureport --tty

autrace — 프로세스 추적

# autrace: strace와 유사하지만 audit 프레임워크 사용
# 모든 감사 규칙을 일시 삭제 후 대상 프로세스만 추적

autrace /bin/ls /tmp

# 추적 결과 분석
ausearch --start recent -p 12345 --raw | aureport --file --summary
ausearch --start recent -p 12345 --raw | aureport --syscall

auditd 데몬 설정

# /etc/audit/auditd.conf — 핵심 설정 항목

# 로그 파일 위치
log_file = /var/log/audit/audit.log

# 로그 형식 (RAW: 원시 형식, ENRICHED: UID→이름 등 해석 포함)
log_format = ENRICHED

# 로그 그룹 (adm 그룹에 읽기 권한 부여)
log_group = adm

# 로그 파일당 최대 크기 (MB)
max_log_file = 50

# 최대 로그 파일 수 (순환)
num_logs = 10

# 최대 크기 도달 시 동작
max_log_file_action = ROTATE     # ROTATE, SYSLOG, SUSPEND, IGNORE, KEEP_LOGS

# 디스크 공간 부족 시 동작
space_left = 75                  # 잔여 공간 경고 임계값 (MB)
space_left_action = SYSLOG       # SYSLOG, EMAIL, EXEC, SUSPEND, SINGLE, HALT
admin_space_left = 50            # 관리자 경고 임계값 (MB)
admin_space_left_action = SUSPEND
disk_full_action = SUSPEND       # 디스크 꽉 찬 경우
disk_error_action = SUSPEND      # 디스크 오류 시

# 네트워크 전달 (원격 감사 서버)
# name_format = HOSTNAME
# name = myserver.example.com

# 디스패처 (audisp 플러그인)
dispatcher = /sbin/audispd

# 플러시 방식
flush = INCREMENTAL_ASYNC        # 성능과 안정성 균형
freq = 50                        # 50개 레코드마다 플러시

# TCP 리스너 (원격 수집 서버로 사용 시)
# tcp_listen_port = 60
# tcp_max_per_addr = 1

영구 규칙 설정

auditctl로 설정한 규칙은 재부팅 시 사라집니다. 영구 규칙은 /etc/audit/rules.d/ 디렉토리에 .rules 파일로 저장합니다.

# /etc/audit/rules.d/audit.rules — 영구 규칙 파일 구조

# === 1단계: 기존 규칙 초기화 ===
-D
-b 8192
-f 1
--backlog_wait_time 60000

# === 2단계: 파일 감시 규칙 ===
-w /etc/passwd -p wa -k auth_files
-w /etc/shadow -p wa -k auth_files
-w /etc/group -p wa -k auth_files
-w /etc/sudoers -p wa -k auth_files
-w /etc/sudoers.d/ -p wa -k auth_files
-w /etc/ssh/sshd_config -p wa -k sshd_config

# === 3단계: 시스템 콜 규칙 ===
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec
-a always,exit -F arch=b32 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec
-a always,exit -F arch=b64 -S init_module -S finit_module -S delete_module -k kernel_modules
-a always,exit -F arch=b64 -S mount -S umount2 -k mount_ops
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -S clock_settime -k time_change

# === 4단계: 고성능 제외 규칙 ===
-a never,exit -F arch=b64 -S all -F exe=/usr/sbin/chronyd
-a always,exclude -F msgtype=CWD

# === 마지막: 규칙 잠금 (프로덕션 필수) ===
-e 2

# 규칙 적용: augenrules --load 또는 service auditd restart

시스템 콜 감사 예제

# 특정 사용자(UID 1000)의 모든 파일 삭제 감사
auditctl -a always,exit -F arch=b64 -S unlinkat -F uid=1000 -k user_deletes

# 감사 로그 확인
ausearch -k user_deletes
# ----
# type=SYSCALL msg=audit(1706000000.123:456): arch=c000003e
#   syscall=263 success=yes exit=0 a0=ffffff9c a1=55a8b... 
#   uid=1000 gid=1000 comm="rm" exe="/usr/bin/rm"
# type=PATH msg=audit(1706000000.123:456): item=1
#   name="secret.txt" inode=12345 nametype=DELETE

로그 분석 기법

# 1. 의심스러운 실행 파일 탐지
ausearch -m EXECVE --start today -i | \
  aureport -x --summary | sort -rn -k1 | head -20

# 2. 실패한 파일 접근 상위 사용자
ausearch -sv no -m SYSCALL --start this-week | \
  aureport --user --summary | sort -rn -k1

# 3. 시간대별 이벤트 분포 (DDoS/brute-force 탐지)
aureport --start today --summary

# 4. 특정 파일에 접근한 모든 프로세스 추적
ausearch -f /etc/shadow -i --start this-month

# 5. 권한 상승 이벤트 추적 (setuid/setgid 호출)
ausearch -m SYSCALL -sc setuid --start today -i
ausearch -m SYSCALL -sc setgid --start today -i

# 6. 특정 사용자의 전체 세션 활동 재구성
ausearch --session 42 -i | aureport --file
ausearch --session 42 -i | aureport --syscall
ausearch --session 42 -i | aureport --host

# 7. PROCTITLE 디코딩 (hex → 텍스트)
ausearch -k exec_log --start today --raw | \
  awk '/proctitle=/{gsub(/proctitle=/,""); cmd=$NF; gsub(/../," 0x&",cmd); print cmd}' | \
  xargs printf '%b\n'

audisp 플러그인

audisp(Audit Dispatcher)은 감사 이벤트를 외부 시스템으로 전달하는 플러그인 프레임워크입니다. /etc/audit/plugins.d/에 플러그인 설정 파일을 배치합니다.

# /etc/audit/plugins.d/syslog.conf — syslog 전달 플러그인
active = yes
direction = out
path = /sbin/audisp-syslog
type = always
args = LOG_INFO
format = string

# /etc/audit/plugins.d/af_unix.conf — 유닉스 소켓 전달
active = yes
direction = out
path = builtin_af_unix
type = always
args = 0640 /var/run/audispd_events
format = string

성능 최적화

/* kernel/auditsc.c — 규칙 매칭 오버헤드 최소화를 위한 최적화 */

/* syscall 비트마스크로 해당 syscall에 규칙이 있는지 O(1) 확인 */
static inline int audit_n_rules;  /* 전체 규칙 수 — 0이면 감사 완전 스킵 */

/* 감사 비활성화 시 빠른 경로 */
static inline void audit_syscall_entry(int major, ...)
{
    /* audit_n_rules == 0 이면 즉시 반환 (오버헤드 거의 0) */
    if (unlikely(audit_n_rules))
        __audit_syscall_entry(major, ...);
}

보안 컴플라이언스 규칙 세트

주요 보안 표준에서 요구하는 감사 규칙 예시:

LSM 연동

Audit 서브시스템은 SELinux, AppArmor 등 LSM과 긴밀하게 연동됩니다. LSM이 접근을 거부하면 자동으로 감사 레코드가 생성됩니다.

# SELinux AVC 거부 → 자동 감사 레코드 생성
type=AVC msg=audit(1706000000.456:321): avc:  denied  { read } for
  pid=3456 comm="httpd" name="index.html" dev="sda1" ino=67890
  scontext=system_u:system_r:httpd_t:s0
  tcontext=system_u:object_r:user_home_t:s0
  tclass=file permissive=0

# AppArmor DENIED → 자동 감사 레코드 생성
type=AVC msg=audit(1706000000.789:654):
  apparmor="DENIED" operation="open"
  profile="/usr/sbin/nginx" name="/etc/shadow"
  pid=5678 comm="nginx" requested_mask="r" denied_mask="r"
  fsuid=33 ouid=0

# SELinux 컨텍스트 기반 감사 규칙
# 특정 SELinux 타입이 접근하는 이벤트만 감사
auditctl -a always,exit -F arch=b64 -S openat \
  -F subj_type=httpd_t -k httpd_access

/* security/selinux/avc.c — SELinux AVC에서 감사 호출 */
static void avc_audit_post_callback(
    struct audit_buffer *ab,
    void *a)
{
    struct common_audit_data *ad = a;
    audit_log_format(ab, " ");
    audit_log_untrustedstring(ab, ad->selinux_audit_data->scontext);
    audit_log_format(ab, " tcontext=");
    audit_log_untrustedstring(ab, ad->selinux_audit_data->tcontext);
    audit_log_format(ab, " tclass=%s",
                     secclass_map[ad->selinux_audit_data->tclass - 1].name);
}

/* 감사 결정: AVC denied 또는 auditallow 규칙 매칭 시 로그 */
static inline int avc_audit_required(
    u32 requested, struct av_decision *avd,
    int result, u32 auditdeny, u32 *deniedp)
{
    u32 denied = requested & ~avd->allowed;

    /* 거부된 경우: auditdeny 마스크와 교차 확인 */
    if (denied && (denied & auditdeny))
        return 1;   /* 감사 필요 */

    /* 허용된 경우: auditallow 마스크 확인 */
    if (!denied && (requested & avd->auditallow))
        return 1;   /* auditallow로 허용 이벤트도 감사 */

    return 0;       /* 감사 불필요 */
}

11. IMA/EVM 및 Lockdown

IMA(Integrity Measurement Architecture)와 EVM(Extended Verification Module)은 파일 무결성을 보장합니다. Lockdown LSM은 커널의 자체 변경을 방지합니다.

# IMA 상태 확인
cat /sys/kernel/security/ima/runtime_measurements_count
cat /sys/kernel/security/ima/ascii_runtime_measurements | head

# Lockdown 상태
cat /sys/kernel/security/lockdown
# [none] integrity confidentiality

12. 보안 관련 커널 설정 종합

역사적 커널 보안 취약점 사례

리눅스 커널의 보안 취약점은 하드웨어 수준의 설계 결함부터 소프트웨어 논리 오류까지 다양한 형태로 발견되어 왔습니다. 주요 사례를 분석하고, 각 취약점이 커널 보안 아키텍처에 미친 영향과 완화 기법의 변천을 살펴봅니다.

Spectre 변종들과 완화 기법 변천사

2018년 1월 공개된 Spectre 취약점은 현대 프로세서의 투기적 실행(speculative execution) 메커니즘을 악용하여 커널 메모리를 읽어낼 수 있는 하드웨어 수준의 결함입니다. 커널은 소프트웨어 완화 기법을 통해 이 문제에 대응해 왔습니다.

/* 취약한 코드 패턴 — Spectre v1에 노출 */
if (index < array_size) {
    value = array[index];           /* 투기적 실행 시 bounds check 우회 */
    leak  = probe_array[value * 4096]; /* 캐시 사이드채널 */
}

/* 완화된 코드 패턴 — array_index_nospec() 적용 */
#include <linux/nospec.h>

if (index < array_size) {
    index = array_index_nospec(index, array_size); /* 투기적 실행 시 인덱스를 0으로 클램프 */
    value = array[index];
}

array_index_nospec()는 조건 분기와 무관하게 인덱스를 안전 범위로 제한하는 데이터 의존성 기반 마스킹을 수행합니다. 투기적 실행 중에도 인덱스가 유효 범위를 벗어나지 않도록 보장합니다.

/*
 * Retpoline: 간접 분기를 투기적 실행 불가능한 구조로 변환
 * GCC/Clang -mindirect-branch=thunk 옵션으로 자동 적용
 */

/* 일반 간접 호출 (취약) */
call *%rax                /* 분기 예측기가 대상을 조작 가능 */

/* Retpoline 변환 후 (완화) */
__x86_indirect_thunk_rax:
    call    retpoline_call_target
capture_ret:
    pause                    /* 투기적 실행이 여기서 무한 루프 */
    lfence
    jmp     capture_ret
retpoline_call_target:
    mov     %rax, (%rsp)     /* 실제 대상 주소를 리턴 스택에 배치 */
    ret                      /* ret로 간접 점프 → 분기 예측기 우회 */

/* 커널 내부 Spectre 완화 상태 확인 */
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: usercopy/swapgs barriers and __user pointer sanitization

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Enhanced / Automatic IBRS; IBPB: conditional; STIBP: conditional; RSB filling; BHI: BHI_DIS_S

권한 상승 취약점 패턴 분석

커널 권한 상승(privilege escalation) 취약점은 일반 사용자가 root 권한을 획득할 수 있게 하는 가장 위험한 유형의 버그입니다. 파일시스템, 프로세스 관리, 메모리 관리 서브시스템의 경계에서 권한 검사가 누락되는 패턴이 반복적으로 발견됩니다.

/* CVE-2021-4154 공격 흐름 (개념적 설명) */

/* 1. 컨테이너 내부에서 cgroup v1 마운트 */
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp

/* 2. 자식 cgroup 생성 및 notify_on_release 활성화 */
mkdir /tmp/cgrp/child
echo 1 > /tmp/cgrp/child/notify_on_release

/* 3. release_agent에 호스트 경로의 악성 스크립트 지정 */
echo /path/to/malicious_script > /tmp/cgrp/release_agent

/* 4. child cgroup에서 프로세스 시작 후 즉시 종료 */
/* → release_agent가 호스트 root로 실행됨 */
sh -c "echo \$\$ > /tmp/cgrp/child/cgroup.procs"

/* Dirty Pipe (CVE-2022-0847) 핵심 메커니즘 */

/* copy_page_to_iter_pipe()에서 플래그 초기화 누락 */
static size_t copy_page_to_iter_pipe(struct page *page, ...) {
    struct pipe_buffer *buf = &pipe->bufs[i_head & p_mask];
    buf->ops   = &page_cache_pipe_buf_ops;
    buf->page  = page;
    buf->offset = offset;
    buf->len   = bytes;
    /* BUG: buf->flags 초기화 누락!
     * 이전 사용에서 PIPE_BUF_FLAG_CAN_MERGE가 남아있으면
     * 후속 write()가 페이지 캐시를 직접 덮어씀 */
}

/* 수정: flags를 명시적으로 초기화 */
buf->flags = 0;  /* 또는 적절한 초기값 설정 */

Container Escape 취약점

컨테이너는 커널의 namespace, cgroup, seccomp 등으로 격리를 구현하지만, 커널 자체가 공유되므로 커널 취약점을 통한 탈출(escape)이 가능합니다. 컨테이너 보안의 근본적 한계와 주요 탈출 사례를 분석합니다.

/* abstract Unix socket은 네트워크 네임스페이스에 바인딩됨 */
/* --net=host 컨테이너는 호스트의 abstract socket에 접근 가능 */

/* containerd shim이 abstract socket으로 API 노출 (취약) */
struct sockaddr_un addr;
addr.sun_family = AF_UNIX;
addr.sun_path[0] = '\0';  /* abstract namespace — 파일시스템에 없음 */
strncpy(&addr.sun_path[1], "/containerd-shim/...", ...);

/* 수정: filesystem-based socket으로 전환 → mount namespace로 격리 */
addr.sun_path[0] = '/';   /* 일반 경로 — mount namespace에 의해 격리됨 */
strncpy(addr.sun_path, "/run/containerd/shim/...", ...);

/* CVE-2022-0185: legacy_parse_param()에서의 정수 언더플로우 */

static int legacy_parse_param(struct fs_context *fc,
                              struct fs_parameter *param) {
    ...
    size_t len = 0;

    /* 여러 파라미터를 연결하며 len 누적 */
    len += strlen(param->key);
    len += strlen(param->string);

    /* BUG: len이 PAGE_SIZE를 초과할 때 size 계산에서 언더플로우 발생 */
    size_t size = PAGE_SIZE - len;  /* 언더플로우 → 매우 큰 값 */

    /* 오버플로우된 size로 memcpy → 힙 오버플로우 */
    memcpy(buf + len, param->string, size);
    ...
}

커널 정보 누출 (Information Leak) 패턴

커널 정보 누출은 커널 메모리의 내용이 사용자 공간으로 복사되어 KASLR 우회, 힙 스프레이 등 후속 공격에 활용되는 취약점 유형입니다. 초기화되지 않은 메모리가 사용자에게 전달되는 패턴이 가장 흔합니다.

/* 취약한 패턴: copy_to_user() 전 구조체 초기화 누락 */
struct user_info {
    __u32 type;      /* 4 bytes */
    __u64 value;     /* 8 bytes */
    /* 컴파일러가 type과 value 사이에 4바이트 패딩 삽입
     * 이 패딩은 초기화되지 않으면 커널 스택 데이터를 포함 */
};

long vulnerable_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {
    struct user_info info;
    /* BUG: memset 누락! info의 패딩 바이트에 스택 잔류 데이터 존재 */
    info.type  = 1;
    info.value = get_some_value();
    /* 패딩 포함하여 16바이트 전체를 사용자 공간으로 복사 */
    if (copy_to_user((void __user *)arg, &info, sizeof(info)))
        return -EFAULT;
    return 0;
}

/* 수정된 패턴: memset()으로 전체 구조체 초기화 */
long safe_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {
    struct user_info info;
    memset(&info, 0, sizeof(info));  /* 패딩 포함 전체 초기화 */
    info.type  = 1;
    info.value = get_some_value();
    if (copy_to_user((void __user *)arg, &info, sizeof(info)))
        return -EFAULT;
    return 0;
}

/* CONFIG_INIT_STACK_ALL_ZERO 효과 */

/* 컴파일러가 함수 진입 시 모든 로컬 변수를 자동 초기화 */
long example_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {
    struct user_info info;
    /* -ftrivial-auto-var-init=zero에 의해
     * info 전체(패딩 포함)가 자동으로 0 초기화됨
     * 별도의 memset() 없이도 정보 누출 방지 */
    info.type  = 1;
    info.value = get_some_value();
    if (copy_to_user((void __user *)arg, &info, sizeof(info)))
        return -EFAULT;
    return 0;
}

/* 커널 빌드 설정 */
/* .config에서 다음 옵션 활성화 */
CONFIG_INIT_STACK_ALL_ZERO=y          /* 스택 전체 0 초기화 */
CONFIG_GCC_PLUGIN_STRUCTLEAK=y        /* STRUCTLEAK 플러그인 (GCC 전용) */
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y /* 모든 참조 전달 구조체 초기화 */
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y     /* 힙 할당 시 0 초기화 */

Dirty COW (CVE-2016-5195) — Copy-on-Write 경쟁 조건

2016년 10월 공개된 Dirty COW는 리눅스 커널 역사상 가장 널리 악용된 권한 상승 취약점 중 하나입니다. get_user_pages()의 Copy-on-Write 처리 과정에서 발생하는 경쟁 조건(race condition)을 악용하여, 읽기 전용 파일을 임의로 수정할 수 있습니다. 2007년(커널 2.6.22)부터 존재한 버그로, 약 9년간 커널에 잠복해 있었습니다.

/* Dirty COW (CVE-2016-5195) 경쟁 조건 분석 */

/*
 * 정상 CoW 흐름:
 * 1. write fault → do_wp_page() → 새 페이지 할당 및 복사
 * 2. PTE를 새 페이지로 업데이트 (RW)
 * 3. 원본 페이지는 변경되지 않음
 *
 * 경쟁 조건 흐름:
 * Thread A: write(/proc/self/mem) → get_user_pages(FOLL_WRITE)
 *   → faultin_page() → CoW 복사 시작
 * Thread B: madvise(MADV_DONTNEED) → 방금 만든 CoW 복사본을 무효화
 *   → PTE를 다시 원본 읽기 전용 페이지로 되돌림
 * Thread A: follow_page_mask() 재시도 → FOLL_WRITE 제거 후
 *   → 원본 읽기 전용 페이지에 쓰기 참조 반환!
 */

/* mm/gup.c — 취약한 코드 (수정 전) */
static long __get_user_pages(..., unsigned int gup_flags, ...) {
retry:
    ...
    page = follow_page_mask(vma, start, foll_flags, &page_mask);
    if (!page) {
        ret = faultin_page(tsk, vma, start, foll_flags, &nonblocking);
        /* CoW 복사가 일어났지만, 다른 스레드가
         * madvise(MADV_DONTNEED)로 복사본을 폐기할 수 있음 */
        if (!ret)
            goto retry;
        /* retry 시 FOLL_WRITE가 빠져 원본 페이지에 접근 */
    }
}

/* 수정: FOLL_COW 플래그 도입 (commit 19be0eaffa3a) */
/* CoW 복사가 완료된 경우에만 쓰기 접근을 허용하고,
 * retry 시 CoW 상태를 재검증 */

하드웨어 투기적 실행 취약점 변형들

Spectre/Meltdown 이후 프로세서의 투기적 실행 관련 취약점이 지속적으로 발견되었습니다. 커널은 각 변형에 대해 소프트웨어 완화를 구현하고, /sys/devices/system/cpu/vulnerabilities/를 통해 시스템의 취약 여부와 완화 상태를 노출합니다.

/* L1TF 완화 상태 확인 */
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable

/*
 * L1TF 커널 완화 기법:
 *
 * 1. PTE Inversion: non-present PTE에서 물리 주소 비트를 반전시켜
 *    투기적 실행 시 L1 캐시 히트를 방지
 *    (arch/x86/include/asm/pgtable.h — protnone_mask())
 *
 * 2. VMX L1D Flush: VM 진입 전 L1 데이터 캐시를 플러시
 *    kvm_intel.vmentry_l1d_flush=always|cond|never
 *
 * 3. SMT 비활성화: HyperThread 형제 코어를 통한 L1D 공유 차단
 *    nosmt 또는 echo off > /sys/devices/system/cpu/smt/control
 */

/* 커널 부트 파라미터 */
l1tf=full        /* PTE inversion + VMX flush + SMT 비활성화 */
l1tf=full,force  /* 강제 적용 (사용자 변경 불가) */
l1tf=flush       /* PTE inversion + VMX flush (SMT 유지) */
l1tf=flush,nosmt /* flush + SMT 비활성화 */
l1tf=off         /* 완화 비활성화 (위험) */

/* MDS 취약점 변형들 */

/*
 * MSBDS (CVE-2018-12126) — Microarchitectural Store Buffer Data Sampling
 *   Store Buffer에 남은 이전 데이터를 투기적으로 읽기 (Fallout)
 *
 * MFBDS (CVE-2018-12130) — Microarchitectural Fill Buffer Data Sampling
 *   Fill Buffer의 데이터를 투기적으로 읽기 (ZombieLoad)
 *
 * MLPDS (CVE-2018-12127) — Microarchitectural Load Port Data Sampling
 *   Load Port에 남은 데이터를 투기적으로 읽기 (RIDL)
 *
 * MDSUM (CVE-2019-11091) — Microarchitectural Data Sampling Uncacheable Memory
 *   Uncacheable 메모리 접근 시 마이크로아키텍처 버퍼 데이터 누출
 */

/* MDS 완화 확인 */
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable

/*
 * 커널 완화: VERW 명령어를 사용한 CPU 버퍼 클리어
 * - 컨텍스트 전환 시 VERW 실행 → 내부 버퍼 덮어쓰기
 * - 커널→사용자 모드 전환 시 실행
 * - VM exit 시 실행
 * - idle 진입 시 실행
 *
 * 커널 부트 파라미터:
 * mds=full       — VERW 완화 + SMT 경고
 * mds=full,nosmt — VERW 완화 + SMT 비활성화
 * mds=off        — 완화 비활성화
 */

/* GDS/Downfall 완화 */
$ cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Mitigation: Microcode

/*
 * GDS 완화:
 * 1. 마이크로코드 업데이트: GATHER 명령어의 투기적 데이터 전달 차단
 * 2. 커널 부트 파라미터:
 *    gather_data_sampling=force  — 강제 완화
 *    gather_data_sampling=off    — 완화 비활성화
 *
 * 영향받는 프로세서: Skylake, Ice Lake, Rocket Lake 등
 * (Alder Lake, Sapphire Rapids 이후는 하드웨어 수정됨)
 *
 * 성능 영향: GATHER 명령어 사용 워크로드에서 ~50% 저하 가능
 * (OpenSSL AES-GCM, 데이터베이스 벡터화 쿼리 등)
 */

/* 시스템의 전체 하드웨어 취약점 상태 일괄 확인 */
$ for f in /sys/devices/system/cpu/vulnerabilities/*; do
    echo "$(basename $f): $(cat $f)"
done
/* 출력 예시:
 * gather_data_sampling: Mitigation: Microcode
 * itlb_multihit: Not affected
 * l1tf: Mitigation: PTE Inversion; VMX: ...
 * mds: Mitigation: Clear CPU buffers; SMT vulnerable
 * meltdown: Mitigation: PTI
 * mmio_stale_data: Mitigation: Clear CPU buffers; SMT vulnerable
 * retbleed: Mitigation: Enhanced IBRS
 * spec_store_bypass: Mitigation: Speculative Store Bypass disabled ...
 * spectre_v1: Mitigation: usercopy/swapgs barriers ...
 * spectre_v2: Mitigation: Enhanced / Automatic IBRS; ...
 * srbds: Mitigation: Microcode
 * tsx_async_abort: Mitigation: TSX disabled
 */

Use-After-Free (UAF) 취약점 패턴

Use-After-Free는 리눅스 커널에서 가장 빈번하게 발견되는 메모리 안전성 취약점 유형입니다. 해제된 메모리 객체에 대한 참조가 남아있어, 해당 메모리가 재할당된 후 공격자가 제어하는 데이터로 덮어쓸 수 있습니다. 참조 카운트 관리 오류, 비동기 콜백의 생명주기 불일치, RCU 보호 누락 등이 근본 원인입니다.

/* CVE-2024-1086: nf_tables verdict 처리 결함 */

/* net/netfilter/nf_tables_api.c — 취약한 코드 */
static int nft_verdict_init(const struct nft_ctx *ctx, ...) {
    ...
    data->verdict.code = ntohl(nla_get_be32(tb[NFTA_VERDICT_CODE]));
    /* BUG: NF_DROP(0)에 양수 errno를 허용 → NF_DROP + 양수 = NF_ACCEPT(1)
     * nf_hook_slow()에서 이 verdict를 NF_ACCEPT로 해석 */
    switch (data->verdict.code) {
    case NF_ACCEPT:
    case NF_DROP:  /* NF_DROP에 양수 errno 허용됨 */
    case NF_QUEUE:
        break;
    ...
    }
}

/* 수정: NF_DROP의 errno를 음수 값만 허용하도록 검증 추가 */
case NF_DROP:
    if (data->verdict.code & NF_VERDICT_MASK)
        data->verdict.code &= ~NF_VERDICT_MASK;  /* errno 비트 제거 */
    break;

/* CVE-2014-3153: futex requeue 결함 */

/*
 * 정상 동작: futex_requeue()로 waiter를 다른 futex로 이동
 * 취약점:
 * 1. PI futex(FUTEX_LOCK_PI) waiter를 non-PI futex(FUTEX_WAIT)로 requeue
 * 2. rt_mutex의 top_waiter가 변경되지만, 이전 waiter의 참조가 남음
 * 3. 이전 waiter의 task_struct가 해제된 후에도 rt_mutex가 참조
 * → Use-After-Free → 임의 코드 실행
 *
 * 수정: requeue 시 PI와 non-PI futex 간 전환을 명시적으로 금지
 *       FUTEX_CMP_REQUEUE_PI만 PI futex 간 requeue 허용
 */

/* kernel/futex.c — 수정 */
static int futex_requeue(...) {
    /* 추가된 검증: requeue_pi가 아닌 경우 PI futex 거부 */
    if (!requeue_pi && match_futex(&key1, &key2)) {
        ret = -EINVAL;
        goto out_put_keys;
    }
    ...
}

Race Condition 취약점 패턴

커널의 동시성(concurrency) 처리에서 발생하는 경쟁 조건은 재현이 어렵고 탐지가 늦어지는 특성 때문에 장기간 잠복하는 경우가 많습니다. Dirty COW, 다수의 파일시스템/네트워크 스택 취약점이 이 패턴에 해당합니다.

/* Race Condition 취약점 탐지 도구 */

/* 1. KCSAN (Kernel Concurrency Sanitizer) — 동적 데이터 레이스 탐지 */
CONFIG_KCSAN=y
CONFIG_KCSAN_STRICT=y            /* 엄격 모드 */
CONFIG_KCSAN_REPORT_ONCE_IN_MS=0 /* 모든 레이스 보고 */

/* KCSAN이 탐지하는 패턴:
 * - 락 없는 공유 변수 동시 접근 (data race)
 * - READ_ONCE/WRITE_ONCE 누락
 * - 보호되지 않는 구조체 필드 접근
 */

/* 2. Lockdep — 잠금 의존성 및 데드락 사전 탐지 */
CONFIG_LOCKDEP=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCK_STAT=y

/* 3. syzbot/syzkaller — 퍼저 기반 경쟁 조건 탐지
 * Google이 운영하는 커널 퍼저로, 시스템 콜을 무작위 조합하여
 * 멀티스레드 시나리오에서 경쟁 조건을 자동 탐지
 * https://syzkaller.appspot.com — 발견된 버그 대시보드 */