SELinux 발번역 2 - Type Enforcement (미완성)

SELinux는 MAC를 시행하기 위해서 Type Enforcement란 독특한 스타일을 사용한다. SELinux에 한해서 그것은 모든 subject와 object는 그들과 연관된 type 식별자를 가지고 있고, 그것들은 policy에 적힌 rule을 시행하기 위해 사용된다.

SELinux Type Identifier는 간단한 가변길이 문자열이다. 그것은 policy 안에서 정의되고 security context과 연관되어 진다. 이것은 또한 policy를 만드는데 사용되는 대부분의 SELinux Language statement와 rule에서 사용되어지고, security server에 적재될 때 policy를 시행할것이다.

Type Identifier(이하 type)은 모든 subject와 object와 연관되기 때문에, 때때로 그 type이 실제로 어떤 것과 연관되어지는지 구분하기가 어려울 수도 있다(모든 Type Identifier는 "_t"로 끝나지만, 이것도 딱히 도움이 되진 않는다). 결국 어떻게 그것들이 policy에서 배치되는지와 어떻게 그것들이 SELinux에서 사용되는지 이해를하는 수 밖에 없다.

기본적으로 만약 Type Identifier가 subject를 참조하는데 사용되었으면, 그것은 GNU/Linux process나 domain(혹은 domain type)을 가리키고 있을 것이다. 만약 Type Identifier가 object를 참조하는데 사용되어진다면, TI는 object의 object type(즉 file type)을 명시하고 있을 것이다.

SELinux가 subject를 domain type에 연관된 active process라고 인식하고 있으면, SELinux Type enforcement domain의 범위는 굉장히 넓어진다. 예를 들어, Building a Basic Policy섹션에 있는 간단한 policy에서, system의 모든 프로세스들은 unconfined_t domain으로 돌아가고, 따라서 모든 프로세스들은 "of type unconfined_t"가 된다. (그 의미는 기본적인 리눅스 DAC policy상으로는 모든지 할 수 있다는 뜻이다)

오직 간단한 policy에서 구현된 추가적인 policy들일 때만(loadable module에 의한), 그 범위들은 한정되어질 수 있다. 예를 들어 독립적인 domain에 속하는 외부 게이트웨이(ext_gateway_t)가 있으면, 그것은 어떤 unconfined_t 프로세스들에 의해서도 간섭을 받지 않는다(gateway processs가 그 domain에 들어가거나 그 domain으로 변경되었을 경우만 뺴고). 이 시나리오는 대부분의 user space process들이 unconfined_t 도메인에서 돌아가는 Red Hat Fedora의 표준의 "targeted" policy와 비슷하다. (하지만 그 policy가 Reference Policy에 의해 제공되는 policy들과 같지는 않다. Reference policy는 수년동안 발전되어 왔고, 나름의 영역에 국한적으로 발전해왔다.)

제약

TE 환경에서 subject가 object를 접근할 수 있는 권한을 얻으려면 "allow" rule을 이용해야 한다. 예를 들어,

allow unconfined_t ext_gateway_t : process transition

추후에 더 자시히 설명할 것이지만, 이것은 unconfined_t domain에서 돌아가는 process가 ext_gateway_t domain으로 변경하는 권한을 가지고 있다는 것을 의미한다. 하지만 policy 작성자가 이것을 더욱 제약하고 소스 도메인의 규칙이 타켓 도메인의 규칙과 같을때만 발생될 수 있게 만들 수도 있다. 그렇게 하려면 constrain 지시어를 적어야 한다.

constrain process transition ( r1 == r2 )

이것은 process transition이 오직 소스 규칙이 타겟 규칙과 동일할때만 발생되도록하는 것을 의미한다. 그러므로 제약은 한 개 이상의 권한이 만족되어야하는 조건이 된다. (즉 RE 규칙에 부과적인 제약이 포함된다). 이것의 예는 Contraint Statement 섹션에서 찾아볼 수 있다.

policy 언어에는 MLS과 같은 분야를 지원하기 위해 많은 다양한 contraint statement가 존재한다. (Constraint Statement와 MLS Statements 섹션을 보라)