#!if 문서명2 != null
, [[Android]]#!if 문서명3 != null
, [[]]#!if 문서명4 != null
, [[]]#!if 문서명5 != null
, [[]]#!if 문서명6 != null
, [[]]| <colbgcolor=#fff,#4a4a44><colcolor=#4a4a44,#fff> SELinux Security Enhanced Linux | |
| | |
| 용도 | Linux용 보안 아키텍처 |
| 라이선스 | GNU 일반 공중 사용 허가서 |
| 개발 | Red Hat, 미국 국가안보국 |
| 출시일 | 1998년 1월 1일 |
| 최신 버전 | 3.7 |
| 링크 | |
1. 개요
SELinux(Security-Enhanced Linux, 보안 강화 리눅스)는 Linux Kernel에 내장된 MAC (Mandatory Access Control, 강제적 접근 제어) 모듈이다.[1]2. 원리
SELinux는 시스템의 애플리케이션, 프로세스, 파일에 대한 액세스 제어를 정의한다. 액세스할 수 있는 항목과 액세스할 수 없는 항목을 SELinux에 지정하는 룰 세트인 보안 정책을 사용하여 정책에서 허용되는 액세스를 적용한다. auditd와 연동되어 운영된다.주체가 파일과 같은 객체에 대한 액세스를 요청하는 경우, SELinux는 주체와 객체에 대해 권한이 캐시되는 AVC(Access Vector Cache)를 확인한다.
SELinux가 캐시된 권한에 기반한 액세스에 대한 결정을 내릴 수 없는 경우 보안 서버에 요청을 전송한다. 보안 서버는 애플리케이션이나 프로세스의 보안 컨텍스트와 파일을 확인한다. 보안 컨텍스트는 SELinux 보안 정책 데이터베이스에서 적용된다. 그러면 권한이 허용되거나 거부된다.
권한이 거부되면 auditd에 의해
avc: denied라는 메시지가 /var/log/messages, /var/log/audit/audit.log 파일에 나타난다. #3. 운영
- Enforcing: SELinux가 활성화되고 보안 정책이 적용된다.
- Permissive: SELinux가 활성화되지만 기록을 할 뿐, 보안 정책이 적용되지 않는다.
- Disabled: SELinux가 비활성화된다. #
RHEL 배포판 Linux에는 Enforcing 상태로 기본 탑재되어 있고, Android에는 SELinux의 개량형인 SEAndroid (Security Enhancements for Android)가 Enforcing 상태로 기본 탑재되어 있다.
SELinux의 컨텍스트를 제어하는 툴로는 audit2allow, semanage, semodule 등이 있다.
4. 여담
- 국내 기업들은 SELinux를 골칫덩어리로만 여기며 이를 끄는 경우가 대다수다.[2] 리눅스 기반 전산을 운용하는 회사들로부터 발생하는 많은 보안침해사고는 보안 취약점이 1차적인 원인이지만 2차적으로 SELinux가 꺼져 있어 마지막 방어조차도 안되는 상태도 원인이다. SK텔레콤 유심 정보 유출 사고도 SELinux가 Enforcing 상태로 되어 있었다면 피해 규모가 실제보다 더 작았을 것이다.[3]
- 해외에서도 대다수는 아니지만 많은 기관들이 SELinux를 끄는 것으로 추정된다. 이러한 현실을 비판하고자 stopdisablingselinux.com이라는 사이트가 생겼다.
- SELinux를 Unix 기반 macOS (XNU/Darwin)에 포팅한 SEDarwin (Security-Enhanced Darwin)이 있다. macport를 통해 설치해야 한다. 이외에도 UNIX 계열에는 TrustedBSD, SEBSD (Security-Enhanced BSD) 등의 프로젝트가 있다.
[1] MAC 시스템은 시스템 관리자가 설정한 중앙 정책에 따라 주체가 개체에 대해 수행할 수 있는 작업을 제한하고 제어하도록 설계한 시스템이다. 최소 권한을 원칙으로 한다. #[2] 개인에 비유하자면 백신 프로그램을 램 용량과 배터리만 잡아먹는 골칫덩어리로 보는 것과 같은 이치다. 이는 안전불감증도 있고, 현실적으로 시스템이 넉넉지 않으니 발생하는 것이다.[3] BPF 백도어 공격은 eBPF의 취약점을 이용하여 리버스 쉘을 열어 악의적인 행위를 하는 것이다. 리버스 쉘은 서버 데몬 프로세스의 실행 계정에 할당된 권한 내에서만 악의적인 행위를 할 수 있고, 루트 권한 없이 진행되었다면 SELinux 정책에 의하여 차단된다. NGINX 등의 서버 데몬이 서비스 전용 계정의 권한이 아닌 루트 권한으로 실행되었다면, 이를 통한 리버스 쉘도 루트 권한 내에서 실행되기에 SELinux를 원격으로 끌 수 있다. 따라서, SELinux가 효과를 보려면 무분별한 루트 권한 할당을 지양하고 각 프로세스 별로 최소한의 권한만을 주어야 한다.