리눅스 배우기 #21 – SELinux 보안 프레임워크 이해와 실무 운용

들어가기 #

SELinux는 이름만 들어도 부담을 느끼는 경우가 많습니다.
실제로도 리눅스를 어느 정도 사용하다가 처음으로 "SELinux 때문에 안 된다"라는 상황을 겪으면, 가장 먼저 끄고 싶어지는 대상이기도 합니다.

하지만 SELinux는 단순한 옵션이 아니라, 리눅스 보안 모델의 방향 자체를 바꾼 핵심 구성 요소입니다.
이 글에서는 명령어 나열보다는,

• SELinux가 왜 만들어졌는지
• 어떤 보안 모델을 기반으로 동작하는지
• 실무에서 문제가 생겼을 때 어떤 순서로 접근해야 하는지

이 흐름을 중심으로 정리해보려 합니다.

---

SELinux Security Framework #

SELinux(Security-Enhanced Linux)는 NSA가 주도하여 설계한 강제 접근 제어(MAC) 기반 보안 프레임워크입니다.
오픈소스 리눅스 환경에서 기존 권한 모델의 한계를 보완하기 위해 만들어졌습니다.

핵심은 하나입니다.

“퍼미션이 맞아도, 정책이 허용하지 않으면 접근할 수 없다”

이를 이해하려면 먼저 리눅스의 접근 제어 모델을 구분해서 볼 필요가 있습니다.

---

리눅스 접근 제어 모델 3가지 #

DAC (Discretionary Access Control) #

임의 접근 제어 모델입니다.
파일과 디렉터리의 소유자(owner) 가 접근 권한을 결정합니다.

• chmod
• chown
• rwx 퍼미션

우리가 일반적으로 알고 있는 리눅스 권한 시스템은 모두 DAC 기반입니다.

문제는,
소유자가 실수로 권한을 열어버리면 시스템 전체가 위험해질 수 있다는 점입니다.

---

MAC (Mandatory Access Control) #

강제 접근 제어 모델입니다.
사용자 의도와 상관없이 정책이 최우선으로 적용됩니다.

SELinux는 이 MAC 모델을 기반으로 설계되었습니다.

• 정책(policy)에 의해 접근 허용 여부 결정
• 중앙 집중적 제어 가능
• 퍼미션보다 항상 우선

SELinux가 "까다롭다"고 느껴지는 이유가 바로 여기에 있습니다.

---

RBAC / RAC (Role-Based Access Control) #

역할 기반 접근 제어 모델입니다.

• 사용자에게 역할(role)을 부여
• 역할에 따라 수행 가능한 작업 제한

SELinux 내부에서도 role 개념이 존재하지만,
실무에서는 type 중심으로 다루는 경우가 대부분입니다.

---

SELinux의 작동 흐름 #

SELinux는 접근 요청이 발생하면 다음 순서로 판단합니다.

1. 기본 퍼미션(DAC) 확인
2. Security Context 확인
3. 정책에 따라 허용 또는 차단

여기서 핵심은 2번입니다.

---

Security Context 구조 #

SELinux는 모든 프로세스와 파일에 보안 꼬리표(Security Context) 를 붙여 관리합니다.

형식은 다음과 같습니다.

plainCopy
identity:role:type:level

이 중 실무에서 가장 중요한 것은 type 입니다.

• 프로세스 타입
• 파일 타입

이 둘의 조합이 정책에 정의되어 있어야 접근이 허용됩니다.

---

Security Context 확인 방법 #

아래 명령어들은 반드시 익숙해져야 합니다.

• 현재 사용자 컨텍스트 확인

plainCopy
id

• 파일 컨텍스트 확인

plainCopy
ls -lZ

• 프로세스 컨텍스트 확인

plainCopy
ps -eZ

SELinux 트러블슈팅의 시작은 항상 타입 확인입니다.

---

Relabeling Files (컨텍스트 복구) #

웹 디렉터리에 파일을 복사했는데 접근이 안 되는 경우는 매우 흔합니다.

bashCopy
touch /var/www/html/1.html
touch /var/www/html/2.html
cp -a /etc/passwd /var/www/html/3.html

퍼미션만 보면 문제 없어 보이지만,
/etc/passwd의 보안 컨텍스트는 웹 서비스와 전혀 맞지 않습니다.

---

chcon #

• 임시로 Security Context를 변경
• 타입을 정확히 알고 있을 때만 사용

bashCopy
chcon -t httpd_sys_content_t /var/www/html/3.html

재부팅이나 정책 재적용 시 원래대로 돌아갑니다.

---

restorecon #

권장되는 방식입니다.

bashCopy
restorecon -vFR /var/www/html

• 정책에 정의된 기본 컨텍스트로 복구
• 실무에서는 restorecon 우선

---

SELinux 동작 모드 #

SELinux는 세 가지 모드로 동작합니다.

bashCopy
getenforce

Enforcing #

• 정책 강제 적용
• 차단 시 실제 접근 불가

Permissive #

• 정책은 검사
• 차단하지 않고 로그만 기록

Disabled #

• SELinux 자체 비활성화
• 재부팅 필요

RHEL 8 이상에서는 커널 파라미터 수정이 필요합니다.

---

SELinux 정책 선택 #

Targeted #

• 기본값
• 주요 데몬만 보호
• 실무 표준

대부분의 서버 환경에서는 Targeted 정책으로 충분합니다.

---

MLS #

• 다단계 보안 모델
• 군·정부 목적
• 운영 난이도 매우 높음

---

Minimum #

• Targeted 기반 최소 보호
• 테스트, 분석 환경용

---

SELinux Booleans #

SELinux Boolean은 정책을 수정하지 않고 동작만 제어하는 스위치입니다.

문제 해결 시 가장 먼저 확인해야 할 요소입니다.

Boolean 목록 확인 #

bashCopy
getsebool -a
getsebool -a | grep httpd

Boolean 변경 #

bashCopy
setsebool httpd_can_network_connect on

재부팅 시 초기화됩니다.

영구 적용 #

bashCopy
setsebool -P httpd_can_network_connect on

---

실습: FTP 업로드 차단 문제 #

FTP 업로드 실패 시 퍼미션이 아닌 SELinux 문제일 가능성이 높습니다.

로그를 확인하면 다음과 같은 메시지를 볼 수 있습니다.

bashCopy
sealert -l <UUID>

Boolean 하나로 해결되는 경우가 많습니다.

bashCopy
setsebool -P ftpd_full_access on

---

Permissive Domains #

특정 서비스만 permissive로 설정할 수 있습니다.

bashCopy
semanage permissive -a httpd_t

전체 SELinux를 끄지 않고 문제 분석이 가능합니다.

---

SELinux 트러블슈팅 접근 순서 #

1. 서비스 로그 확인
2. /var/log/messages 또는 journalctl
3. sealert -l 실행
4. Boolean 여부 확인
5. port, type, context 점검

SELinux 문제는 대부분 정책 위반 로그에 답이 이미 적혀 있습니다.

---

마무리 #

SELinux는 어렵기 때문이 아니라,
제대로 된 흐름 없이 접근해서 어렵게 느껴지는 경우가 많습니다.

• 끄는 대신 이해하기
• 막연한 공포 대신 로그 읽기
• 퍼미션이 아니라 type부터 보기

이 세 가지만 익숙해져도 SELinux는 더 이상 장애물이 아니라,
시스템을 지켜주는 안전장치로 보이기 시작합니다.