Linux 시스템 보안 기초 · 03/50편
이 글은
리눅스 시스템 기초·파일 · 권한 · 사용자 관리·서비스 · 프로세스 관리시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다.
선행 학습
1. 들어가며
리눅스 권한(rwx)만으로는 막지 못하는 공격이 있습니다. 파일 소유자가 마음대로 권한을 열어줄 수 있기 때문입니다. 이 한계를 메우는 것이 MAC(강제적 접근통제), 즉 SELinux와 AppArmor입니다. 이번 편은 두 접근통제 모델의 차이와, SOC가 왜 MAC 로그를 봐야 하는지 정리합니다.
2. 핵심 개념
- DAC (Discretionary Access Control, 임의적 접근통제): 자원의 소유자가 권한을 결정. 리눅스 기본 권한(rwx), ACL이 여기 속합니다. 유연하지만, 소유자가 실수로/악의로 권한을 열면 그대로 뚫립니다.
- MAC (Mandatory Access Control, 강제적 접근통제): 시스템 정책이 접근을 강제. 소유자라도 정책을 넘을 수 없습니다. SELinux(RHEL 계열 기본), AppArmor(Ubuntu 계열 기본)가 대표적입니다.
쉽게 말해 DAC는 '집주인이 열쇠를 나눠주는 것', MAC은 '건물 전체에 적용되는 출입 규정'입니다.
접근 요청
│
▼
[ DAC 검사 ] ← 소유자/권한 비트(rwx), ACL
│ 통과
▼
[ MAC 검사 ] ← SELinux/AppArmor 정책 (통과해도 여기서 또 막힐 수 있음)
│ 통과
▼
접근 허용3. 동작 원리
리눅스에서 접근은 DAC를 먼저 통과한 뒤 MAC을 다시 통과해야 최종 허용됩니다. 즉 두 관문이 직렬로 놓여 있습니다.
SELinux는 모든 주체·객체에 보안 컨텍스트(label) 를 붙이고(예: httpd_t, httpd_sys_content_t), 'httpd_t 프로세스는 httpd_sys_content_t 파일만 읽는다' 같은 정책을 강제합니다. 그래서 웹서버가 침해되어도 정책 밖 파일(예: /etc/shadow)은 SELinux가 차단합니다. AppArmor는 label 대신 경로 기반 프로파일로 같은 목적을 달성합니다.
4. 명령어 실습
# --- RHEL/Rocky (SELinux) ---
getenforce # Enforcing / Permissive / Disabled
ls -Z /var/www/html # 파일의 보안 컨텍스트(label) 확인
sudo ausearch -m AVC -ts recent # SELinux 거부(AVC) 로그
# --- Ubuntu/Debian (AppArmor) ---
sudo aa-status # 로드된 프로파일 상태
sudo journalctl -k | grep -i apparmor | tail5. 실행 결과
SELinux Enforcing 상태에서 웹서버가 정책 밖 파일을 읽으려다 거부되면 다음과 같은 AVC 로그가 남습니다. (예시 출력 — RHEL 계열 기준, 본 실습 컨테이너는 SELinux 미탑재)
type=AVC msg=audit(1758.../0): avc: denied { read } for pid=1234 comm="httpd"
name="shadow" dev="dm-0" ino=... scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:shadow_t:s0 tclass=file permissive=0denied { read }, comm="httpd", tcontext=...shadow_t 조합은 '웹서버가 shadow 파일을 읽으려다 SELinux에 막혔다'는 뜻으로, 침해 시도의 강력한 근거입니다.
6. 보안 관점 — 정상 사용 vs 악용
- 정상: 애플리케이션이 자기 컨텍스트에 허용된 자원만 접근. AVC 거부가 거의 없음.
- 악용/공격 징후: 웹서버·DB 프로세스가 민감 파일을 읽으려다 발생하는 연속적인 AVC denied. 이는 웹셸이나 익스플로잇이 정책 경계를 넘으려는 시도일 수 있습니다.
주의: 관리자가 SELinux를 Permissive나 Disabled로 꺼두는 경우가 많은데, 이는 MAC 관문을 통째로 여는 것이라 SOC 관점에서 위험 신호입니다.
7. 탐지 방법
- SELinux:
ausearch -m AVC,/var/log/audit/audit.log의avc: denied - AppArmor:
dmesg/journalctl -k의apparmor="DENIED" - 모드 확인:
getenforce가Disabled면 그 자체가 점검 대상
8. SOC 관점 — SIEM · Wazuh · IOC
SIEM 규칙에서 AVC denied 급증은 익스플로잇/웹셸 활동의 지표로 씁니다. Wazuh는 SELinux/AppArmor 거부 로그를 룰로 파싱하며, 동일 프로세스에서 짧은 시간 다수 거부가 발생하면 알람을 올립니다. MAC 로그는 '공격이 DAC는 뚫었지만 MAC에서 막힌' 순간을 포착하는 마지막 방어선 겸 탐지원입니다.
9. 실습 체크리스트
[ ] DAC와 MAC의 차이를 한 문장으로 설명한다
[ ] getenforce/aa-status로 현재 모드를 확인한다
[ ] ls -Z로 보안 컨텍스트를 읽어 본다
[ ] AVC denied 로그의 의미를 해석한다10. 핵심 정리
- DAC는 소유자가, MAC은 시스템 정책이 접근을 결정한다.
- 리눅스는 DAC 통과 후 MAC을 다시 검사한다(직렬 관문).
- SELinux는 label 기반, AppArmor는 경로 기반 정책이다.
- AVC denied 로그는 정책 경계를 넘으려는 시도의 근거다.
- SELinux를 Disabled로 꺼둔 것 자체가 위험 신호다.
11. 다음 편
다음 편에서는 04. Linux UID와 GID 보안 를 다룹니다. 모든 권한의 출발점인 UID/GID, 특히 UID 0의 의미를 파고듭니다.
본 실습은 격리된 테스트 VM(Rocky Linux / Ubuntu, VMware) 및 테스트 계정 환경을 기준으로 하며, 운영 서버를 대상으로 하지 않습니다. 실행 결과는 실제 캡처와 예시 출력을 명확히 구분해 표기합니다.
