이은호 2014-01

SELinux는 linux 공격에 빈번히 이용되는 보안 위험요소를 기본적으로 방어해주는 역할을 합니다.
가령 ftp home dir 보안취약점,
세마포어 공유 메모리 관련 취약점,
httpd가 생성하는 tcp socket network 취약점등 다양하죠.

해당 기능을 아예 사용하지 않는다라면 기능을 제거하여 애초에 보안 위협이 발생하지 않게끔 할 수 있지만
그 기능을 사용하는 경우도 많아서 SELinux 등을 통하여 막아두고 풀 수 있게끔 한 것이죠.

전 SELinux를 강제 설정하고, 필요한 것들만 setsebool 등으로 allow해줍니다.

피투성 2014-01

방화벽은 rule 기반의 네트워크 접근에 대한 방어를 수행하는 반면
SELinux는 역할 기반으로 전반적인 시스템의 리소스들에 대한 접근 권한을 관리하는 것 같습니다.

즉 HTTP를 예로 들면 방화벽은 특정 IP나 특정 패턴의 dest가 80 port인 네트워크 접근을 막는다면,
Selinux는 http role을 갖는 계정으로 실행되는 어플리케이션(apache, cgi, php, java 등등)의 파일, 디렉토리, 소켓 생성,
device i/o, 프로그램 실행 등등에 대한 접근 및 실행 권한에 대한 전반적인 것들을 관리합니다.

따라서, 관리적 측면에서는 무척 귀챦은 것이 사실입니다.
예를 웹 서비스를 할때 특정 디렉토리에 접근 권한을 주었는데, 또 실행 권한도 열어주어야 하고,
해당 어플이 소켓을 사용하는데 이것도 찾아서 풀어주어야 하고, 특정 h/w를 사용하는데 이것도 풀어주어야 하고,
심지어 특정 시스템 콜에 대해서도 풀어주어야 하는 경우도 발생하고,

무엇가 문제로 프로그램 실행 에러가 발생하는데 도통 어떤 보안 조건에 걸려서 안되는지도 알 수 없고,
(흐흐 한번 알아두면 쉽습니다. audit 검사를 하면 원인과 해결 방법도 알 수 있습니다.)

저 같은 경우 centos 5.x 부터 selinux를 접했던것 같은데, 처음엔 그럴싸해서 없는 자료 뒤져 가면서 사용해볼려고 했는데, 서비스가 잘 안되서 막 풀어주다 보면, 이렇게 풀어 버리면 selinux를 사용하는 의미가 있나 싶기도 하고
그래서 결국 지금은 항상 selinux 상태 먼저 확인하고 disable 시켜 버립니다.

제한된 환경의 network 서비스 시스템은 할수만 있다면 well-known port만 피해가도 어느정도 공격의 위협으로
부터 벗어 날 수 있는것 같습니다.
다만 부득이 well-known을 써야 하는 서비스를 통해 커널 rootkit이 설치되는 무시무시한(?) 경험도 했지만 말입니다.
크크

사용을 안하다 보니 centos 6.x 대인 지금은 얼마나 편리하게 바뀌었는지 모르겠습니다.