SELinux는 고맙게도 자신이 거부한 것에 대한 안내를 /var/log/audit/audit.log에 친절히 남겨주고 있었다. 이것을 보기좋게 보여주는 audit2allow -a 명령은 불행하게도 별 도움이 되지 못했다. 다음은 /var/log/audit/audit.log를 직접 분석하여 위의 문제를 해결하는 일련의 과정이다.
음... 이 고비는 일단 넘겼지만 Apache 웹 데몬에서 실행되는 mod_python의 디렉토리, 파일 I/O에 대해 그 대상이 httpd_sys_script_rw_t 를 가지고 있어야 한다니, 벌써부터 예상되는 문제가 떠오른다. 아마 산너머 산이 될까? 다행히 type 부여후 새로 생성되는 것들은 부모의 속성을 이어 받는듯 하다. 정말 다행 스런 일이다.
PHP는 httpd_sys_content_t로 만사 오케이 이건만 ^^;
여하튼 그동안 정확한 원인을 몰라 쩔쩔매던 것이 이렇게 SELinux가 자신이 거부한 것에 대해 친절이 로그를 남기고 있다니 천만 다행이다.
예전 회사에서 보안 Kernel을 위해 PKI 알고리즘을 사용하여 실행화일 수행시 서명이 통과된 실행화일만 수행 가능하도록 했던 프로젝트라던지, ETRI 프로젝트를 진행하면서 역할 기반한 인증서 발급 시스템의 Framework을 개발했던 기억이 난다. 모두 보안 이슈로서 허가받지 않은 행동이 이루어지는 것을 막고자 하는 열망에서 기인한 프로젝트 들이었다.
Linux의 Kernel에도 드디어 보다 진보된 보안 시스템이 도입되어 실용화 되었다. 그것이 바로 SELinux이다. 일단은 사용자, 프로그램, 프로세서 들의 주체와 파일, 디렉토리, 디바이스 등의 대상 리소스를 분리하여 각각의 범주를 정의하고 개별 리소스에 대해 각 범주를 설정한다는 측면에서 기존의 사용자 소유권에 기반한 보안 시스템보다 훨씬 안전한 보안을 보증해 주길 기대해 본다.
하지만, 덕분에 SELinux에 대한 이해 없이는 매 문제가 발생할 때 마다 구글 신공을 발휘해야할 처지에 놓였있다.
Http 데몬의 Listen 포트(8888)를 하나 추가하였는데 컥 커널에서 Bind시 에러가 발생하였다. 결국 문제는 SELinux와 결부되어 있었다.
[root@ProjectS conf.d]# service httpd restart httpd 를 정지 중: [ OK ] httpd: Could not reliably determine the server's fully qualified domain name, using 218.158.45.145 for ServerName (13)Permission denied: make_sock: could not bind to address [::]:8888 (13)Permission denied: make_sock: could not bind to address 0.0.0.0:8888 no listening sockets available, shutting down Unable to open logs [실패] [root@ProjectS conf.d]#
semanage 명령을 사용하여 8888 포트를 http에 대해 접근을 허가한 후에 정상적으로 bind 될 수 있었다. 조만간 SELinux에 대한 이해가 필요할 듯 하다.
