이 랩에서는 RHEL 에서 SELinux 보안을 관리하는 실습 경험을 얻게 됩니다. SELinux 시행 모드를 임시적으로, 그리고 영구적으로 변경하는 방법을 배우고, 사용자 정의 SELinux 파일 컨텍스트를 사용하여 Apache 를 구성하는 방법을 익힐 것입니다. 또한, 이 랩에서는 부울 (booleans) 을 사용하여 사용자 홈 디렉토리에 대한 SELinux 정책을 조정하는 방법과 Apache 웹 서버 및 사용자 정의 웹 콘텐츠에 대한 SELinux 거부 문제를 해결하고 해결하기 위한 실질적인 단계를 다룹니다.
이 단계에서는 SELinux 모드를 임시적으로, 그리고 영구적으로 관리하는 방법을 배우게 됩니다. SELinux (Security-Enhanced Linux) 는 Linux 커널에 대한 MAC (Mandatory Access Control, 강제 접근 제어) 을 제공하는 보안 메커니즘입니다. 이는 프로세스, 파일 및 기타 시스템 리소스에 대한 접근 권한을 정의합니다.
SELinux 는 세 가지 주요 모드로 작동합니다.
명령줄 도구를 사용하고 구성 파일을 수정하여 SELinux 모드를 변경하는 연습을 할 것입니다.
먼저, 현재 SELinux 시행 모드를 확인해 보겠습니다.
현재 SELinux 시행 모드 확인.
getenforce 명령을 사용하여 현재 SELinux 모드를 빠르게 확인할 수 있습니다.
getenforce출력으로 Enforcing이 표시되어 SELinux 가 현재 정책을 시행하고 있음을 나타냅니다.
EnforcingSELinux 모드를 임시적으로 permissive로 변경.
setenforce 명령을 사용하면 런타임에 SELinux 모드를 변경할 수 있습니다. 값 0은 모드를 permissive로 설정하고, 1은 enforcing으로 설정합니다. 이 변경은 임시적이며 재부팅 시 유지되지 않습니다.
sudo setenforce 0이제 getenforce를 다시 사용하여 변경 사항을 확인합니다.
getenforce출력은 이제 Permissive여야 합니다.
PermissiveSELinux 모드를 임시적으로 다시 enforcing으로 변경.
임시 변경을 되돌리려면 setenforce 1을 사용합니다.
sudo setenforce 1모드를 다시 한 번 확인합니다.
getenforce출력은 다시 Enforcing이어야 합니다.
Enforcing기본 SELinux 모드를 영구적으로 permissive로 변경.
재부팅 후에도 SELinux 모드 변경 사항을 유지하려면 /etc/selinux/config 파일을 수정해야 합니다. 이 파일은 시스템의 기본 SELinux 모드를 정의합니다.
nano를 사용하여 구성 파일을 엽니다.
sudo nano /etc/selinux/confignano 편집기 내에서 SELINUX=로 시작하는 줄을 찾아 해당 값을 enforcing에서 permissive로 변경합니다.
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
## enforcing - SELinux security policy is enforced.
## permissive - SELinux prints warnings instead of enforcing.
## disabled - No SELinux policy is loaded.
SELINUX=permissive
## SELINUXTYPE= can take one of these three values:
## targeted - Targeted processes are protected,
## for the majority of users.
## minimum - Modification of targeted policy
## uses current settings and adds to it.
## mls - Multi Level Security protection.
SELINUXTYPE=targetedCtrl+X를 눌러 종료하고, Y를 눌러 저장을 확인하고, Enter를 눌러 동일한 파일에 씁니다.
파일을 저장한 후 grep을 사용하여 구성 파일에서 변경 사항을 확인할 수 있습니다.
grep '^SELINUX' /etc/selinux/config출력은 SELINUX=permissive를 표시해야 합니다.
SELINUX=permissive
SELINUXTYPE=targeted중요 사항: /etc/selinux/config를 변경해도 활성 SELinux 모드가 즉시 변경되지는 않습니다. 다음 시스템 재부팅 후에 적용될 모드만 설정합니다. 현재 활성 모드를 확인하려면 여전히 getenforce를 사용해야 합니다.
getenforce시스템이 아직 재부팅되지 않았으므로 여전히 Enforcing이 표시되어야 합니다.
Enforcing구성 파일에서 기본 SELinux 모드를 다시 enforcing으로 변경.
이제 영구 모드를 다시 enforcing으로 변경해 보겠습니다. 이것은 SELinux 에 권장되는 가장 안전한 설정입니다.
구성 파일을 다시 엽니다.
sudo nano /etc/selinux/configSELINUX= 매개변수를 다시 enforcing으로 변경합니다.
## This file controls the state of SELinux on the system.
## SELINUX= can take one of these three values:
## enforcing - SELinux security policy is enforced.
## permissive - SELinux prints warnings instead of enforcing.
## disabled - No SELinux policy is loaded.
SELINUX=enforcing
## SELINUXTYPE= can take one of these three values:
## targeted - Targeted processes are protected,
## for the majority of users.
## minimum - Modification of targeted policy
## uses current settings and adds to it.
## mls - Multi Level Security protection.
SELINUXTYPE=targeted파일을 저장하고 종료합니다 (Ctrl+X, Y, Enter).
구성 파일에서 변경 사항을 확인합니다.
grep '^SELINUX' /etc/selinux/config출력은 이제 SELINUX=enforcing을 표시해야 합니다.
SELINUX=enforcing
SELINUXTYPE=targeted이 시점에서 시스템의 활성 SELinux 모드는 여전히 Enforcing이며 (4 단계 후에 재부팅하지 않은 경우), 영구 설정도 Enforcing입니다.
이 단계에서는 비표준 디렉토리에서 웹 콘텐츠를 제공하고 SELinux 파일 컨텍스트를 관리하도록 Apache 를 구성하는 방법을 배우게 됩니다. 기본적으로 SELinux 정책은 Apache (httpd) 가 특정 디렉토리, 주로 /var/www/html에서만 파일을 제공하도록 제한합니다. 웹 콘텐츠를 다른 위치에 배치하면 파일 시스템 권한이 올바르더라도 SELinux 가 Apache 가 해당 콘텐츠에 접근하는 것을 방지합니다. 여기서 SELinux 파일 컨텍스트가 작용합니다.
SELinux 파일 컨텍스트는 파일 또는 디렉토리에 적용되어 해당 보안 속성을 정의하는 레이블입니다. Apache 가 사용자 정의 위치에서 콘텐츠를 제공하려면 해당 위치와 해당 콘텐츠에 올바른 SELinux 컨텍스트, 일반적으로 httpd_sys_content_t가 있어야 합니다. semanage fcontext를 사용하여 영구 규칙을 정의하고 restorecon을 사용하여 적용합니다.
먼저, Apache HTTP 서버를 설치해야 합니다.
Apache HTTP 서버 설치.
dnf 패키지 관리자를 사용하여 httpd 패키지를 설치합니다.
sudo dnf install -y httpdhttpd 패키지 및 해당 종속성의 성공적인 설치를 나타내는 출력이 표시되어야 합니다.
웹 콘텐츠용 사용자 정의 디렉토리와 index.html 파일 생성.
/custom이라는 새 디렉토리를 만들고 그 안에 간단한 index.html 파일을 배치합니다. 이것이 비표준 웹 문서 루트가 됩니다.
sudo mkdir /custom
echo 'This is custom web content.' | sudo tee /custom/index.htmlindex.html 파일의 내용을 확인합니다.
cat /custom/index.htmlThis is custom web content.새 문서 루트를 사용하도록 Apache 구성.
Apache 의 주요 구성 파일은 /etc/httpd/conf/httpd.conf입니다. Apache 가 기본 /var/www/html 대신 새 /custom 디렉토리를 가리키도록 이 파일을 편집해야 합니다.
nano를 사용하여 구성 파일을 엽니다.
sudo nano /etc/httpd/conf/httpd.conf편집기 내에서 DocumentRoot "/var/www/html" 및 <Directory "/var/www/html"> 줄을 찾습니다. /var/www/html의 두 항목을 모두 /custom으로 변경합니다.
수정 후 관련 섹션은 다음과 같이 표시되어야 합니다.
#
## DocumentRoot: The directory out of which you will serve your
## documents. By default, all requests are taken from this directory, but
## symbolic links and aliases may be used to point to other locations.
#
DocumentRoot "/custom"
#
## Relax access to content within /var/www.
#
<Directory "/custom">
AllowOverride None
## Allow open access:
Require all granted
</Directory>파일을 저장하고 종료합니다 (Ctrl+X, Y, Enter).
Apache 웹 서비스를 시작하고 활성화합니다.
구성을 수정한 후 httpd 서비스를 시작해야 합니다. 컨테이너 환경에 있으므로 systemctl을 사용할 수 없습니다. httpd를 직접 시작합니다.
sudo /usr/sbin/httpd -DFOREGROUND && 기호는 명령을 백그라운드에서 실행하여 터미널을 계속 사용할 수 있도록 합니다. Apache 가 시작됨을 나타내는 다음과 유사한 출력이 표시되어야 합니다.
[1] 5094
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80::216:3eff:fe00:63b%eth0. Set the 'ServerName' directive globally to suppress this message참고: 서버의 정규화된 도메인 이름에 대한 경고 메시지는 이 랩 환경에서 정상이며 안전하게 무시할 수 있습니다.
Apache 가 실행 중인지 확인하려면 httpd 프로세스를 확인하면 됩니다.
ps aux | grep httpd여러 httpd 프로세스가 실행 중인 것을 볼 수 있습니다.
root ... /usr/sbin/httpd -DFOREGROUND
apache ... /usr/sbin/httpd -DFOREGROUND
...output omitted...웹 페이지에 접근을 시도합니다.
이제 curl을 사용하여 웹 페이지에 접근해 봅니다. 동일한 시스템에 있으므로 localhost를 사용할 수 있습니다.
curl http://localhost/index.html참고: 이 특정 환경에서는 root_t 컨텍스트로도 웹 페이지에 접근할 수 있음을 알 수 있습니다. 이는 SELinux 가 시행 중이지만 root_t 컨텍스트가 예상보다 더 넓은 권한을 가질 수 있음을 보여줍니다. 그러나 보안 모범 사례 및 적절한 SELinux 구성을 위해 웹 콘텐츠는 여전히 적절한 httpd_sys_content_t 컨텍스트를 사용해야 합니다.
This is custom web content.사용자 정의 디렉토리의 현재 SELinux 컨텍스트를 확인합니다.
ls -Z 명령을 사용하여 /custom 디렉토리와 index.html 파일의 SELinux 컨텍스트를 확인합니다.
ls -Zd /custom /custom/index.htmlroot_t 컨텍스트가 있음을 알 수 있는데, 이는 Apache 웹 콘텐츠에 권장되는 컨텍스트가 아닙니다.
system_u:object_r:root_t:s0 /custom
system_u:object_r:root_t:s0 /custom/index.html기본 Apache 문서 루트와 비교합니다.
ls -Zd /var/www/html/var/www/html에 httpd_sys_content_t 컨텍스트가 있음을 알 수 있습니다. 이것이 사용자 정의 디렉토리에 적용해야 하는 컨텍스트입니다.
system_u:object_r:httpd_sys_content_t:s0 /var/www/html/custom에 대한 영구 SELinux 파일 컨텍스트 규칙을 정의합니다.
semanage fcontext 명령은 SELinux 파일 컨텍스트 매핑 규칙을 관리하는 데 사용됩니다. -a 옵션은 새 규칙을 추가하고, -t는 대상 유형을 지정하며, 정규식 '/custom(/.*)?'는 /custom 디렉토리 자체와 그 안에 있는 모든 파일 및 하위 디렉토리를 일치시킵니다.
sudo semanage fcontext -a -t httpd_sys_content_t '/custom(/.*)?'이 명령은 SELinux 정책에 규칙을 추가하지만 기존 파일의 컨텍스트를 즉시 변경하지는 않습니다.
새 SELinux 컨텍스트를 파일에 적용합니다.
restorecon 명령은 파일 및 디렉토리의 SELinux 컨텍스트를 정책에 정의된 기본값으로 복원하는 데 사용됩니다. -R 옵션은 변경 사항을 재귀적으로 적용하고, -v는 자세한 출력을 제공합니다.
sudo restorecon -Rv /custom/custom 및 /custom/index.html의 컨텍스트가 다시 레이블링되었음을 나타내는 출력이 표시되어야 합니다.
Relabeled /custom from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /custom/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0ls -Z를 사용하여 컨텍스트를 다시 확인합니다.
ls -Zd /custom /custom/index.html이제 httpd_sys_content_t 컨텍스트가 있어야 합니다.
system_u:object_r:httpd_sys_content_t:s0 /custom
system_u:object_r:httpd_sys_content_t:s0 /custom/index.html웹 페이지에 다시 접근합니다.
SELinux 컨텍스트가 올바르게 설정되었으므로 curl을 사용하여 웹 페이지에 다시 접근해 봅니다.
curl http://localhost/index.html이제 index.html 파일의 내용을 볼 수 있습니다.
This is custom web content.마지막으로 Apache HTTP 서버 프로세스를 중지합니다.
sudo pkill httpdhttpd 프로세스가 실행 중이지 않은지 확인합니다.
ps aux | grep httpdgrep 프로세스 자체만 표시되어야 합니다.
labex ... grep httpd이 단계에서는 부울 (Boolean) 을 사용하여 SELinux 정책을 조정하여 Apache 가 사용자의 홈 디렉토리에서 웹 콘텐츠를 제공하도록 허용하는 방법을 배우게 됩니다. 기본적으로 SELinux 는 보안상의 이유로 Apache 와 같은 서비스가 사용자 홈 디렉토리의 파일에 접근하는 것을 방지합니다. 그러나 개인 웹 페이지와 같이 이 기능이 필요한 특정 시나리오가 있습니다.
SELinux 부울은 관리자가 복잡한 사용자 정의 정책을 작성하지 않고도 SELinux 정책의 동작을 수정할 수 있도록 하는 true/false 설정입니다. 특정 보안 기능을 활성화하거나 비활성화하는 유연한 방법을 제공합니다. 예를 들어, Apache 가 사용자 홈 디렉토리에 접근하도록 허용하는 부울이 있습니다.
Apache 의 사용자 디렉토리 기능 활성화.
Apache 에는 사용자가 홈 디렉토리 내의 public_html 디렉토리 (예: ~/public_html) 에서 웹 콘텐츠를 게시할 수 있도록 하는 mod_userdir이라는 모듈이 있습니다. 이 기능은 일반적으로 /etc/httpd/conf.d/userdir.conf에서 구성됩니다. 기본적으로 이 기능은 종종 비활성화되어 있습니다.
nano를 사용하여 구성 파일을 엽니다.
sudo nano /etc/httpd/conf.d/userdir.conf편집기 내에서 UserDir과 관련된 줄을 찾을 수 있습니다. UserDir을 비활성화하는 줄을 주석 처리하고 public_html에 대해 활성화하는 줄의 주석 처리를 해제해야 합니다.
변경:
UserDir disabled
#UserDir public_html다음으로 변경:
#UserDir disabled
UserDir public_html파일을 저장하고 종료합니다 (Ctrl+X, Y, Enter).
홈 디렉토리에 public_html 디렉토리와 index.html 파일 생성.
public_html 디렉토리와 그 안에 index.html 파일을 만듭니다. 여기에 개인 웹 콘텐츠가 있습니다.
mkdir ~/public_html
echo 'This is labex user content.' > ~/public_html/index.htmlindex.html 파일의 내용을 확인합니다.
cat ~/public_html/index.htmlThis is labex user content.정보: ~/public_html 디렉토리를 만들 때 user_home_t 및 ~/ (홈 디렉토리) 는 home_dir_t SELinux 컨텍스트로 자동 구성되었습니다. Apache 웹 서버 프로세스 (httpd_t) 는 SELinux 정책으로 인해 기본적으로 user_home_t 또는 home_dir_t로 레이블이 지정된 파일을 읽을 수 없습니다.
Apache 웹 서비스 시작.
httpd 서비스를 시작합니다. 이 컨테이너 환경에서는 systemctl을 사용할 수 없으므로 httpd를 직접 시작합니다.
sudo /usr/sbin/httpd -DFOREGROUND &서버의 정규화된 도메인 이름에 대한 경고 메시지가 표시될 수 있으며, 이 랩 환경에서는 안전하게 무시할 수 있습니다.
Apache 가 실행 중인지 확인합니다.
ps aux | grep httpdroot ... /usr/sbin/httpd -DFOREGROUND
apache ... /usr/sbin/httpd -DFOREGROUND
...output omitted...사용자의 웹 페이지에 접근을 시도하고 SELinux 거부를 관찰합니다.
이제 curl을 사용하여 개인 웹 페이지에 접근해 봅니다. 사용자 디렉토리의 URL 은 일반적으로 http://localhost/~username/ 형식을 따릅니다.
curl http://localhost/~labex/index.htmlSELinux 로 인해 Apache 가 여전히 콘텐츠에 접근할 수 없음을 나타내는 "Forbidden" 오류가 수신될 가능성이 높습니다.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /~labex/index.html
on this server.<br />
</p>
</body></html>httpd에 대한 홈 디렉토리와 관련된 SELinux 부울을 확인합니다.
getsebool 명령을 사용하면 SELinux 부울의 현재 상태를 볼 수 있습니다. grep을 사용하여 httpd 및 홈 디렉토리와 관련된 부울을 찾도록 출력을 필터링할 수 있습니다.
sudo getsebool -a | grep httpd | grep homehttpd_enable_homedirs --> off가 표시되어 이 부울이 현재 비활성화되어 있음을 나타냅니다.
httpd_enable_homedirs --> offhttpd_enable_homedirs 부울을 영구적으로 활성화합니다.
setsebool 명령은 SELinux 부울의 상태를 변경하는 데 사용됩니다. -P 옵션은 재부팅 후에도 변경 사항을 유지합니다.
sudo setsebool -P httpd_enable_homedirs on부울이 이제 on인지 확인합니다.
sudo getsebool -a | grep httpd | grep homehttpd_enable_homedirs --> on홈 디렉토리에 대한 올바른 파일 권한을 설정합니다.
SELinux 부울이 활성화되어 있더라도 Apache 는 홈 디렉토리와 public_html 디렉토리에 접근하기 위해 적절한 파일 시스템 권한이 필요합니다. 기본적으로 사용자 홈 디렉토리는 Apache 사용자가 접근할 수 없습니다.
chmod 711 ~
chmod 755 ~/public_html
chmod 644 ~/public_html/index.html웹 페이지에 다시 접근합니다.
이제 httpd_enable_homedirs 부울이 활성화되고 파일 권한이 올바르게 설정되었으므로 curl을 사용하여 개인 웹 페이지에 다시 접근해 봅니다.
curl http://localhost/~labex/index.html이제 index.html 파일의 내용을 볼 수 있습니다.
This is labex user content.문제 해결: 부울을 활성화하고 파일 권한을 설정한 후에도 여전히 접근 문제가 발생하는 경우, 이는 Linux 보안의 다층적 특성을 보여줍니다. 일부 환경에서는 다음과 같은 추가 요소가 필요할 수 있습니다.
/etc/httpd/conf.d/userdir.conf의 Apache 구성 지시문주요 학습 포인트는 SELinux 부울이 기존 파일 권한 및 애플리케이션별 구성과 함께 작동하는 방식을 이해하는 것입니다.
Apache HTTP 서버 프로세스를 중지합니다.
마지막으로 Apache HTTP 서버 프로세스를 중지합니다.
sudo pkill httpdhttpd 프로세스가 실행 중이지 않은지 확인합니다.
ps aux | grep httpdlabex ... grep httpd이 단계에서는 Apache 웹 서버가 올바르게 작동하는 것을 방해할 수 있는 문제에 중점을 두고 SELinux 보안 거부를 식별하고 문제 해결하는 방법을 배우게 됩니다. SELinux 가 작업을 차단하면 "Access Vector Cache" (AVC) 거부 메시지를 기록합니다. 이러한 메시지는 작업이 실패한 이유와 해결 방법을 이해하는 데 매우 중요합니다.
auditd (Linux Auditing System 데몬) 및 sealert와 같은 도구를 사용하여 이러한 거부 메시지를 분석합니다. auditd는 SELinux 거부를 포함하여 시스템 호출 및 이벤트를 수집하고 /var/log/audit/audit.log에 저장합니다. setroubleshoot-server 패키지의 일부인 sealert 도구는 이러한 로그를 구문 분석하고 SELinux 거부에 대한 사람이 읽을 수 있는 설명과 제안된 솔루션을 제공할 수 있습니다.
먼저, auditd 및 setroubleshoot-server가 설치되어 있는지 확인해야 합니다.
auditd 및 setroubleshoot-server 설치.
sudo dnf install -y audit setroubleshoot-server이러한 패키지의 성공적인 설치를 나타내는 출력이 표시되어야 합니다.
Apache 웹 서버를 시작하고 문제가 있는 파일 생성.
SELinux 거부를 시뮬레이션하기 위해 잘못된 SELinux 컨텍스트로 파일을 만들고 Apache 로 제공하려고 합니다.
먼저, Apache 가 실행 중인지 확인합니다.
sudo /usr/sbin/httpd -DFOREGROUND &이제 새 디렉토리와 그 안에 index.html 파일을 만듭니다. 이번에는 거부를 트리거하기 위해 이 파일에 대해 의도적으로 잘못된 SELinux 컨텍스트를 설정합니다.
sudo mkdir /testweb
echo 'This is a test page.' | sudo tee /testweb/index.html기본적으로 /testweb/index.html은 root_t 컨텍스트를 가질 가능성이 높습니다. 확인해 보겠습니다.
ls -Z /testweb/index.htmlsystem_u:object_r:root_t:s0 /testweb/index.html이제 /testweb에서 제공하도록 Apache 를 구성해 보겠습니다. /etc/httpd/conf/httpd.conf를 엽니다.
sudo nano /etc/httpd/conf/httpd.confDocumentRoot 및 <Directory> 지시문을 /testweb로 변경합니다.
DocumentRoot "/testweb"
<Directory "/testweb">
AllowOverride None
Require all granted
</Directory>저장하고 종료합니다 (Ctrl+X, Y, Enter).
구성 변경 사항을 적용하려면 Apache 를 다시 시작합니다. 컨테이너에 있으므로 이전 프로세스를 종료하고 새 프로세스를 시작해야 합니다.
sudo pkill httpd
sudo /usr/sbin/httpd -DFOREGROUND &웹 페이지에 접근을 시도합니다.
curl을 사용하여 웹 페이지에 접근해 봅니다.
curl http://localhost/index.html중요 참고 사항: 이 환경에서는 2 단계에서 관찰한 것과 유사하게 root_t 컨텍스트로도 웹 페이지에 접근할 수 있음을 알 수 있습니다. 이는 SELinux 가 시행 중이지만 root_t 컨텍스트가 더 제한적인 컨텍스트보다 더 넓은 권한을 가지고 있음을 보여줍니다.
This is a test page.그러나 SELinux 문제 해결 기술을 배우기 위해 거부가 있는 것처럼 진행합니다. 더 제한적인 SELinux 환경 또는 다른 정책 구성에서는 부적절한 컨텍스트로 파일에 접근하면 실제로 거부가 생성됩니다.
ausearch를 사용하여 SELinux 거부를 조사하는 방법에 대해 알아봅니다.
ausearch 명령은 감사 로그를 쿼리하는 데 사용됩니다. 오늘 발생한 SELinux AVC 거부 (-m AVC) 를 검색할 수 있습니다 (-ts today).
sudo ausearch -m AVC -ts today참고: 이 환경에서는 웹 페이지에 접근할 수 있었으므로 이 특정 테스트와 관련된 최근 AVC 거부가 표시되지 않을 수 있습니다. 그러나 이 명령은 일반적으로 거부가 있는 경우 자세한 감사 로그 항목을 출력합니다. 일반적인 거부 시나리오에서는 httpd 및 /testweb/index.html과 관련된 항목을 찾습니다.
일반적인 AVC 거부 항목은 다음과 같습니다.
----
time->...
type=AVC msg=audit(...): avc: denied { getattr } for pid=... comm="httpd" path="/testweb/index.html" dev="overlay" ino=... scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=file permissive=0
...output omitted...AVC 거부의 주요 부분은 다음과 같습니다.
denied { getattr }: 거부된 작업 (파일의 속성 가져오기).comm="httpd": 거부된 프로세스 (Apache HTTP 서버).path="/testweb/index.html": 접근된 파일.scontext=system_u:system_r:httpd_t:s0: 소스 (Apache) 의 SELinux 컨텍스트.tcontext=system_u:object_r:root_t:s0: 대상 (/testweb/index.html 파일) 의 SELinux 컨텍스트.tclass=file: 대상 유형 (파일).이 출력은 httpd_t (Apache) 가 default_t 컨텍스트가 있는 파일에 대한 getattr 접근이 거부되었음을 명확하게 보여줍니다.
SELinux 분석에 sealert를 사용하는 방법에 대해 알아봅니다.
sealert는 감사 로그를 구문 분석하고 더 사용자 친화적인 정보를 제공할 수 있습니다. 최근의 모든 거부를 분석하려면 sealert -a를 실행하거나, /var/log/messages의 setroubleshoot 메시지에서 특정 UUID 가 있는 경우 sealert -l <UUID>를 사용합니다.
sudo sealert -a /var/log/audit/audit.log참고: 이 환경에서는 실제 거부가 발생하지 않았으므로 sealert를 실행해도 /testweb 예제와 관련된 결과가 표시되지 않을 수 있습니다. 그러나 SELinux 거부가 발생하는 시나리오에서는 sealert가 감사 로그를 분석하고 요약을 제시합니다.
httpd 컨텍스트 문제에 대한 일반적인 sealert 출력은 다음과 같습니다.
SELinux is preventing /usr/sbin/httpd from getattr access on the file /testweb/index.html.
***** Plugin catchall_labels (83.8 confidence) suggests *******************
If you want to allow httpd to have getattr access on the index.html file
Then you need to change the label on /testweb/index.html
Do ## semanage fcontext -a -t FILE_TYPE '/testweb/index.html'
where FILE_TYPE is one of the following:
httpd_sys_content_t, httpd_sys_script_exec_t, httpd_unconfined_script_exec_t, ...
***** Plugin httpd_can_network_connect (93.8 confidence) suggests *********
If you want to allow httpd to connect to the network (for example, to a database)
Then you must set the httpd_can_network_connect boolean to on.
Do ## setsebool -P httpd_can_network_connect on
...output omitted...sealert 출력은 실제 거부 시나리오에서 매우 유용합니다. 문제점을 명시적으로 설명하고 semanage fcontext -a -t FILE_TYPE '/testweb/index.html'로 레이블을 변경하고 httpd_sys_content_t를 적합한 FILE_TYPE으로 나열하는 것과 같은 솔루션을 제안합니다.
마지막으로 Apache HTTP 서버 프로세스를 중지합니다.
sudo pkill httpdhttpd 프로세스가 실행 중이지 않은지 확인합니다.
ps aux | grep httpdlabex ... grep httpd이 마지막 단계에서는 이전 문제 해결 연습에서 얻은 지식을 적용하여 Apache 가 /testweb 디렉토리에서 콘텐츠를 제공하는 것을 방해했던 SELinux 거부를 해결합니다. semanage fcontext를 사용하여 사용자 정의 웹 콘텐츠에 대한 올바른 SELinux 컨텍스트를 정의하고 restorecon을 사용하여 적용합니다.
이 프로세스는 SELinux 컨텍스트가 작동하는 방식과 Apache 와 같은 서비스에 대해 이를 올바르게 구성하는 방법에 대한 이해를 강화합니다.
Apache 가 실행 중이고 구성이 적용되었는지 확인합니다.
먼저, Apache 가 /testweb에서 제공하도록 구성되어 있고 실행 중인지 확인합니다. 이전 단계에서 Apache 를 중지한 경우 다시 시작합니다.
sudo /usr/sbin/httpd -DFOREGROUND &/etc/httpd/conf/httpd.conf의 DocumentRoot가 /testweb로 설정되어 있는지 확인합니다. 그렇지 않은 경우 이전 단계에서 수행한 대로 수정합니다.
grep "DocumentRoot" /etc/httpd/conf/httpd.confDocumentRoot "/testweb"또한 /testweb/index.html이 존재하고 root_t 컨텍스트를 갖는지 확인합니다.
ls -Z /testweb/index.htmlsystem_u:object_r:root_t:s0 /testweb/index.html현재 동작을 확인하기 위해 웹 페이지에 접근합니다.
root_t 컨텍스트로 웹 페이지에 현재 접근할 수 있는지 확인해 보겠습니다.
curl http://localhost/index.html이전에 보았듯이 root_t 컨텍스트로도 페이지에 접근할 수 있습니다.
This is a test page.이것이 작동하지만 웹 콘텐츠에 대한 적절한 SELinux 구성을 시연하기 위해 진행합니다.
/testweb에 대한 올바른 SELinux 파일 컨텍스트를 정의합니다.
Apache 에서 제공하는 웹 콘텐츠에 대한 올바른 SELinux 컨텍스트는 httpd_sys_content_t입니다. semanage fcontext를 사용하여 영구적인 규칙을 추가해야 합니다.
sudo semanage fcontext -a -t httpd_sys_content_t '/testweb(/.*)?'이 명령은 SELinux 에 /testweb 내의 모든 파일 또는 디렉토리 (/testweb 자체 포함) 에 httpd_sys_content_t로 레이블을 지정하도록 지시합니다.
새 SELinux 컨텍스트를 파일에 적용합니다.
규칙을 정의한 후 restorecon을 사용하여 기존 파일에 적용해야 합니다.
sudo restorecon -Rv /testweb컨텍스트가 다시 레이블 지정되었음을 나타내는 출력이 표시되어야 합니다.
Relabeled /testweb from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0
Relabeled /testweb/index.html from system_u:object_r:root_t:s0 to system_u:object_r:httpd_sys_content_t:s0ls -Z를 사용하여 컨텍스트를 다시 확인합니다.
ls -Z /testweb/index.htmlsystem_u:object_r:httpd_sys_content_t:s0 /testweb/index.html적절한 구성을 확인하기 위해 웹 페이지에 다시 접근합니다.
이제 SELinux 컨텍스트가 모범 사례에 따라 올바르게 적용되었으므로 curl을 사용하여 웹 페이지에 다시 한 번 접근해 봅니다.
curl http://localhost/index.html콘텐츠는 여전히 접근할 수 있어야 하며 이제 권장되는 SELinux 컨텍스트로 적절하게 구성되었습니다.
This is a test page.이는 root_t 컨텍스트가 이 환경에서 작동할 수 있지만 적절한 httpd_sys_content_t 컨텍스트를 사용하면 SELinux 모범 사례를 따르고 서로 다른 보안 구성 간의 호환성을 보장함을 보여줍니다.
마지막으로 Apache HTTP 서버 프로세스를 중지합니다.
sudo pkill httpdhttpd 프로세스가 실행 중이지 않은지 확인합니다.
ps aux | grep httpdlabex ... grep httpd이 랩에서는 RHEL 에서 SELinux 보안을 관리하는 방법을 배웠습니다. 먼저 setenforce를 사용하여 일시적으로, /etc/selinux/config를 수정하여 영구적으로 SELinux 시행 모드를 변경하는 방법을 이해하고 실습했습니다. 여기에는 getenforce를 사용하여 현재 모드를 확인하고 시행 (Enforcing), 허용 (Permissive), 비활성 (Disabled) 모드의 의미를 이해하는 것이 포함되었습니다.
또한, semanage fcontext 및 restorecon을 사용하여 사용자 정의 SELinux 파일 컨텍스트로 Apache 를 구성하여 적절한 웹 서버 작동을 보장하는 실질적인 경험을 얻었습니다. 또한 setsebool을 사용하여 특정 SELinux 부울 값을 활성화하여 사용자 홈 디렉토리에 대한 SELinux 정책을 조정하는 방법을 배웠습니다. 마지막으로, 이 랩에서는 SELinux 거부에 대한 필수적인 문제 해결 기술을 다루었습니다. 특히 Apache 웹 서버의 경우, ausearch 및 audit2allow를 사용하여 감사 로그를 분석하여 사용자 정의 웹 콘텐츠에 대한 접근 문제를 식별하고 해결했습니다.
