SELinux(Security-Enhanced Linux)는 미국 국가안보국(NSA)이 개발하고 2000년 오픈소스로 공개한 Linux 커널 보안 모듈이다.[1] 기존 Linux가 사용자 재량에 맡기는 임의적 접근 제어(DAC, Discretionary Access Control) 방식을 보완하여, 시스템 관리자가 정의한 정책에 따라 모든 프로세스와 리소스 접근을 강제하는 강제 접근 제어(MAC, Mandatory Access Control) 아키텍처를 Linux 커널에 구현한다. 2003년 Linux 커널 2.6에 메인라인으로 병합된 이후 Red Hat Enterprise Linux(RHEL), Fedora, 안드로이드 (운영체제) 등 주요 배포판과 플랫폼의 핵심 보안 기반으로 자리잡았다.

1. 역사와 배경

SELinux의 개발은 1990년대 후반 NSA가 주도한 Flask 아키텍처 연구에서 시작되었다. Flask는 커널 내부에 보안 결정 로직을 분리하는 개념으로, 이를 Linux에 구현한 것이 SELinux의 원형이다. NSA는 NAI Labs, Secure Computing Corporation, MITRE Corporation과 협력하여 개발을 진행했으며, 2000년 12월 22일 GNU GPL 라이선스로 오픈소스 커뮤니티에 최초 공개했다.[1]

초기에는 별도의 커널 패치로 배포되었으나, 2003년 8월 Linux 커널 2.6.0-test3에 공식 통합되며 범용 Linux 보안 기술로 전환점을 맞았다. 이후 Linux Security Modules(LSM) 프레임워크 위에서 동작하도록 재구성되어, 다른 보안 모듈(AppArmor 등)과 공존 가능한 구조가 되었다. NSA는 초기 개발 이후 프로젝트 관리를 커뮤니티와 Red Hat에 이전했으며, 현재는 주로 Red Hat 엔지니어들이 개발을 이끌고 있다.

2. MAC 보안 모델과 동작 원리

기존 Linux의 DAC 모델에서는 파일 소유자가 접근 권한을 직접 설정하므로, root 권한을 탈취당한 프로세스는 시스템 전체에 무제한 접근할 수 있다. SELinux의 MAC 모델은 이 문제를 근본적으로 다른 방식으로 접근한다.[2]

SELinux에서 모든 주체(프로세스)와 객체(파일·소켓·포트 등)에는 보안 컨텍스트(Security Context)가 부여된다. 보안 컨텍스트는 user:role:type:sensitivity[:categories] 형식으로 표현되며, 커널은 접근 요청이 발생할 때마다 이 컨텍스트를 기반으로 정책을 조회하여 허용 또는 거부를 결정한다. 기본 거부(default deny) 원칙에 따라, 정책에 명시적으로 허용되지 않은 모든 접근은 자동으로 차단된다.

SELinux는 세 가지 동작 모드를 지원한다.

  • Enforcing: 정책을 실제로 적용하여 위반 접근을 차단하고 감사 로그에 기록한다.
  • Permissive: 정책 위반을 차단하지 않고 로그만 기록한다. 정책 개발·디버깅 단계에서 활용된다.
  • Disabled: SELinux를 완전히 비활성화한다. 재활성화 시 파일시스템 재레이블링이 필요하다.

현재 실행 모드는 getenforce 명령으로 확인하고, setenforce 명령으로 Enforcing과 Permissive 사이를 즉시 전환할 수 있다. 영구 설정은 /etc/selinux/config 파일에서 관리한다.

3. 정책 구조: Type Enforcement와 MLS

SELinux 정책의 핵심은 두 가지 접근 제어 개념의 조합이다.[3]

3.1 Type Enforcement (TE)

Type Enforcement는 SELinux 정책의 기본 레이어로, 모든 프로세스와 파일에 타입(type)을 부여하고 타입 간 허용 관계를 규칙으로 정의한다. 프로세스에 부여된 타입은 특별히 도메인(domain)이라 부른다. 예를 들어 Apache 웹서버 프로세스는 httpd_t 도메인에서 동작하고, 웹 콘텐츠 파일에는 httpd_sys_content_t 타입이 붙는다. 정책은 httpd_t 도메인이 httpd_sys_content_t 타입 파일을 읽을 수 있다는 규칙을 명시하며, 그 외의 접근은 모두 거부된다. 이 구조 덕분에 웹서버 프로세스가 침해당하더라도 시스템의 다른 영역으로 피해가 확산되지 않는다.

3.2 Multi-Level Security (MLS)

MLS는 군사·정부 환경에서 사용하는 기밀 등급 기반 접근 제어를 구현한 레이어다. 각 객체와 주체에 민감도 레벨(sensitivity level)과 카테고리(category)를 부여하고, Bell-LaPadula 모델에 따라 정보 흐름을 제어한다.[3] 기본 정책은 TE만 사용하는 targeted 정책이며, MLS까지 활성화하는 mls 정책은 별도로 설정해야 한다. RHEL 계열에서는 /etc/selinux/config의 SELINUXTYPE 값을 targeted 또는 mls로 지정한다.

역할 기반 접근 제어(RBAC, Role-Based Access Control)도 SELinux가 지원하는 추가 레이어로, 사용자 역할에 따라 진입 가능한 도메인을 제한한다.

4. Android SELinux

안드로이드 (운영체제)는 Android 4.3(2013년)부터 SELinux를 도입했으며, Android 5.0(2014년) 이후 모든 도메인에 Enforcing 모드를 완전 적용했다.[4] AOSP의 SELinux는 Linux 배포판과 동일한 TE 기반으로 동작하지만, 모바일 플랫폼 특성에 맞게 정책 구조가 변형되어 있다.

Application Sandbox 모델과 결합하여, 일반 앱 프로세스는 기본적으로 untrusted_app 도메인에서 실행되며 다른 앱이나 시스템 서비스에 접근할 수 없다. Android 8.0부터는 플랫폼 정책과 벤더 정책을 분리하는 구조(Treble)가 도입되어, 플랫폼 업데이트와 기기 제조사 커스텀 정책을 독립적으로 유지·업데이트할 수 있게 되었다. Android 12 이후에는 MLS의 카테고리 기능을 활용해 멀티유저 환경에서 사용자 간 앱 데이터 격리도 강화되었다.

Android framework의 시스템 서버, Zygote, mediaserver 등 핵심 데몬들은 각각 전용 도메인을 가지며, Verified Boot과 함께 Android 보안 모델의 중심축을 이룬다.

5. 주요 배포판 채택 현황

SELinux는 Red Hat 계열 배포판의 기본 MAC 솔루션으로 자리잡았다.[2]

  • RHEL / CentOS Stream / AlmaLinux / Rocky Linux: SELinux가 기본 활성화(Enforcing)된 상태로 출하된다. targeted 정책이 기본값이다.
  • Fedora: RHEL의 업스트림 배포판으로, 최신 SELinux 정책이 가장 먼저 반영된다.
  • Debian / Ubuntu: 기본 MAC 솔루션으로 AppArmor를 채택한다. SELinux를 수동으로 설치하고 전환할 수 있으나 공식 지원 수준은 낮다.
  • Android: 모든 Android 기기에 SELinux Enforcing이 강제된다. Google Play 단말 인증 요구 사항에도 포함된다.
  • Gentoo: SELinux 하드닝 프로파일을 통해 지원하며, 정책을 직접 커스터마이징하려는 고급 사용자층을 대상으로 한다.

6. 관리 도구

SELinux 운영에 필요한 주요 도구들은 policycoreutils 및 policycoreutils-python-utils 패키지에 포함된다.[2]

audit2allow는 빠른 문제 해결에 유용하지만, 생성된 규칙을 그대로 프로덕션에 적용하면 과도한 권한이 부여될 수 있으므로 내용을 반드시 검토해야 한다. 올바른 파일 컨텍스트 문제는 audit2allow가 아닌 semanage fcontext + restorecon으로 해결하는 것이 권장된다.

7. 관련 문서

8. 인용 및 각주

[1] Android Open Source Project, "SELinux in Android", Ssource.android.com(새 탭에서 열림) — NSA가 개발하고 2000년 공개한 SELinux의 역사와 Android 적용 현황을 설명한다.

[2] Red Hat, "What is SELinux?", Wwww.redhat.com(새 탭에서 열림) — SELinux가 DAC 대비 MAC를 통해 제공하는 보안 강화 효과를 설명한다.

[3] Red Hat, "Multi-Level Security (MLS)", Aaccess.redhat.com(새 탭에서 열림) — Bell-LaPadula 모델 기반 MLS와 Type Enforcement 정책 구조를 설명한다.

[4] Android Open Source Project, "SELinux in Android", Ssource.android.com(새 탭에서 열림) — Android 5.0에서 모든 도메인에 Enforcing 모드가 완전 적용된 내용을 기술한다.