帮助中心

적용 환경과 지원 상태

SELinux 차단 원인을 확인하는 순서

1. SELinux가 실제로 Enforcing 상태인지 확인합니다.
2. 일반 Linux 파일 권한과 소유권이 정상인지 먼저 확인합니다.
3. ausearch로 같은 시각의 AVC 거부 로그를 찾습니다.
4. 로그의 scontext, tcontext, tclass, 거부된 동작을 확인합니다.
5. 파일 컨텍스트, SELinux Boolean, 허용 포트 타입을 순서대로 점검합니다.
6. 기존 정책 설정으로 해결되지 않는 경우에만 사용자 정의 정책 필요성을 검토합니다.
7. 수정 후 서비스를 다시 실행하고 새 AVC 로그가 발생하지 않는지 확인합니다.

SELinux 상태 확인

먼저 현재 SELinux가 어떤 상태로 동작 중인지 확인합니다.

getenforce
sestatus

getenforce는 일반적으로 다음 세 상태 중 하나를 표시합니다.

• Enforcing: SELinux 정책을 실제로 적용하여 허용되지 않은 접근을 차단합니다.
• Permissive: 차단은 하지 않지만 정책 위반을 로그에 기록합니다.
• Disabled: SELinux 정책이 로드되지 않습니다.

현재 상태가 Enforcing이고 특정 서비스 동작 시점에 AVC 거부가 함께 기록된다면 SELinux 차단 여부를 구체적으로 분석할 수 있습니다.

일반 Linux 권한을 먼저 확인

SELinux 정책은 일반적인 파일 소유권과 권한 검사 이후에 적용됩니다. 따라서 파일 권한 자체가 잘못되어 접근이 거부되는 경우에는 AVC 로그가 없을 수 있습니다.

예를 들어 서비스가 /srv/myapp/data에 접근하지 못한다면 다음과 같이 경로 전체의 권한과 SELinux 컨텍스트를 함께 확인합니다.

namei -l /srv/myapp/data
ls -ld /srv/myapp /srv/myapp/data
ls -ldZ /srv/myapp /srv/myapp/data

서비스 실행 사용자를 확인한 뒤 해당 계정이 경로에 필요한 읽기·쓰기·실행 권한을 갖는지도 확인합니다.

systemctl show name.service -p User -p Group -p ExecStart
ps -eZ | grep PROCESS_NAME

위의 name.service와 PROCESS_NAME은 실제 서비스명과 프로세스명으로 변경하십시오. 일반 권한이 잘못되어 있다면 SELinux 설정을 변경하기 전에 소유권과 최소 권한부터 올바르게 수정해야 합니다.

AVC 거부 로그 확인

CentOS 7에서 auditd가 실행 중이면 SELinux AVC 거부는 일반적으로 /var/log/audit/audit.log에 기록됩니다. 먼저 audit 서비스 상태를 확인합니다.

systemctl is-active auditd.service
systemctl status auditd.service --no-pager

최근 AVC 거부를 검색합니다.

sudo ausearch -m AVC,USER_AVC -ts recent

오늘 발생한 거부 전체를 확인하려면 다음 명령을 사용할 수 있습니다.

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today

특정 서비스 문제를 재현하면서 확인하려면 먼저 현재 시각을 기록하고 서비스를 다시 실행한 뒤 최근 AVC만 조회하는 것이 좋습니다.

date
sudo systemctl restart name.service
sudo ausearch -m AVC,USER_AVC -ts recent

서비스 자체의 실패 로그도 같은 시각 기준으로 함께 확인합니다.

sudo systemctl status name.service -l --no-pager
sudo journalctl -u name.service -b -n 100 --no-pager

AVC 로그에서 확인해야 할 항목

AVC 로그에는 차단된 동작과 출발·대상 SELinux 컨텍스트가 기록됩니다. 실제 값은 서비스마다 다르지만 다음 항목을 중심으로 읽으면 원인을 좁힐 수 있습니다.

예를 들어 웹 서버 프로세스 도메인은 정상인데 대상 파일이 default_t처럼 서비스가 접근할 수 없는 타입으로 표시된다면 파일 컨텍스트 문제부터 확인해야 합니다. 반대로 name_bind가 거부되면서 비표준 포트가 표시된다면 SELinux 포트 타입 문제일 가능성이 큽니다.

파일 컨텍스트가 잘못되었는지 확인

파일을 다른 위치에서 이동하거나 백업에서 복원했을 때 경로에 맞지 않는 SELinux 타입이 유지되어 서비스 접근이 차단되는 경우가 많습니다. 대상 경로의 현재 컨텍스트를 확인합니다.

ls -ldZ /path/to/resource
ls -lZ /path/to/resource

정책이 해당 경로에 기대하는 기본 컨텍스트와 비교합니다.

matchpathcon /path/to/resource

기본 정책에 이미 올바른 컨텍스트 규칙이 존재하지만 실제 라벨만 틀린 경우에는 restorecon으로 복원합니다.

sudo restorecon -Rv /path/to/resource

비표준 경로를 서비스가 사용해야 하는 경우

서비스 데이터를 정책의 기본 위치가 아닌 별도 디렉터리에 저장한다면 chcon으로 일시 변경하기보다 semanage fcontext에 영구 규칙을 추가하고 restorecon으로 적용하는 방식이 적절합니다.

예를 들어 Apache가 /srv/myweb의 정적 콘텐츠를 읽어야 하는 환경이라면 Red Hat 문서의 방식처럼 다음과 같이 경로 규칙을 등록할 수 있습니다.

sudo semanage fcontext -a -t httpd_sys_content_t "/srv/myweb(/.*)?"
sudo restorecon -Rv /srv/myweb

SELinux Boolean이 필요한 동작인지 확인

SELinux Boolean은 정책 전체를 새로 작성하지 않고 서비스가 특정 기능을 사용할 수 있도록 준비된 정책 스위치입니다. 먼저 관련 Boolean을 검색합니다.

getsebool -a | grep -i SERVICE_KEYWORD
sudo semanage boolean -l | grep -i SERVICE_KEYWORD

예를 들어 Apache 애플리케이션이 외부 또는 로컬 데이터베이스에 네트워크 연결을 해야 하는 경우 정책에 준비된 httpd_can_network_connect_db Boolean을 확인할 수 있습니다.

getsebool httpd_can_network_connect_db

실제 서비스 요구사항과 일치하는 Boolean임을 확인한 뒤 영구적으로 활성화해야 한다면 -P 옵션을 사용합니다.

sudo setsebool -P httpd_can_network_connect_db on
getsebool httpd_can_network_connect_db

-P는 재부팅 후에도 설정을 유지합니다. 문제를 해결하기 위해 관련 없는 Boolean을 여러 개 켜지 말고 필요한 기능에 해당하는 항목만 활성화하십시오.

서비스가 비표준 포트를 사용할 때 SELinux 포트 타입 확인

서비스 설정에서 기본 포트가 아닌 다른 포트로 변경한 뒤 서비스 시작이 실패한다면 SELinux 정책이 해당 포트에서의 바인딩을 허용하는지 확인해야 합니다.

Apache의 허용 포트 타입을 예로 확인하면 다음과 같습니다.

sudo semanage port -l | grep -w http_port_t

AVC 로그에 name_bind 거부가 기록되고 실제 서비스가 예를 들어 TCP 12345 포트를 사용해야 하며, 그 포트가 다른 SELinux 포트 타입에 이미 할당되어 있지 않은 경우 다음과 같이 추가할 수 있습니다.

sudo semanage port -a -t http_port_t -p tcp 12345
sudo semanage port -l | grep -w http_port_t

sealert로 SELinux 거부 내용을 읽기 쉽게 분석

CentOS 7에서는 setroubleshoot-server 패키지의 sealert를 사용하면 audit 로그를 사람이 읽기 쉬운 형태로 분석할 수 있습니다.

rpm -q setroubleshoot-server

패키지가 설치되어 있다면 audit 로그 전체를 분석합니다.

sudo sealert -a /var/log/audit/audit.log

설치되어 있지 않고 패키지를 설치할 수 있는 저장소가 구성되어 있다면 다음과 같이 설치할 수 있습니다.

sudo yum install -y setroubleshoot-server

분석 결과가 제안하는 명령을 그대로 실행하기보다 먼저 파일 컨텍스트, Boolean, 포트 설정과 서비스의 실제 요구사항이 맞는지 검토하십시오.

audit2allow는 마지막 단계에서 검토

audit2allow는 AVC 거부 로그에서 SELinux 허용 규칙을 생성할 수 있는 도구입니다. 하지만 Red Hat 문서는 SELinux 거부가 발생했다고 해서 처음부터 audit2allow로 사용자 정의 정책을 만드는 방식을 권장하지 않습니다.

먼저 다음 항목이 모두 정상인지 확인해야 합니다.

1. 일반 파일 권한과 소유권
2. 대상 파일과 디렉터리의 올바른 SELinux 컨텍스트
3. 서비스 용도에 맞는 SELinux Boolean
4. 서비스가 사용하는 포트의 올바른 SELinux 포트 타입
5. 서비스 자체의 잘못된 경로나 비정상적인 동작 여부

정책이 정말 부족한 것으로 판단되면 먼저 거부 이유를 읽기 쉬운 형태로 분석할 수 있습니다.

sudo ausearch -m AVC,USER_AVC -ts recent | audit2why

수정 후 정상 작동 확인

컨텍스트, Boolean 또는 포트 타입을 수정한 뒤 서비스를 다시 실행합니다.

sudo systemctl restart name.service
sudo systemctl status name.service -l --no-pager
sudo systemctl is-active name.service

서비스를 실제로 사용해 문제가 발생했던 동작을 다시 수행한 뒤 새로운 AVC 거부가 발생했는지 확인합니다.

sudo ausearch -m AVC,USER_AVC -ts recent

네트워크 서비스라면 실제 수신 포트와 기능도 확인합니다.

sudo ss -lntup

서비스가 active이고 실제 기능이 정상이며 같은 작업을 반복했을 때 새로운 AVC 거부가 기록되지 않는지 확인해야 문제 해결 여부를 판단할 수 있습니다.

증상별 SELinux 점검표

원상복구 방법

추가한 Boolean 되돌리기

예시로 활성화한 Boolean을 다시 끄려면 다음과 같이 실행합니다.

sudo setsebool -P httpd_can_network_connect_db off
getsebool httpd_can_network_connect_db

추가한 포트 타입 제거

이 문서의 예시처럼 직접 추가한 포트 매핑을 더 이상 사용하지 않는다면 제거할 수 있습니다.

sudo semanage port -d -t http_port_t -p tcp 12345

추가한 파일 컨텍스트 규칙 제거

직접 추가한 /srv/myweb 규칙을 제거하려면 같은 패턴으로 삭제한 뒤 현재 정책의 기본 컨텍스트를 다시 적용합니다.

sudo semanage fcontext -d "/srv/myweb(/.*)?"
sudo restorecon -Rv /srv/myweb

관련 지구 IDC 기술자료

• CentOS 7에서 systemd 서비스가 시작되지 않을 때 원인을 확인하는 방법
• CentOS 7에서 Cron 작업이 실행되지 않을 때 원인을 확인하는 방법

공식 참고자료

자주 묻는 질문

setenforce 0으로 문제가 사라지면 SELinux가 원인이라고 보면 되나요?

SELinux 정책과 관련된 문제일 가능성은 높아지지만 그것만으로 해결 방법이 결정되지는 않습니다. Permissive 상태에서 기록된 AVC를 확인해 잘못된 파일 컨텍스트인지, Boolean이나 포트 타입이 필요한지, 실제 정책이 부족한지 구분해야 합니다.

chmod 777을 하면 SELinux 차단도 해결되나요?

아닙니다. 일반 Linux 권한과 SELinux는 별도의 접근 제어 계층입니다. 파일 권한을 777로 넓혀도 SELinux 정책이 허용하지 않으면 접근은 계속 차단될 수 있으며 보안만 약해질 수 있습니다.

chcon과 semanage fcontext의 차이는 무엇인가요?

chcon은 파일의 현재 컨텍스트를 직접 변경하지만 정책의 기본 파일 컨텍스트 규칙을 바꾸지는 않습니다. 비표준 경로를 서비스가 지속적으로 사용해야 하는 경우에는 semanage fcontext로 영구 규칙을 등록하고 restorecon으로 적용하는 방식이 적절합니다.

AVC 로그가 없으면 SELinux 문제는 아닌가요?

반드시 그렇지는 않지만 먼저 일반 Linux 권한이 접근을 거부했는지와 auditd가 정상적으로 로그를 기록하는지 확인해야 합니다. 일반 권한이 먼저 거부하면 SELinux 정책까지 도달하지 않아 AVC가 남지 않을 수 있습니다.

audit2allow가 출력한 명령을 바로 실행해도 되나요?

권장하지 않습니다. Red Hat 문서도 라벨 문제와 기존 정책 설정을 먼저 점검하도록 안내합니다. 생성된 정책이 어떤 접근을 허용하는지 이해하지 않고 설치하면 서비스에 불필요하게 넓은 권한을 부여할 수 있습니다.