SELinux 발번역 1 - SELinux 개괄 (미완성)

소개

SELinux는 다수의 GNU/Linux 배포판에 빌트인 된 최초의 Mandatory Access Control (MAC)이다. 원래 SELinux는 Utah University Flux팀과 US Department of Defence의 Flux Advanced Security Kernel(FLASK) 개발로부터 시작되었다. 그 개발은 NSA에 의해 강화되고, 또한 오픈 소스로 릴리즈됨으로써 더욱 강화되었다. SELinux의 개발에 관한 히스토리는 Flux와 NAS 웹싸이트에서 찾을 수 있다.

다음에 오는 각 섹션은 SELinux의 요소들에 관해 설명할 것이다. 그리고 대강의 논리적은 순서에 따라 기술되었다.

Note: SELinux가 설치될 때, 세개의 잘 정의된 디렉토리가 참조된다. 두 개는 최신버전에서 다음과 같이 변경되었다.

설명	과거 위치	최신 위치
security server에 기반한 커널과 연결하는 SELinux 파일시스템	/selinux	/sys/fs/selinux
sub-system의 환결설정과 policy들을 가지고 있는 SELinux 환경설정 디렉토리	/etc/selinux	No change
policy 모듈과 자세한 환경설정을 가지고 있는 SELinux policy 저장소	/etc/selinux	/var/lib/selinux

SEAndroid에서 위 디렉토리들은 존재하는가? 다른 디렉토리로 바뀌지 않았나?

SELinux는 유용한가?

Linux 에서 SELinux의 유용성을 보는 다양한 관점들이 있다. 이 섹션에서는 SELinux가 어디에 좋은지 또한 왜 좋지 않은지에 관한(그런것들을 목적으로 만들어지지 않았으므로..) 간단한 관점들을 소개한다.

SELinux는 Multi-Level Security(MLS)가 요구되는 군대 또는 보안 시스템을 위한 것만은 아니다. "Type Enforcement(TE)" 기능을 사용하면서, 어플리케이션들은 domain에 담겨딜 수 있고, "nutshell"이란 곳 안에서 실행되는데 최소의 권한이 주어진다. 

MLS가 뭐지?

1. SELinux가 Enable되면, policy는 어떤 자원과 연산이 그들에게 허락될지 정의한다. (즉 SELinux는 policy에 의해 허락되지 않은 access는 방어?한다). 이것이 SELinux가 왜 "Mandatory Access Control(MAC)"라 부를는지에 대한 이유이다.
2. 보안 규칙 또는 요구사항에 의해 만들어진 Policy 디자인, 구현 그리고 테스트는 매우 중요하다. 그렇지 않으면 안정성에 매우 불안전하게 된다.
3. SELinux는 어플리케이션을 'domain'이라는 것에 가두고, 작업에 필요한 최소한의 권한을 허용한다. 어플리케이션이 네트워크나 다른 어플리케이션이 접근권한을 요청할때는, 그에 대한 접근권한이 충족되어져 있어야만 한다. (적어도 어떤 interaction이 허락되어지는지와 어떤 것이 막혀야하는지는 알고 있어야 한다)
4. 어플리케이션이 policy에 허락되지 않는 무언가를 하려하면, SELinux는 그 행위를 막는다.
5. 어플리케이션이 policy에 의해 허락된 무언가를 실행하면, SELinux는 고의적이던 아니던 데미지를 입을 가능성이 있다. 예를 들어 한 어플리케이션이 모든 파일이나 데이터베이스를 삭제할 권한을 가지고 있다면, 바이러스나 나쁜 유저가 그 권한을 획득했을 때, 같은 행위를 저질러버릴 수 있다. 그러나 좋은 소식은 policy가 어플리케이션과 데이터를 세밀하게 제어했을 경우, 모든 데이터는 안전할 수 있다.
6. 로그인 세션은 그들의 도메일에 속할 수 있다. 이것은 오직 그들이 실행하는데 필요로하는 권한만을 그들에게 주어질 수 있다.(즉, admin이나 sales 스탭이냐, HR이냐에 따라 다르게 권한을 줄 수 있다). 이 점은 데이터의 데미지를 최소화로 제한할 수 있다.
7. X-Windows같은 어떤 어플리케이션은 일반적으로 모든 data에 관해 접근을 원하기 때문에 권한을 세밀하게 주기가 어려울 수도 있다. SELinux는 sandboxing 서비스를 이용하여 그와같은 문제를 해결할 수 있다.
8. SELinux는 메모리 릭이나 버퍼 오버런과 같은 문제를 멈출 수는 없다.(왜냐하는 SELinux는 그 문제를 해결하기 위해 만들어지지 않았기 때문). 하지만 그 문제를 작게 억제할 수는 있다.
9. SELinux는 모든 virus나 malware를 막을 수는 없다.(왜냐하면 합법적인 일반 유저에 의한 virus/malware 설치도 매우 다양하게 나타나기 때문이다). 그러나 그것들이 가져올 데미지의 범위를 제한할 수는 있다.
10. SELinux는 커널 약점을 극복할 수는 없다. 하지만 그 약점에 의한 피해를 제한할 수는 있다.
11. 유저가 관련 권한을 가지고 있다면, audit2allow와 같은 툴로 SELinux policy를 추가하는 것은 매우 쉽다. 그러나 권한을 추가한다는 것은 security hole을 만들 수도 있다는 사실을 기억해야 하고, 그래서 추가할 rule이 정말로 필요한 것인가는 정확히 알아야 한다.
12. 마지막으로, SELinux는 security policy에 의해 허락된 어떤 것도 막을 수 없다. 따라서 policy의 정확하고 좋은 디자인이 중요하다.

다음은 SELinux과 관해 유용한 연습을 제공해 줄 수 있다.

• Apache 버서와 SELinux에 관한 토론은 처음엔 부정적으로 보일 수 있다. 하지만 어떤 점을 억제할 것인가는 중요한 포인트인다. 그것에 대한 초기 스터디는 다음을 참고 http://blog.ptsecurity.com/2012/08/selinux-in-practice-dvwa-test.html, 이것은 그 스터디에 관한 결과 http://danwalsh.livejournal.com/56760.html.

하지만 좋은 policy 디자인과 알려져있는 보안목표들(?)로인해 SELinux ' Apache / SELinux Plus' 서비스는 많은 보안 웹서비스를 빌드하는데 사용되어 질 수 있다(?) (http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus).

• SELinux는 SEAndroid란 이름으로 Android에 포함되어져 왔다. 아래 프리젠테이션은 SELinux가 극복할 수 있는 Android의 취약점에 관한 use-case를 제공해준다 (https://events.linuxfoundation.org/images/stories/pdf/lf_abs12_smalley.pdf)

중요 SELinux의 구성요소들

High Level Core SELinux Component(http://taiga.selinuxproject.org/~rhaines/diagrams/1-core.png)는 SELinux의 중요 구성요소들에 관한 상위 단계에서의 관점이다. 그 구성요소들은 다음과 같이 policy의 강제를 제어한다. 

1. subject는 objec에 의해 획득되는 행위를 일이킨다???? (subject가 포함되었을 때, 파일을 읽는 것과 같은 것..???)
2. Object Manager는 파일과 같은 특정한 자원을 필요로하는 액션을 알고있고, policy rule에 의해 그 액션을 제어할 수 있다.
3. Security Server는 policy rule에 의해 object에 요청되는 action이 수행될 권한이 subject에 있는지 결정한다.
4. Security Policy는 SELinux Policy Language(http://selinuxproject.org/page/PolicyLanguage)에 따라 쓰여진다. 
5. Access Vector Cache(AVC)는 security server의 결정을 캐쉬함으로써 시스템의 성능을 높인다.

High Level SELinux Architecture(http://taiga.selinuxproject.org/~rhaines/diagrams/2-high-level-arch.png)는 SELinux 환경에서 사용되는 더욱 복잡한 커널/유저스페이스/다양한 서비스 지원에 관한 view를 보여준다. 이 그림은 SELinux를 설명할때 여러번 참조될 것이다.

• 현대 SELinux의 구현상으로는, security server는 userspace에서 로딩되는 policy과 함께 커널 안에 있다. 또한 policy 로딩은 libselinux 라이브러리안에 포함된 다양한 함수에 의해 로딩된다.

Object Manager(OM) 과 Access Vetor Cache (AVC)는 다음과 같은 곳에 있다.

Kernel Space. Object Manager들은 파일/디렉토리/소켓/IPC와 같은 커널 서비스를 위해 존재하고, Linux Security Module(LSM)을 이용하는 SELinux sub-system에 있는 hook에 의해 제공된다. LSM은 LSM 섹션(http://selinuxproject.org/page/NB_LSM)에서 따로 기술될 것이다. SELinux 커널 AVC 서비스는 security server가 커널의 object manager들에게 응답하는 것을 캐쉬한다. 그러므로 향후에 있을 같은 요청에 빠르게 접근 결정을 내릴 수 있게 된다.

• userspace. object manager들은 MAC를 지원하기 위해 application 또는 서비스들로 이루어져 있고, 그것들은 "SELinux aware" 어플리케이션 또는 서비스라고 불리운다. 예를 들어 X-Windows, Gnome desktop에서 사용되는 D-bus messaging, PostgreSQL database, Name Service Cache Daemon(nscd) 그리고 GNU/Linux passwd 명령어들이 그것이다. 일반적으로 이 OM들은 SELinux library (libselinux)안에 있는 AVC 서비스를 사용한다. 그러나 그들은 AVC를 전혀 이용하지 않거나 그들의 AVC를 ???? 뭔말이냐....

• 그림의 오른쪽에 있는 SELinux security policy와 그 설정 파일들은 /etc/selinux 디렉토리 안에 있다. 이 디렉토리는 주요 SELinux 설정 파일(config)을 가지고 있고, 그 설정 파일은 로드될 policy의 이름들과 policy 로딩시의 초기 enforcement를 어떻게 할것인지에 대한 정보를 가지고 있다(SELINUX entry를 통하여..). /etc/selinux/<SELINUXTYPE> 디렉토리는 설정파일들과 함께 동작되어질 policy들을 가지고 있다 (즉, SELINUXTYPE=targeted라고 설정되면 설정파일들은 /etc/selinux/targeted에 저장된다.). 알려진 모든 설정파일들은 요 섹센(http://selinuxproject.org/page/ConfigurationFiles)에서 자세히 알 수 있다.
• SELinux는 "modular policy"를 지원한다. 즉, policy들은 한개의 커다란 policy 소스로 이루어져 있지 않고 모듈들 안에 있다는 뜻이다. modular policy는 중요한 정보(object classe들, permission 등..)를 가지고 있는 base policy와 각각의 어플리케이션 또는 서비스를 지원하는 0개 이상의 policy module로 이루어져 있다. 그 module들은 컴파일되고 링크되어 "policy store"에 저장되는데, "policy store"는 binary 형식으로 만들어져서 security server에 로딩되게 된다(그림으로는 binary policy가 /etc/selinux/targeted/policy/policy.26에 있다). policy의 종류와 그 구성은 은 요 섹선(http://selinuxproject.org/page/NB_PolicyType)에 설명되어 있다. 
• 처음 policy를 빌드하기 위해서는, policy 소스(그림의 왼쪽 위)가 필요하다. 이것은 두 가지 방법이 제공된다(세번째 방법은 CIL(Common Intermediate Language)란 개발이 끝나면 가능하다)
• SELinux Policy Language로 작성된 소스코드(http://selinuxproject.org/page/PolicyLanguage)로 부터 생성. 여기에 이 notebook에 나온 예제들이 쓰여졌는지에 관해 나와있다. 그러나 실제 policy에서는 이 예제 policy를 사용하지 말기를 권한다
• policy rule들은 정의하는데 높은 수준의 macro를 사용한 레퍼런스 policy를 이용한다. 이것은 현재 Red Hat과 Debian과 같은 SELinux 배포판들에 들어가있는 표준 방법의 policy들이다. 레퍼런스 policy는 여기에 설명되어 있다(http://selinuxproject.org/page/NB_RefPolicy)
• 소스 코드를 컴파일하고 링크고 그것을 security server로 적재하기 위해서는 다수의 tool들이 필요하다(그림의 상단에 나와있음). 그것들은 샘플 policy module을 빌드하는데 사용된다.
• policy를 관리하기 위해 시스템 관리자 권한을 enable시키려면, SELinux 환경과 Label file system은 tool들과 수정된 GNU/Linux 명령어들을 필요로 한다.
• security 이벤트가 로깅되는 것을 확신하기 위해서, GNU/Linux는 policy 위반을 적재하는 audit server를 가지고 있다. 요기서(http://selinuxproject.org/page/NB_AL) 그 security 이벤트들의 형식을 기술하고 있다.
• SELinux는 네트웤 서비스도 지원한다(http://selinuxproject.org/page/NB_Networking)

Linux Security Module and SELinux 섹션에서는 LSM/SELinux에 관해 더 자세히 들여다 본다