SELinux
Security-Enhanced Linux · 시리눅스
는 에서 와 객체의 를 정책에 대입해 접근을 제한하는 강제 접근 통제 체계이다. 파일 모드가 허용한 요청도 주체 도메인·대상 타입·객체 클래스·동작의 조합이 정책에 맞지 않으면 거부될 수 있다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 서비스가 침해돼도 접근할 파일·포트· 범위를 정책으로 제한한다.
- 파일·포트 등에 레이블을 연결하여 경로 이름과 분리된 접근 판단을 제공한다.
- AVC 기록을 통해 거부한 주체·객체·동작을 추적한다.
02어떤 순서로 동작하나
- 접근 요청
httpd 같은 서비스 가 파일 읽기 또는 소켓 등의 작업을 요청한다.
- 컨텍스트 수집
도메인과 대상 객체의 타입·클래스, 요청 동작을 접근 결정의 입력으로 만든다.
- 정책 판정
캐시된 결정 또는 정책 계산으로 허용 관계를 판단한다. 과 포트 타입 설정은 이미 설계된 정책 선택에 영향을 준다.
- 모드에 따른 처리
enforcing에서는 정책 거부를 실제 차단에 반영한다. permissive는 거부를 강제하지 않지만 다른 통제의 거부는 여전히 가능하다.
03먼저 알아둘 용어와 구성요소
- 전형적인 security context는 user:role:type:level 형식이다.
- 일반적인 서버 서비스에서 먼저 보는 중심은 의 domain과 파일의 type이다. 이름에 _t가 붙는 것은 타입 명명 관례다. 예를 들어 httpd_t 가 httpd_sys_content_t로 표시된 웹 문서를 읽는 관계와, 데이터베이스 전용 파일 타입을 읽으려는 관계는 다르게 취급된다.
- 은 현재 파일의 컨텍스트를 바꾼다. 그러나 기본 경로 매핑을 바꾸는 것은 아니므로 restorecon이나 전체 재레이블링 뒤 의도한 변경이 사라질 수 있다.
- 는 경로 패턴에 어떤 기본 타입을 적용할지 정책 매핑을 추가하고, restorecon은 그 매핑을 실제 파일에 적용한다. 설정 선언과 객체 상태 반영이라는 두 단계다.
- 은 정책에 미리 정의된 조건부 기능을 켜고 끄는 장치다. httpd_can_network_connect처럼 웹 서비스의 외부 연결 허용과 관계된 선택지는 서비스가 실제로 해야 하는 동작과 맞추어 판단한다.
- AVC는 Access Vector Cache로 접근 판단을 캐시하는 구조다. 로그에 AVC가 나타난다는 것과 모든 접근이 매번 하나의 새 로그로 기록된다는 것은 다르다.
Disabled 화면에서 알 수 있는 것과 정책 검증에 필요한 것
방화벽 서비스 상태와 상태를 분리하고, 정책의 허용·거부를 검증할 수 있는 실행 조건을 정한다.
실습 구성과 전제
- 두 화면 모두 getenforce가 Disabled를 반환하는 사례다. 이 상태의 서비스 성공으로 정책의 적절성을 입증할 수는 없다.
- 정책 실습을 재구성할 때에는 가 활성화된 별도 을 사용한다. 방화벽이나 를 끄는 절차를 해결책으로 삼지 않는다.
서로 다른 제어 장치의 상태를 나눈다
- systemctl status 는 방화벽 관리 서비스의 상태다. getenforce는 실행 상태를 보고하므로 두 출력은 독립된 제어 경계다.
- 관리 서비스가 inactive라는 사실만으로 커널의 모든 방화벽 규칙이 없다고 단정할 수 없다. 또한 Disabled는 Permissive와 다르다.
bashgetenforce sestatus systemctl status firewalld --no-pager상태 조회만 수행하는 예시이며 보안 기능을 변경하지 않는다.
원본 크기로 보기 ↗- firewalld는 Loaded disabled와 Active inactive (dead)로 표시된다.
- 그 아래 getenforce 결과는 Disabled로 나타나 방화벽 출력과 별도로 SELinux 상태를 알려 준다.
확인 기준상태를 firewall 서비스 상태로 대신 판단하지 않는다. 이 화면에는 접근 거부 기록이 없다.
Disabled와 Permissive의 증거 차이를 설명한다
- Disabled에서는 정책이 접근을 판정하는 상태가 아니다. Permissive에서는 정책을 로드한 채 거부될 요청을 기록하지만 강제 차단하지 않는다.
- 따라서 두 번째 화면의 Disabled는 첫 화면과 같은 상태 분류를 보일 뿐, 특정 파일의 레이블이나 allow 규칙이 올바르다는 결과는 아니다.
원본 크기로 보기 ↗- getenforce 명령 하나와 Disabled 응답이 보인다.
- 정책 타입, 파일 컨텍스트, AVC 기록은 이 화면에 표시되지 않는다.
확인 기준서비스가 열렸다는 결과만 남기지 말고, Enforcing·Permissive·Disabled 중 어떤 조건에서 시험했는지 기록한다.
활성화된 VM에서는 주체·객체·동작을 묶어 검증한다
- 웹 서버 의 도메인, 요청 파일의 타입, 요구한 read·open 같은 동작을 연결한다. 실패 시 AVC의 scontext·tcontext·tclass·denied 항목을 읽는다.
- 재구성 조회 결과에 레이블 차이가 보이면 영구 파일 컨텍스트 매핑과 실제 레이블을 확인한다. 임의 허용 규칙을 추가하기 전에 경로와 배포판 정책의 의도를 대조한다.
bashps -eZ | grep -E "httpd|nginx" ls -Zd /srv/lab-web ausearch -m AVC -ts recent가 활성화된 별도 실습 에서 컨텍스트와 최근 AVC를 읽는 예시다. 감사 로그 조회에는 권한이 필요할 수 있다.
확인 기준Disabled 환경에서 AVC가 없다는 사실은 허용 규칙의 증명이 아니다. Enforcing 환경의 실제 재현 요청과 시간 범위를 맞춰 확인한다.
실습에서 확인한 동작 원리
- 정책을 검증하려면 정책이 적용되는 모드와 실제 요청을 함께 제시해야 한다.
- 방화벽은 네트워크 경로, 는 와 객체 사이의 허용 동작을 다루므로 상태와 증거를 분리한다.
동작·명령 참고 문서
04예제로 따라가기
- 웹 문서 파일이 user_home_t인데 가 httpd_t이면 단순 chmod 644와 별도로 해당 타입의 읽기 허용 여부가 문제될 수 있다.
- 는 경로의 영구 레이블 매핑을 관리하고 restorecon이 매핑을 실제 객체 레이블에 반영하는 흐름이다.
- AVC에서 name_bind가 거부됐다면 파일 읽기 문제로 취급하지 않고 해당 포트 번호와 포트 타입·서비스 도메인을 연결한다.
05혼동하기 쉬운 점과 확인 기준
- 동일 시각의 DAC·마운트·서비스 오류와 감사 경로를 함께 본다. AVC가 없다는 이유만으로 를 범인으로 확정하거나 완전히 배제하지 않는다.
- audit2allow 결과를 무조건 적용하면 공격 시도까지 정상 권한으로 추가할 수 있으므로 기존 정책 의미를 대신하는 자동 승인 도구로 사용하지 않는다.
- 과도한 권한 부여로 경로 오류를 숨기지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
함께 보는 학습 자료
아래 공식 자료를 본문의 개념·예제와 함께 읽어 보세요. 자료별로 확인할 위치와 관찰할 내용을 적었습니다.
SELinux 구조와 Apache·MariaDB 접근 도해
1.1의 Figure 1.1과 1.4의 설명을 함께 읽는다. 파일 소유 권한이 같아도 도메인과 파일 타입 조합에 따라 결과가 달라지는 사례다.
- httpd_t와 mysqld_t가 각각 접근하는 파일 타입
- DAC가 먼저 거부했을 때 거부 로그가 없는 이유
- enforcing과 permissive의 실제 차단 차이
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.