SELinux의 정책·컨텍스트와 거부 분석

01주체·객체·동작으로 접근 요청을 모델링하기

• 접근 통제의 대상SELinux는 프로세스가 어떤 자원에 어떤 동작을 할 수 있는지를 제한한다.
• 웹 서버웹 서버가 파일을 읽는 상황에서 주체는 웹 서버 프로세스, 객체는 파일, 동작은 open/read 등이다.
• DAC와 SELinux파일 모드 0644가 읽기를 허용해도 정책상 해당 프로세스 도메인에서 파일 타입을 읽을 수 없으면 거부된다.
• DAC일반적인 DAC 검사에서 먼저 거절된 요청은 SELinux까지 도달하지 않아 AVC 거부 로그가 없을 수 있다.
• 방화벽과 통제 범위방화벽은 주로 패킷의 주소·프로토콜·연결 상태를 분류하지만 SELinux는 프로세스와 자원 사이의 허용 관계를 다룬다.
• 포트의 객체 타입네트워크 포트도 객체가 될 수 있으므로 네트워크 기능과 관련이 없다는 말도 정확하지 않다.
• 파일 접근·포트 Bind같은 포트에 도착한 요청이 허용되더라도 서비스가 비표준 파일을 읽거나 새로운 포트에 bind하는 행위는 별도 정책 조건을 가진다.
• enforcing·정책enforcing 모드는 정책 위반을 차단하고 기록한다.
• permissivepermissive 모드는 해당 정책 위반을 기록하지만 SELinux가 그 접근을 차단하지 않는다.
• disabled·SELinuxdisabled는 SELinux가 비활성인 상태이며 permissive와 같지 않다.

02컨텍스트의 네 필드와 type enforcement

• 컨텍스트의 네 필드전형적인 security context는 user:role:type:level 형식이다.
• SELinux여기서 SELinux user는 /etc/passwd의 로그인 사용자 이름과 다른 정책상 식별자다.
• rolerole은 도메인 접근의 역할 관계를, level은 MLS/MCS와 관련된 보안 수준·범주를 나타낸다.
• 주체·객체의 타입일반적인 서버 서비스에서 먼저 보는 중심은 프로세스의 domain과 파일의 type이다.

  • 이름에 _t가 붙는 것은 타입 명명 관례다.
  • 예를 들어 httpd_t 프로세스가 httpd_sys_content_t로 표시된 웹 문서를 읽는 관계와, 데이터베이스 전용 파일 타입을 읽으려는 관계는 다르게 취급된다.
• 타입웹 문서를 /var/www에서 /srv/web로 옮기면 Unix 소유권을 그대로 보존했더라도 새 경로의 기본 파일 타입이 적절하지 않을 수 있다.
• 레이블·정책경로 문자열 자체가 모든 권한을 결정하는 것이 아니라 실제 객체의 레이블과 정책 관계가 핵심이다.

ps -eZ
ls -Zd /srv/web
ls -lZ /srv/web
id -Z

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

03현재 레이블과 영구 경로 매핑을 나누어 설정하기

• chcon·컨텍스트chcon은 현재 파일의 컨텍스트를 바꾼다.

  • 그러나 기본 경로 매핑을 바꾸는 것은 아니므로 restorecon이나 전체 재레이블링 뒤 의도한 변경이 사라질 수 있다.
• semanage fcontextsemanage fcontext는 경로 패턴에 어떤 기본 타입을 적용할지 정책 매핑을 추가하고, restorecon은 그 매핑을 실제 파일에 적용한다.

  • 설정 선언과 객체 상태 반영이라는 두 단계다.
• SELinux·정책아래 예시는 RHEL 계열 SELinux 정책에서 /srv/web 이하를 읽기용 웹 콘텐츠로 제공하려는 경우다.

  • (/.*)?는 디렉터리 자체와 하위 경로를 함께 포함한다.
  • 이미 같은 경로 매핑이 있으면 추가 -a 대신 수정 -m이 적합할 수 있다.
• 타입웹 애플리케이션이 쓰는 업로드 디렉터리까지 읽기용 타입 하나로 처리하기보다 필요한 쓰기 범위를 따로 구분한다.
• 최소한의 정책 수정과도한 권한 부여로 경로 오류를 숨기지 않는다.

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/web(/.*)?'
sudo restorecon -Rv /srv/web
matchpathcon /srv/web/index.html
ls -lZ /srv/web/index.html

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

04boolean과 포트 타입은 이미 설계된 정책의 선택점이다

• boolean·정책boolean은 정책에 미리 정의된 조건부 기능을 켜고 끄는 장치다.

  • httpd_can_network_connect처럼 웹 서비스의 외부 연결 허용과 관계된 선택지는 서비스가 실제로 해야 하는 동작과 맞추어 판단한다.
• boolean의 영구 반영setsebool의 현재 변경과 -P를 사용한 영구 변경은 재부팅 후 지속 여부가 다르다.
• boolean이름이 비슷한 boolean을 모두 켜면 최소 접근 범위를 잃게 된다.
• 포트 타입포트 타입 매핑은 특정 TCP/UDP 포트를 어떤 서비스 타입으로 해석할지 연결한다.
• SELinux서비스가 8443 같은 비표준 포트에서 listen할 때 방화벽에서 허용하는 작업과 SELinux가 bind를 허용하는 작업은 다르다.
• 타입semanage port -l은 기존 타입별 목록을 보여 주므로 새 설정을 중복 추가하기 전에 현재 소속을 읽는다.
• 포트 번호 변경포트 번호 변경은 프로세스의 실제 listen 설정도 별도로 바꾸어야 한다.

getsebool httpd_can_network_connect
sudo semanage port -l
# 포트 목록의 프로토콜과 타입을 애플리케이션 설정과 비교한다.

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

05AVC 한 줄을 정책의 문장으로 읽기

• scontext거부 기록에서 scontext는 요청한 주체, tcontext는 대상 객체, tclass는 객체 종류, 중괄호 안의 권한은 거절된 동작을 나타낸다.

  • 예를 들어 scontext의 httpd_t, tcontext의 user_home_t, tclass=file, denied { read }가 함께 있으면 웹 서비스가 사용자 홈 타입 파일을 읽으려 했다는 문장으로 바꿀 수 있다.
• SELinux단순히 SELinux error라는 라벨만 붙이면 어느 접근 관계가 잘못됐는지 드러나지 않는다.
• Enforcing·PermissiveEnforcing은 정책을 적용하여 거부하고 기록하며 Permissive는 정책상 거부를 관찰하되 차단하지 않는다.
• 정책·permissiveDisabled는 정책을 사용하지 않는 상태여서 permissive와도 다르다.
• 레이블원인을 설명할 때는 잘못된 파일 위치·레이블·서비스 설정을 먼저 교정하고, 정책이 의도적으로 금지한 동작인지 구분한다.
• audit2allow의 한계audit2allow 결과를 무조건 적용하면 공격 시도까지 정상 권한으로 추가할 수 있으므로 기존 정책 의미를 대신하는 자동 승인 도구로 사용하지 않는다.

getenforce
sestatus
sudo ausearch -m AVC,USER_AVC -ts recent
# scontext / tcontext / tclass / denied permission을 함께 읽는다.

교육용 설정·명령 예시. 실행 환경과 대상 경로를 가정하며 이 페이지를 만들면서 실행하지 않았다.

09예외를 만들기 전에

• 접근 필요성 판단서비스가 실제로 그 접근을 필요로 하는지 먼저 판단한다.
• 정책·SELinux거부 로그 전체를 자동으로 허용 정책으로 바꾸거나 SELinux를 영구 해제하면 잘못된 애플리케이션 동작까지 허용할 수 있다.
• 변경 후 재현변경 후에는 필요한 접근이 성공하고 불필요한 접근은 여전히 제한되는지 확인한다.

getenforce
sestatus
ls -Zd .

SELinux 모드와 현재 디렉터리의 컨텍스트를 조회한다. 설치·활성화 상태에 따라 도구가 없을 수 있다.

10웹 서버의 파일 읽기를 정책에 대입하기

• 타입·정책웹 서버 프로세스가 문서 파일을 읽는 상황에서는 프로세스의 도메인과 파일의 타입, 요청한 읽기 동작이 정책 판단의 핵심이다.
• 도메인·타입 허용 관계파일 소유권과 모드가 읽기를 허용해도 해당 도메인이 대상 타입을 읽도록 허용되지 않았다면 enforcing 환경에서 접근이 거부될 수 있다.
• 이동·복사 후 레이블경로를 옮기거나 다른 곳에서 파일을 복사하면서 기대와 다른 타입이 붙는 경우가 대표적인 진단 대상이다.

  • 실제 타입 이름과 기본 경로 규칙은 배포판 정책에서 확인한다.
• AVC·scontextAVC 기록에서 scontext는 요청 주체의 컨텍스트, tcontext는 대상의 컨텍스트를 나타내고 tclass와 요청 권한은 대상 종류와 수행 동작을 해석하는 단서다.
• 동작별 허용 조건같은 파일에 대한 read와 write는 별도 허용 조건일 수 있다.
• 거부된 동작거부된 동작을 그대로 모두 허용하기 전에 그 접근이 서비스 설계에 필요한지 판단한다.
• 정책설정 경로가 잘못되어 비밀 파일에 접근한 경우에는 정책 완화보다 애플리케이션 경로 수정이 올바른 해결이 될 수 있다.

1. 파일 읽기 요청httpd_t 도메인의 웹 서버 프로세스가 웹 문서를 열고 읽으려 한다. 접근 요청에는 주체의 컨텍스트, 대상 파일의 컨텍스트와 동작이 관계한다.
2. 기본 접근 조건 검사경로 탐색과 파일 모드·ACL 등 DAC 조건이 충족돼야 한다. DAC에서 거부된 요청을 SELinux의 허용 규칙이 대신 허용해 주지는 않는다.
3. 타입과 동작의 정책 평가SELinux는 주체 타입과 대상 타입, 객체 클래스, 요청 권한의 관계를 정책에 대입한다. 같은 파일이라도 read와 write는 다른 허용 조건을 가질 수 있다.
4. 모드에 따른 결과 반영enforcing에서 정책이 허용하지 않으면 접근을 거부한다. permissive에서는 SELinux의 거부 판단을 기록하되 그 판단만으로 접근을 막지는 않는다.
5. 읽기 결과 또는 거부 반환필요한 접근 검사를 통과하면 읽기가 진행된다. 거부는 애플리케이션의 접근 오류로 나타나며 AVC 기록을 남길 수 있지만 로깅·억제 규칙에 따라 기록 여부는 달라질 수 있다.

11거부를 재현하고 수정 범위를 좁히기

• 실행 도메인 차이같은 계정의 터미널 테스트와 서비스 요청은 서로 다른 도메인에서 실행될 수 있다.
• 정책터미널에서 파일을 읽었다는 사실만으로 서비스의 정책 문제를 배제하지 않는다.
• AVCAVC 로그가 보이지 않을 때도 감사 설정, 로그 보존, 기록 제한과 일반 권한 단계의 실패를 고려해야 한다.
• permissivepermissive에서 문제가 사라졌다는 관찰은 유력한 단서지만, 어떤 규칙을 어떻게 바꿀지까지 자동으로 결정해 주지는 않는다.
• 레이블표준 경로라면 기대되는 레이블과 실제 레이블을 비교하고, 사용자 정의 경로라면 필요한 영구 파일 컨텍스트 매핑과 복구 절차를 검토한다.
• chcon·정책chcon으로 붙인 값과 정책의 기본 매핑은 서로 다른 관리 상태다.
• 타입파일 타입이 맞아도 비표준 포트나 특정 네트워크 접근 기능 때문에 정책 조정이 필요할 수 있다.
• 최소 범위 수정 검증변경 뒤에는 필요한 한 동작의 성공뿐 아니라 읽기와 쓰기, 인접 경로의 접근 범위가 의도대로 유지되는지 확인한다.