^^; 웁스..... 한고비 뒤 SELinux와 관련된 에러가 또 발생하였다. Trac에서 로깅을 위해 syslogd를 사용하도록 설정하였더니, 웁스 아래 그림과 같은 에러가 발생하였다.
원인은 기본적으로 httpd 데몬에서 수행된 script (httpd_sys_script_t)에서 Socket 생성하는 것이 막혀 있기 때문이었다. ( ^^; 재미있는 것은 php는 스크립트로 취급되지 않는 것 같다. php로 된 Dokuwiki는 smtp를 사용한 메일 발송에 문제가 없었었다.)
이것은 socket이라는 시스템의 커널 리소스에 대한 문제이기 때문에 무언가 context type을 변경해준다고 해결될 문제가 아니었다. 즉 정책 변경이 필요하게 된 것이다.
1차적으로 allow httpd_sys_script_t self:unix_dgram_socket { write create connect }; 이 적용되면 일차적으로 위 소켓 생성시 나는 에러를 해결할 수 있을 것이다. 기타 관련된 다른 allow도 audit 로그 분석을 통해 뽑아졌다.
위 명령을 수행하면 현재 폴더에 tracsocket.pp 와 tracsocket.te 파일 2개가 생성된다. tracsocket.pp는 컴파일된 policy module 파일이다. tracsocket.te는 text로 된 컴파일되기 전의 소스이다.
이것을 SELinux 시스템에 적용하는 방법은 $ semodule -i tracsocket.pp 와 같이 하면 적용된다.
이렇게 한번 인스톨된 모듈의 정책은 리부팅 후에도 유지된다고 하니, install에 사용된 pp를 삭제하면 무슨일이 벌어질까?!, 아마도 커널에 로드된 정책을 포함한 전체 Policy를 별도로 저장한다면 문제가 없겠지만 커널 모듈 파일이 지워지면 커널 모듈 로딩중 에러가 나듯, pp 파일이 삭제되면 SELinux에서 Policy 모듈 로드중 에러가 나지 않을까 생각해 본다.
굳이 시간을 들여 테스트 해보픈 마음은 없다. ^^; 여튼 사용된 pp파일은 되도록 삭제나 install된 위치에서 옮기지 말도록 하자. te 파일도 같이 보관하자. 컴파일된 pp 모듈이 실제 어떤 정책을 갖는지 텍스트인 te 파일을 통해 확인할 수 있으니 말이다. 얼핏 te를 가지고 재 컴파일도 가능하다고 한것 같지만 사용법은 나중에 필요하면 알아봐야 겠다. ㅋㅋ
^^ 멋지게 문제가 해결되었다. SELinux에서 audit2allow 무척 유용하구나! ㅋㅋ
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가 자신이 거부한 것에 대해 친절이 로그를 남기고 있다니 천만 다행이다.
