SELinux 기초 — 강제 접근 제어(MAC) 입문

지난 글에서 X11 포워딩으로 원격 GUI 앱을 실행하는 방법을 살펴봤습니다. 보안 챕터로 넘어가 **SELinux(Security-Enhanced Linux)**를 다룹니다. RHEL/CentOS/Fedora 계열에서 기본 활성화되어 있는 SELinux는 많은 관리자가 처음 만나면 당황해서 비활성화부터 합니다. 하지만 원리를 이해하면 강력한 방어 계층이 됩니다.

DAC와 MAC의 차이

기존 Linux 파일 권한은 **DAC(Discretionary Access Control, 임의 접근 제어)**입니다. 파일 소유자가 chmod로 권한을 마음대로 바꿀 수 있습니다. root는 모든 파일에 접근할 수 있습니다.

SELinux는 **MAC(Mandatory Access Control, 강제 접근 제어)**입니다. 정책이 커널 수준에서 강제되며, root도 정책에 정의된 범위를 넘을 수 없습니다. Apache가 침해당해도 httpd_t 컨텍스트의 범위 밖에는 접근할 수 없습니다.

세 가지 모드

# 현재 모드 확인
getenforce
# Enforcing / Permissive / Disabled

# 일시적 변경 (재부팅 시 /etc/selinux/config 값으로 돌아옴)
setenforce 0   # Permissive (정책 위반 허용, 로그만 기록)
setenforce 1   # Enforcing  (정책 위반 차단 + 로그)

영구 변경은 /etc/selinux/config에서 SELINUX=enforcing을 수정한 뒤 재부팅합니다. Disabled에서 Enforcing으로 직접 전환하면 재레이블링이 필요합니다.

컨텍스트 라벨

SELinux는 모든 파일, 프로세스, 포트에 컨텍스트(context) 라벨을 붙입니다. 형식은 user:role:type:level입니다.

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

# 프로세스 컨텍스트 확인
ps -eZ | grep httpd
# system_u:system_r:httpd_t:s0    ...  httpd

# 포트 컨텍스트 확인
semanage port -l | grep http
# http_port_t  tcp  80, 443, ...

가장 중요한 부분은 type 필드입니다. httpd 프로세스(httpd_t)는 httpd_sys_content_t 라벨이 붙은 파일에만 읽기 접근이 허용됩니다.

컨텍스트 수정

파일을 다른 위치에서 복사하거나 직접 생성하면 컨텍스트가 틀릴 수 있습니다.

# 임시 변경 (재레이블링 시 초기화됨)
chcon -t httpd_sys_content_t /srv/mysite/index.html

# 재귀적 적용
chcon -Rt httpd_sys_content_t /srv/mysite/

# 권장: restorecon으로 정책 기본값 복원
restorecon -Rv /var/www/html/

# 새 경로를 정책에 영구 등록 (semanage)
semanage fcontext -a -t httpd_sys_content_t "/srv/mysite(/.*)?"
restorecon -Rv /srv/mysite/

semanage fcontext + restorecon 조합이 올바른 방법입니다. chcon만 쓰면 restorecon 실행 시 원래대로 돌아갑니다.

Boolean — 정책 스위치

SELinux 정책에는 시스템 관리자가 켜고 끌 수 있는 Boolean 스위치가 있습니다.

# 모든 Boolean 목록
getsebool -a | grep httpd

# Apache가 네트워크 연결을 시작할 수 있는지
getsebool httpd_can_network_connect
# httpd_can_network_connect --> off

# 활성화 (-P: 영구 저장)
setsebool -P httpd_can_network_connect on

Apache에서 백엔드 API나 DB에 연결할 때 흔히 필요한 Boolean입니다.

트러블슈팅

AVC(Access Vector Cache) 거부 로그는 /var/log/audit/audit.log에 기록됩니다.

# 최근 AVC 거부 확인
ausearch -m avc -ts recent

# sealert: 거부 원인과 해결 방법 제안
sealert -a /var/log/audit/audit.log

# audit2allow: 허용 정책 모듈 자동 생성
audit2allow -w -a
audit2allow -a -M mymodule
semodule -i mymodule.pp

흔한 실수: SELinux가 문제라고 의심되면 setenforce 0으로 전환해 확인하는 것까지는 좋습니다. 그런데 그 상태로 두고 잊어버리는 게 문제입니다. 원인을 파악한 뒤 컨텍스트 수정이나 Boolean 조정으로 해결하고 다시 Enforcing으로 복원하세요.

---

지난 글: X11 포워딩 — SSH로 원격 서버의 GUI 앱 실행하기

다음 글: AppArmor 기초 — 프로파일 기반 강제 접근 제어

읽어주셔서 감사합니다. 😊