네임스페이스 (Namespaces)

Linux 네임스페이스를 프로세스 가시성 격리의 핵심 메커니즘 관점에서 심층 분석합니다. PID/mount/network/user/IPC/UTS/cgroup/time 네임스페이스의 역할 분리, clone/unshare/setns 시스템 콜 경로, user namespace와 capability 매핑, 컨테이너 런타임의 네임스페이스 조합 전략, 호스트와의 경계 누수 위험과 방어 패턴, 디버깅 시 네임스페이스 진입 절차(nsenter/procfs), 운영 중 장애 원인 추적까지 실제 컨테이너 인프라에 필요한 핵심 내용을 다룹니다.

네임스페이스 개요

네임스페이스는 커널 리소스를 격리하여 프로세스 그룹이 독립적인 시스템 뷰를 갖게 하는 메커니즘입니다. 컨테이너(Docker, LXC)의 핵심 기반 기술입니다.

네임스페이스 격리 원리

네임스페이스의 핵심 원리는 "같은 커널 위에서 서로 다른 시스템처럼 보이게 만든다"는 것입니다. 운영체제 수준의 가상화가 아니라, 커널 자원에 대한 뷰(view)를 분리하는 것입니다.

커널 구현: nsproxy 구조체

모든 프로세스(task_struct)는 nsproxy 포인터를 통해 자신이 속한 네임스페이스 집합을 참조합니다. 같은 네임스페이스를 공유하는 프로세스들은 동일한 nsproxy를 가리킵니다:

/* include/linux/nsproxy.h */
struct nsproxy {
    refcount_t count;              /* 참조 카운트 */
    struct uts_namespace  *uts_ns;   /* 호스트명 */
    struct ipc_namespace  *ipc_ns;   /* IPC 객체 */
    struct mnt_namespace  *mnt_ns;   /* 마운트 포인트 */
    struct pid_namespace  *pid_ns_for_children; /* 자식의 PID NS */
    struct net           *net_ns;   /* 네트워크 스택 */
    struct time_namespace *time_ns;  /* 시간 오프셋 */
    struct time_namespace *time_ns_for_children;
    struct cgroup_namespace *cgroup_ns; /* cgroup 뷰 */
};

/* task_struct에서 네임스페이스 접근 */
struct task_struct {
    /* ... */
    struct nsproxy *nsproxy;      /* UTS/IPC/mount/net/time/cgroup 묶음 */
    const struct cred *cred;   /* cred->user_ns 가 권한 기준 */
    struct fs_struct *fs;      /* root/pwd 는 mount NS와 함께 해석 */
    /* 현재 PID 뷰는 task_active_pid_ns(task) 경로로 별도 조회 */
};

중요한 점은 nsproxy가 "현재 task의 모든 격리 상태를 하나의 구조체에 완전히 담아 둔 것"은 아니라는 것입니다. 권한 판정은 cred->user_ns, 현재 PID 뷰는 task_active_pid_ns(task), 현재 경로 해석은 fs_struct와 mount namespace를 함께 봐야 정확하게 복원됩니다. 즉, 컨테이너 문맥을 조사할 때 task->nsproxy만 덤프해서는 충분하지 않습니다.

네임스페이스 격리의 동작 방식은 다음과 같습니다:

• 자원 조회 시 네임스페이스 참조: 커널의 모든 자원 조회 경로(PID 조회, 네트워크 소켓 생성, 마운트 탐색 등)에서 현재 프로세스의 nsproxy를 참조하여 해당 네임스페이스 범위 내에서만 자원을 검색합니다.
• Copy-on-Write 생성: clone()이나 unshare() 시 지정된 네임스페이스만 새로 복사하고, 나머지는 부모와 공유합니다. 이는 생성 비용을 최소화합니다.
• 참조 카운팅으로 수명 관리: 네임스페이스는 참조 카운트가 0이 되면(마지막 프로세스 종료 + bind mount 없음) 자동으로 해제됩니다.

nsproxy 심화

nsproxy는 namespace object 자체가 아니라 현재 task가 어떤 namespace 집합을 보고 있는지 가리키는 묶음 포인터입니다. 실제 격리 상태는 각 concrete namespace 객체(struct net, struct ipc_namespace, struct time_namespace 등)에 들어 있고, nsproxy는 그 객체들을 한 번에 task에 묶어 둡니다. 그래서 task가 네임스페이스 하나만 바꾼다고 해도 필드 하나만 덮어쓰는 방식보다 새 nsproxy를 만들고 필요한 포인터만 교체한 뒤 task의 nsproxy 포인터 자체를 바꾸는 설계가 선택됩니다.

이 간접 계층은 세 가지 면에서 중요합니다. 첫째, task_struct hot path에 namespace별 포인터를 낱개로 직접 박아 넣지 않고도 현재 격리 상태를 표현할 수 있습니다. 둘째, 대부분의 fork()/clone()은 새 네임스페이스를 만들지 않으므로 get_nsproxy(old) 한 번으로 빠르게 공유할 수 있습니다. 셋째, unshare()와 setns()가 "현재 task가 보는 namespace 묶음 전체"를 일관되게 교체할 수 있어, mount/net/ipc/user/time 같은 서로 다른 수명 규칙을 가진 객체들을 하나의 일괄 교체 단위처럼 취급할 수 있습니다.

현재 task가 namespace를 보는 실제 경로

실무에서 가장 많이 생기는 오해는 "task->nsproxy만 보면 현재 task의 namespace 문맥을 전부 알 수 있다"는 가정입니다. 실제로는 그렇지 않습니다. 대부분의 namespace는 nsproxy에서 시작하지만, PID는 활성 뷰와 자식 뷰가 분리되고, User NS는 cred, 경로 해석은 fs_struct가 추가로 개입합니다.

또 하나 중요한 사실은 각 concrete namespace 객체가 다시 자기 소유 user_namespace를 들고 있다는 점입니다. 예를 들어 struct net, struct pid_namespace, struct ipc_namespace, struct time_namespace에는 보통 struct user_namespace *user_ns와 struct ns_common ns가 들어 있습니다. 즉 nsproxy는 "어떤 namespace 객체를 볼 것인가"를 결정하고, cred->user_ns는 "그 객체를 조작할 권한이 있는가"를 판정합니다.

예외: PID와 Time은 현재 뷰와 자식 뷰가 분리된다

nsproxy를 이해할 때 가장 자주 놓치는 부분이 바로 pid_ns_for_children와 time_ns_for_children입니다. 이름 그대로 이 둘은 현재 task 자체가 즉시 쓰는 namespace가 아니라, 앞으로 만들어질 자식에게 적용할 namespace입니다. 이 설계는 "이미 존재하는 task의 PID를 중간에 갈아끼울 수 없는" 현실과, Time NS가 vvar/vDSO와 맞물려 단계적으로 전환되어야 하는 제약에서 나옵니다.

• PID namespace: 현재 task의 PID는 이미 여러 테이블과 pid hash, struct pid, thread_group 연결에 박혀 있으므로, unshare(CLONE_NEWPID)가 현재 task를 새 PID NS로 바로 옮기지 않습니다. 대신 pid_ns_for_children만 바꾸고, 다음 fork()/clone() 자식이 그 namespace의 PID 1 또는 그 이후 번호를 받습니다.
• Time namespace: 현재 읽기 경로는 current->nsproxy->time_ns를 보지만, 자식용 후보는 time_ns_for_children로 따로 관리됩니다. 최근 커널 트리에는 exec_task_namespaces()가 있어 time_ns_for_children != time_ns인 경우 exec 경계에서 현재 task의 time view를 정리해 전환합니다.
• procfs 노출: 그래서 /proc/<pid>/ns/pid와 /proc/<pid>/ns/pid_for_children, /proc/<pid>/ns/time과 /proc/<pid>/ns/time_for_children가 따로 존재합니다. 현재 뷰와 다음 자식 뷰를 둘 다 관찰할 수 있어야 하기 때문입니다.

# 현재 task의 "즉시 적용된" namespace와 "다음 자식용" namespace를 같이 본다.
readlink /proc/self/ns/pid
readlink /proc/self/ns/pid_for_children
readlink /proc/self/ns/time
readlink /proc/self/ns/time_for_children

# PID namespace는 보통 자식을 만들어야 차이가 드러난다.
unshare --pid --fork --mount-proc /bin/sh

컨테이너 런타임이 초기 진입기(process bootstrap)를 별도로 두는 이유도 여기에 있습니다. PID namespace를 바꾸고 싶다면 기존 관리 프로세스 자신이 즉시 "새 PID 1"이 될 수는 없으므로, 보통 얇은 부모 프로세스가 새 namespace를 준비하고 진짜 workload 자식을 그 안에서 시작합니다.

공유, 복사, 해제 수명

nsproxy 자체의 count는 "이 nsproxy를 참조하는 task 수"를 뜻합니다. 반면 각 concrete namespace 객체의 refcount는 "이 namespace 객체를 가리키는 nsproxy 수"를 뜻합니다. 헤더 주석에서도 이 점을 분명히 말합니다. 따라서 스레드 10개가 하나의 nsproxy를 공유해도, net_ns나 mnt_ns의 refcount는 task 수가 아니라 그 namespace를 가리키는 nsproxy 수를 기준으로 변합니다.

/* include/linux/nsproxy.h 의 핵심 규칙 요약 */
/* 1. current만 자신의 tsk->nsproxy 포인터를 바꿀 수 있다. */
/* 2. current의 namespace를 읽을 때는 그냥 역참조하면 된다. */
/* 3. 다른 task의 namespace를 읽을 때는 task_lock(task)가 필요하다. */
/* 4. task->nsproxy == NULL 이면 거의 종료 직전인 task일 수 있다. */

static inline void put_nsproxy(struct nsproxy *ns)
{
    if (refcount_dec_and_test(&ns->count))
        deactivate_nsproxy(ns);
}

최신 커널 트리의 kernel/nsproxy.c를 보면 deactivate_nsproxy()는 결국 put_mnt_ns(), put_uts_ns(), put_ipc_ns(), put_pid_ns(), put_time_ns(), put_cgroup_ns(), put_net()를 차례로 호출해 하위 namespace 객체들의 refcount를 내립니다. 즉 nsproxy가 마지막으로 해제되는 순간이, concrete namespace 객체들의 수명 감소가 시작되는 지점입니다.

• 공유 시점: clone()/fork()에 CLONE_NEW* 플래그가 없으면 보통 기존 nsproxy를 그대로 공유하고 count만 증가합니다.
• 복사 시점: namespace 하나라도 새로 만들거나 기존 다른 namespace에 진입하면 nsproxy 전체가 새로 준비됩니다. "필드 하나만 교체"가 아니라 "새 묶음을 만든 후 task에 스위치"하는 모델입니다.
• 종료 시점: task가 빠져나가면 switch_task_namespaces(tsk, NULL) 같은 경로로 put_nsproxy()가 호출됩니다. 최근 트리에는 exit_nsproxy_namespaces()와 exit_cred_namespaces()가 분리되어 있어, nsproxy 계열과 cred 계열 수명 정리가 나뉘어 있습니다.
• 현재 task 읽기 vs 타 task 읽기: 자기 자신은 락 없이 읽을 수 있지만, 다른 task를 조사할 때는 task_lock()을 잡고 task->nsproxy가 NULL이 아닌지 확인해야 합니다. 그렇지 않으면 종료 경쟁과 엇갈릴 수 있습니다.

clone, unshare, setns에서 nsproxy가 바뀌는 경로

최신 커널 트리 기준으로 nsproxy는 세 가지 큰 경로에서 움직입니다. clone()/clone3()는 자식 task를 만들면서 결정하고, unshare()는 현재 task의 문맥을 갈라내며, setns()는 기존 namespace로 현재 task를 이동시킵니다. 세 경로 모두 최종적으로는 "새 namespace 묶음을 준비한 뒤 switch_task_namespaces()로 교체"하는 형태를 취합니다.

/* clone 경로: copy_process() 내부 */
copy_process(...)
    -> copy_namespaces(flags, child)
       -> /* NEW* 플래그 없음 */ get_nsproxy(old)
       -> /* NEW* 플래그 있음 */ create_new_namespaces(...)
       -> child->nsproxy = new

/* unshare 경로: 현재 task 분리 */
ksys_unshare(...)
    -> unshare_userns(...)
    -> unshare_nsproxy_namespaces(...)
    -> switch_task_namespaces(current, new_nsproxy)

/* setns 경로: fd 또는 pidfd 기반 진입 */
setns(fd, flags)
    -> prepare_nsset(...)
    -> validate_ns() / validate_nsset()
    -> commit_nsset(...)
    -> switch_task_namespaces(current, nsset.nsproxy)

clone 경로: 최신 kernel/nsproxy.c의 copy_namespaces()는 CLONE_NEWNS, CLONE_NEWUTS, CLONE_NEWIPC, CLONE_NEWPID, CLONE_NEWNET, CLONE_NEWCGROUP, CLONE_NEWTIME가 하나도 없으면 빠르게 기존 nsproxy를 공유합니다. 새 namespace가 필요할 때만 create_new_namespaces()를 호출해 자식에게 새 묶음을 달아 줍니다.

unshare 경로: unshare()는 이미 실행 중인 current task를 바꾸므로 비활성 child에 대해 동작하는 copy_* 경로를 그대로 쓸 수 없습니다. 그래서 ksys_unshare()는 먼저 CLONE_NEWUSER면 CLONE_THREAD | CLONE_FS를 자동 포함시키고, CLONE_NEWNS면 CLONE_FS를 같이 요구하는 등 제약을 정리한 뒤, 새 cred, 새 fs_struct, 새 nsproxy를 준비해 마지막에 현재 task로 스위치합니다.

setns 경로: 최근 커널의 setns()는 오래된 "/proc/<pid>/ns/net 파일 디스크립터 하나" 방식뿐 아니라 pidfd + namespace bitmask 경로도 갖습니다. 내부적으로는 prepare_nsset()가 임시 nsset를 만들고, validate_ns() 또는 validate_nsset()가 대상 task의 nsproxy와 cred를 스냅샷으로 잡은 뒤, 모든 검증이 끝난 후 commit_nsset()가 commit_creds(), timens_commit(), switch_task_namespaces()를 순서대로 수행합니다. 즉 검증 실패로 중간 상태가 남지 않도록 일괄 적용하는 구조입니다.

/* include/linux/nsproxy.h - setns / unshare 지원용 보조 컨텍스트 */
struct nsset {
    unsigned flags;
    struct nsproxy *nsproxy;
    struct fs_struct *fs;
    const struct cred *cred;
};

int copy_namespaces(u64 flags, struct task_struct *tsk);
int unshare_nsproxy_namespaces(unsigned long flags,
    struct nsproxy **new_nsp, struct cred *cred, struct fs_struct *fs);
void switch_task_namespaces(struct task_struct *tsk, struct nsproxy *new);

/proc/pid/ns, nsfs, bind mount로 namespace를 붙잡는 법

네임스페이스를 사용자 공간에서 다루게 해 주는 접점은 /proc/<pid>/ns/*입니다. 최신 fs/proc/namespaces.c를 보면 procfs는 net, uts, ipc, pid, pid_for_children, user, mnt, cgroup, time, time_for_children 같은 항목을 노출합니다. 이 파일들은 보통 symlink처럼 보이지만, 실제로는 nsfs inode와 struct ns_common를 경유해 namespace 객체를 가리킵니다.

# 네임스페이스 식별자 확인
readlink /proc/self/ns/net
readlink /proc/self/ns/mnt
readlink /proc/self/ns/pid_for_children

# namespace를 파일 경로로 고정하여 수명 유지
mkdir -p /run/ns
mount --bind /proc/$TARGET_PID/ns/net /run/ns/demo-net

# 이후 task가 모두 종료해도 bind mount가 남아 있으면 namespace는 유지될 수 있다.
nsenter --net=/run/ns/demo-net ip link show
umount /run/ns/demo-net

운영 환경에서는 이 메커니즘이 자주 쓰입니다. CNI 플러그인이나 디버깅 도구가 컨테이너 네트워크 namespace를 잠시 보존하려고 /proc/$pid/ns/net를 bind mount해서 /var/run/netns/... 아래에 두는 방식이 대표적입니다. 이렇게 하면 원래 task가 죽어도 namespace 핸들이 남아 있어 추후 setns()나 nsenter로 재진입할 수 있습니다.

실전 디버깅 체크리스트

• "같은 컨테이너인지"를 inode로 확인: readlink /proc/$pid/ns/*의 name:[inum]을 비교하면 task들이 같은 namespace를 공유하는지 빠르게 볼 수 있습니다.
• PID는 반드시 현재 뷰와 자식 뷰를 같이 본다: pid와 pid_for_children를 함께 봐야 unshare(CLONE_NEWPID) 직후의 상태를 오해하지 않습니다.
• Time NS도 pair로 본다: time과 time_for_children의 inode가 다를 수 있으며, 이는 아직 fork / exec 경계가 지나지 않았음을 뜻할 수 있습니다.
• setns 실패는 capability만의 문제가 아니다: 멀티스레드, CLONE_FS 공유, mount 전환 시 root / pwd 정합성, ptrace_may_access() 조건 때문에도 자주 실패합니다.
• mount namespace는 fs_struct까지 본다: namespace inode만 같아도 chroot, pivot_root, pwd 차이 때문에 실제 파일 경로 해석은 달라질 수 있습니다.
• User NS owner를 같이 본다: concrete namespace 객체는 자기 소유 user_ns를 갖고, 현재 task의 cred->user_ns에 대해 ns_capable()가 평가됩니다. UID 0이라고 해서 항상 허용되는 것이 아닙니다.
• 수명 누수는 fd와 bind mount에서 생긴다: "프로세스는 다 죽었는데 namespace가 남아 있다"면 열린 fd, bind mount, 런타임의 namespace 핀 파일을 먼저 의심해야 합니다.

PID 번역 원리

PID 네임스페이스는 계층적 번역(hierarchical translation) 모델을 사용합니다. 하나의 프로세스가 여러 PID 네임스페이스에서 서로 다른 PID를 가질 수 있습니다:

/* 커널 내부: 프로세스는 레벨별로 PID를 가짐 */
struct pid {
    refcount_t count;
    unsigned int level;        /* PID NS 깊이 */
    struct upid numbers[];      /* 각 레벨별 PID 번호 */
};

struct upid {
    int nr;                        /* 해당 NS에서의 PID 값 */
    struct pid_namespace *ns;      /* 소속 NS */
};

/* 예: 컨테이너 프로세스의 PID 매핑
 * Host NS (level 0): PID 1234
 * Container NS (level 1): PID 1
 * → numbers[0] = {nr=1234, ns=host_ns}
 * → numbers[1] = {nr=1, ns=container_ns}
 *
 * 자식 NS에서는 부모 NS의 PID를 볼 수 없지만,
 * 부모 NS에서는 자식의 모든 프로세스를 볼 수 있음
 */

네임스페이스 유형

Time Namespace 통합 요약

Time Namespace는 다른 네임스페이스와 달리 "자원 자체"가 아니라 CLOCK_MONOTONIC/CLOCK_BOOTTIME의 읽기 오프셋을 격리합니다. 컨테이너 체크포인트/복원(CRIU) 시 시간축 일관성을 보장하는 것이 주목적입니다.

• 격리 대상: CLONE_NEWTIME, monotonic/boottime 오프셋
• 비격리 대상: CLOCK_REALTIME은 전역 시간 공유
• 운영 포인트: 오프셋은 첫 진입 이후 동결되므로 생성 순서 설계가 중요
• 심화 문서: 상세 API/제약/디버깅은 Time Namespaces 참고

네임스페이스 API

#include <sched.h>

/* 새 네임스페이스로 프로세스 생성 */
clone(child_fn, stack, CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | SIGCHLD, arg);

/* 현재 프로세스를 새 네임스페이스로 이동 */
unshare(CLONE_NEWNS | CLONE_NEWPID);

/* 기존 네임스페이스에 진입 */
int fd = open("/proc/<pid>/ns/net", O_RDONLY);
setns(fd, CLONE_NEWNET);

PID Namespace

PID 네임스페이스는 프로세스 ID를 격리합니다. 새 PID NS 내의 첫 프로세스는 PID 1이 되며, 부모 NS에서는 다른 PID로 보입니다.

Network Namespace

네트워크 네임스페이스는 네트워크 인터페이스, 라우팅 테이블, iptables 규칙, 소켓 등을 완전히 격리합니다. veth 페어로 네임스페이스 간 통신을 구성합니다.

# 네트워크 네임스페이스 생성
ip netns add myns

# veth 페어 생성 및 연결
ip link add veth0 type veth peer name veth1
ip link set veth1 netns myns

# 네임스페이스 내에서 명령 실행
ip netns exec myns ip addr add 10.0.0.2/24 dev veth1
ip netns exec myns ip link set veth1 up

Mount Namespace

Mount namespace는 프로세스별로 독립적인 마운트 포인트 테이블을 제공합니다. 컨테이너가 호스트와 다른 파일시스템 뷰를 가질 수 있게 합니다. 내부적으로 각 Mount NS는 자체 struct mnt_namespace를 가지며, 이 안에 마운트 포인트의 트리 구조가 저장됩니다.

Mount Propagation 원리

Mount namespace 간의 마운트 이벤트 전파는 peer group 메커니즘으로 제어됩니다. 새 Mount NS를 생성하면 기본적으로 부모와 peer group을 형성하여 마운트 이벤트가 양방향으로 전파됩니다. propagation 유형에 따라 이 동작을 제어합니다:

/* 새 mount namespace에서 프로세스 생성 */
int flags = CLONE_NEWNS;
unshare(flags);

/* pivot_root: 컨테이너의 루트 파일시스템 변경 */
pivot_root("./newroot", "./newroot/oldroot");
umount2("/oldroot", MNT_DETACH);

# mount namespace 생성 및 확인
unshare --mount --propagation private /bin/bash
mount --bind /tmp/myroot /mnt
# 호스트에서는 /mnt가 변경되지 않음

# mount propagation 유형
mount --make-shared /mnt     # 양방향 전파
mount --make-slave /mnt      # 단방향 (호스트→컨테이너)
mount --make-private /mnt    # 전파 없음
mount --make-unbindable /mnt # bind mount도 불가

User Namespace

User namespace는 UID/GID 매핑을 격리합니다. 컨테이너 내에서 root(UID 0)로 보이지만 호스트에서는 일반 사용자입니다.

/* user namespace 생성 */
unshare(CLONE_NEWUSER);

/* UID 매핑 설정: /proc/PID/uid_map */
/* 형식: container_uid  host_uid  range */
/* 예: "0 1000 1" → 컨테이너 UID 0 = 호스트 UID 1000 */

# unprivileged 컨테이너 생성
unshare --user --map-root-user /bin/bash
id   # uid=0(root) gid=0(root)  (컨테이너 내부에서)

# UID 매핑 확인
cat /proc/self/uid_map
#          0       1000          1

Cgroup Namespace

Cgroup namespace는 프로세스의 cgroup 뷰를 격리합니다. 컨테이너 내에서 /proc/self/cgroup이 루트(/)로 보입니다.

UTS와 IPC Namespace

# UTS namespace: 호스트네임 격리
unshare --uts /bin/bash
hostname container-host
hostname  # container-host (호스트에는 영향 없음)

# IPC namespace: System V IPC, POSIX 메시지 큐 격리
unshare --ipc /bin/bash
ipcs  # 빈 IPC 테이블 (호스트의 IPC 객체 안보임)

네임스페이스 생명주기와 관리

/* 네임스페이스 생성 방법 3가지 */

/* 1. clone() 시 플래그로 생성 */
clone(child_fn, stack, CLONE_NEWPID | CLONE_NEWNET | SIGCHLD, arg);

/* 2. unshare()로 현재 프로세스의 namespace 분리 */
unshare(CLONE_NEWNS | CLONE_NEWPID);

/* 3. setns()로 기존 namespace에 진입 */
int fd = open("/proc/PID/ns/net", O_RDONLY);
setns(fd, CLONE_NEWNET);
close(fd);

# 프로세스의 네임스페이스 확인
ls -la /proc/self/ns/
# cgroup -> cgroup:[4026531835]
# ipc    -> ipc:[4026531839]
# mnt    -> mnt:[4026531841]
# net    -> net:[4026531840]
# pid    -> pid:[4026531836]
# user   -> user:[4026531837]
# uts    -> uts:[4026531838]

# 네임스페이스를 파일로 유지 (bind mount)
touch /run/netns/my_netns
mount --bind /proc/self/ns/net /run/netns/my_netns
# ip netns는 이 방식 사용

# nsenter: 기존 네임스페이스에 진입
nsenter --target $PID --net --pid --mount /bin/bash

컨테이너 런타임과의 관계

Docker, Podman 등의 컨테이너 런타임은 namespace를 조합하여 격리된 환경을 구성합니다:

네임스페이스 관련 주요 취약점

User namespace는 비특권 사용자에게 네임스페이스 내부의 CAP_SYS_ADMIN을 부여하므로, 커널의 다양한 공격 면적을 노출합니다. 많은 커널 취약점이 user namespace를 전제 조건으로 요구하며, 이는 namespace 자체의 보안 설계와 밀접하게 연관됩니다.

/* User Namespace가 공격 전제 조건인 주요 CVE 목록 */

/*
 * CVE-2022-0185: fsconfig() 힙 오버플로우
 *   → user NS의 CAP_SYS_ADMIN으로 fsconfig() 호출 가능
 *
 * CVE-2022-0492: cgroup v1 release_agent
 *   → user NS + cgroup NS로 cgroup 마운트 가능
 *
 * CVE-2022-1015: nf_tables 스택 버퍼 오버플로우
 *   → user NS의 CAP_NET_ADMIN으로 nf_tables 규칙 생성
 *
 * CVE-2023-0386: OverlayFS + FUSE setuid 우회
 *   → user NS에서 FUSE + OverlayFS 마운트 가능
 *
 * CVE-2023-32233: nf_tables 익명 set UAF
 *   → user NS의 CAP_NET_ADMIN으로 nf_tables 조작
 *
 * CVE-2024-1086: nf_tables verdict UAF
 *   → user NS의 CAP_NET_ADMIN으로 트리거
 */

/* User Namespace 공격 면적 제한 방법 */

# 방법 1: User NS 완전 비활성화 (가장 강력)
sysctl -w user.max_user_namespaces=0

# 방법 2: 비특권 User NS 비활성화 (Debian/Ubuntu)
sysctl -w kernel.unprivileged_userns_clone=0

# 방법 3: BPF와 perf 제한 (user NS 내 CAP_SYS_ADMIN 영향 축소)
sysctl -w kernel.unprivileged_bpf_disabled=2
sysctl -w kernel.perf_event_paranoid=3

# 방법 4: AppArmor로 user NS 내 특정 작업 제한 (Ubuntu 23.10+)
# /etc/apparmor.d/unprivileged_userns 프로파일 활용

관련 문서

네임스페이스와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• Linux Containers — 컨테이너 개요
• Docker 커널 내부 — Docker의 네임스페이스 활용
• cgroups — 리소스 제어
• 네트워크 네임스페이스 — 네트워크 격리 심화
• 프로세스 관리 — PID 네임스페이스
• 네트워크 스택 — 네트워크 네임스페이스
• Time Namespaces — 시간 오프셋 격리와 CRIU 연동