기술자료

적용 환경

SELinux와 Audit 데몬 상태 확인

1. CentOS Stream 버전 확인

먼저 현재 시스템이 CentOS Stream 9인지 확인합니다.

cat /etc/centos-release

출력에 CentOS Stream release 9가 포함되어 있으면 이 문서의 적용 환경과 일치합니다.

2. SELinux 모드 확인

getenforce는 현재 SELinux 모드를 간단히 표시하며, sestatus는 활성 상태와 정책 유형 등 상세 정보를 보여줍니다.

getenforce
sestatus

• Enforcing: 정책을 적용하고 허용되지 않은 접근을 차단하며 로그를 남깁니다.
• Permissive: 차단하지는 않지만 정책 위반에 해당하는 AVC 로그를 남깁니다.
• Disabled: SELinux가 비활성화되어 있으므로 SELinux 차단 로그가 생성되지 않습니다.

3. auditd 상태와 분석 도구 확인

SELinux 거부 기록은 일반적으로 auditd가 관리하는 /var/log/audit/audit.log에 저장됩니다. 먼저 Audit 데몬이 실행 중인지 확인합니다.

sudo systemctl is-active auditd
sudo systemctl status auditd --no-pager

active가 표시되면 Audit 로그를 조회할 수 있습니다. 필요한 명령어가 없거나 Audit 패키지가 제거된 환경에서는 다음 패키지를 설치합니다.

sudo dnf install -y audit policycoreutils-python-utils setroubleshoot-server

Audit 데몬이 비활성 상태라면 시작한 뒤 문제가 발생했던 작업을 다시 실행하여 새 로그를 생성합니다.

sudo systemctl enable auditd
sudo service auditd start

ausearch로 SELinux 차단 로그 조회

ausearch는 Audit 이벤트를 유형, 시간, 프로세스, 실행 파일, 경로 등의 조건으로 검색합니다. SELinux 차단 여부를 확인할 때는 AVC 관련 메시지 유형을 지정하는 방법이 가장 정확합니다.

최근 10분 동안 발생한 차단 로그 확인

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i

-ts recent는 최근 10분을 의미하며, -i는 숫자로 기록된 사용자 ID와 시스템 호출 등의 값을 가능한 범위에서 읽기 쉬운 형태로 변환합니다.

오늘 또는 현재 부팅 이후의 로그 확인

문제 발생 시각이 정확하지 않다면 오늘 생성된 로그나 현재 부팅 이후의 로그로 범위를 넓힙니다.

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts today -i
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts boot -i

특정 프로세스나 파일 경로로 필터링

로그가 많을 때는 서비스 프로세스 이름이나 문제가 발생한 파일 경로를 지정합니다. 아래의 httpd와 /srv/example은 예시이므로 실제 서비스와 경로에 맞게 변경해야 합니다.

sudo ausearch -m AVC,USER_AVC -c httpd -ts today -i
sudo ausearch -m AVC,USER_AVC -f /srv/example -ts today -i

원본 Audit 로그 직접 확인

원본 기록이 필요한 경우 Audit 로그 파일을 직접 열 수 있습니다. 하나의 이벤트가 여러 레코드로 구성될 수 있으므로 원인 분석에는 단순 grep보다 ausearch를 우선 사용하는 것이 좋습니다.

sudo less /var/log/audit/audit.log
sudo grep -i 'avc: *denied' /var/log/audit/audit.log

AVC 로그의 주요 항목 해석

SELinux AVC 메시지는 어떤 프로세스가 어떤 대상에 어떤 권한을 요청했고, 어떤 보안 컨텍스트 조합 때문에 거부되었는지를 기록합니다. 출력 형식은 이벤트에 따라 달라질 수 있지만 다음 항목을 우선 확인하면 원인을 좁힐 수 있습니다.

sealert와 audit2why로 원인 분석

sealert로 저장된 거부 이벤트 분석

setroubleshoot-server 패키지의 sealert는 저장된 SELinux 거부 기록을 사람이 읽기 쉬운 설명과 제안 형태로 보여줍니다.

sudo sealert -l "*"

시스템 로그에 sealert -l UUID 형태의 안내가 표시되었다면 별표 대신 해당 UUID를 입력하여 특정 이벤트만 분석할 수 있습니다.

audit2why로 거부 이유 확인

최근 AVC 이벤트를 원시 형식으로 전달하면 audit2why가 현재 정책 기준에서 거부된 이유를 분석합니다.

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

차단 로그가 보이지 않을 때 점검

1. setroubleshoot Journal 확인

auditd가 실행 중이지만 ausearch 결과가 없으면 setroubleshoot가 기록한 systemd Journal을 확인합니다.

sudo journalctl -t setroubleshoot --since today

2. Audit 데몬이 없을 때 커널 메시지 확인

SELinux는 활성 상태지만 Audit 데몬이 실행되지 않는 환경이라면 커널 메시지에서 관련 레코드 유형을 검색합니다.

sudo dmesg | grep -i -e 'type=1300' -e 'type=1400'

3. dontaudit 규칙에 숨겨진 거부 이벤트 확인

일부 거부는 정책의 dontaudit 규칙 때문에 기록되지 않을 수 있습니다. 진단이 꼭 필요한 경우에만 해당 규칙을 잠시 비활성화하고 문제를 재현합니다.

sudo semodule -DB
sudo ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent -i
sudo semodule -B

4. SELinux가 실제 원인인지 임시로 구분

점검 창구가 확보된 상황에서만 SELinux를 일시적으로 permissive 모드로 전환하고 동일한 작업을 재현할 수 있습니다. permissive 상태에서도 문제가 그대로 발생한다면 SELinux가 아닌 일반 파일 권한, 서비스 설정, 방화벽 또는 애플리케이션 문제일 가능성이 높습니다.

sudo setenforce 0
getenforce

# 문제가 발생했던 작업을 다시 실행한 뒤 로그를 확인합니다.

sudo setenforce 1
getenforce

로그 확인 후 안전하게 조치하는 순서

SELinux 로그를 찾은 뒤에는 다음 순서로 원인을 확인하는 것이 안전합니다.

1. 일반 Linux 권한 확인: 소유자, 그룹, 파일 모드, 상위 디렉터리 실행 권한이 올바른지 먼저 확인합니다.
2. SELinux 레이블 확인: 파일이나 디렉터리를 이동·복사한 뒤 잘못된 유형이 적용되지 않았는지 ls -lZ로 확인합니다.
3. 비표준 경로·포트 확인: 서비스의 데이터 경로나 수신 포트를 기본값과 다르게 사용했다면 적절한 파일 컨텍스트나 포트 유형을 등록해야 할 수 있습니다.
4. SELinux Boolean 확인: 정책이 제공하는 기능 전환 항목으로 해결할 수 있는지 서비스별 SELinux 도움말과 Boolean을 확인합니다.
5. 사용자 정의 정책은 마지막에 검토: 기존 정책 설정으로 해결할 수 없고 해당 접근이 보안상 반드시 필요한 경우에만 최소 권한 원칙으로 검토합니다.

대상 파일과 현재 SELinux 컨텍스트를 확인하려면 다음 명령어를 사용할 수 있습니다. /srv/example은 실제 경로로 변경합니다.

ls -ldZ /srv/example
matchpathcon -V /srv/example

matchpathcon -V가 현재 레이블과 정책상 기본 레이블의 불일치를 보고한다면, 경로가 원래 정책에 정의된 위치인지 검토한 뒤 restorecon 적용 여부를 판단합니다. 임의로 레이블을 변경하기 전에 서비스의 공식 SELinux 매뉴얼을 확인하십시오.

자주 발생하는 오류와 해결 방법

관련 VISION IDC 기술자료

• CentOS 포트 변경 방법 — SSH 포트를 변경할 때 SELinux 포트 유형 설정이 필요한 사례를 함께 확인할 수 있습니다.
• VISION IDC 기술자료 전체 보기

공식 참고자료

• Red Hat Enterprise Linux 9 문서: Troubleshooting problems related to SELinux — Audit 로그 위치, AVC 조회, sealert 분석, dontaudit 점검 절차 확인
• CentOS Project: CentOS Stream 9 — CentOS Stream 9 지원 상태와 일정 확인
• Linux Audit 프로젝트 매뉴얼: ausearch(8) — 검색 조건, 시간 범위, 해석 옵션 확인

공식 자료 조회일: 2026년 7월 15일

자주 묻는 질문

SELinux 차단 로그는 항상 /var/log/audit/audit.log에 남나요?

auditd가 정상 실행 중이면 일반적으로 해당 파일에 기록됩니다. auditd가 실행되지 않거나 setroubleshoot만 기록한 경우에는 systemd Journal 또는 커널 메시지를 추가로 확인해야 합니다.

ausearch에서 <no matches>가 나오면 SELinux 문제가 아닌가요?

반드시 그렇지는 않습니다. 검색 시간 범위가 너무 짧거나 auditd가 비활성 상태일 수 있고, 일부 이벤트는 dontaudit 규칙으로 숨겨질 수 있습니다. 상태와 시간 범위를 확인한 뒤 동일한 문제를 다시 재현해야 합니다.

문제를 해결하려면 SELinux를 disabled로 바꿔도 되나요?

권장하지 않습니다. SELinux 비활성화는 보호 계층 전체를 제거하며 근본 원인을 해결하지 못합니다. 파일 레이블, 비표준 경로와 포트, Boolean, 일반 권한을 순서대로 확인하는 것이 안전합니다.

permissive 모드에서 생성된 AVC 로그도 분석할 수 있나요?

가능합니다. permissive 모드는 접근을 실제로 차단하지 않지만 정책 위반에 해당하는 AVC 이벤트를 기록합니다. 로그의 permissive=1 값을 통해 기록 전용 이벤트인지 구분할 수 있습니다.