5.3.1. Common AV Rule Syntax
비록 각각의 AV 규칙은 다른 목적을 가지지만 그들은 똑같은 기본 문맥을 가진다.
그리고 각 5개의 원소를 포함한다.
- Rule Name
: allow, dontaudit, auditallow, 또는 neverallow
- 소스 타입 ( source type )
: 접근이 주어질 타입, 대개 접근이 시도되는 프로세스의 도메인 타입을 말한다.
- 타겟 타입 ( target type )
: 접근이 주어질 소스 객체의 타입
- 객체 클래스 ( object class )
: 접근이 허용되어진 것에 대해 명세한 객체의 클래스
- 허용 ( permission )
: 객체 클래스 나타내기위한 타겟 타입이 허용한 소스의 허용 권한에 대해 명세한다.
단순한 AV 규칙을 가진 것은 소스타입, 타겟타입, 객체 클래스, 허용에 대한 정보를 가진다.
아래의 allow 규칙을 통하여 AV 규칙과 같은 많은 예를 볼수 있다.
allow user_t bin_t : file execute;
이 allow 규칙은 source type 인 user_t, target type인 bin_t, object class인 file, 그리고 permission에 해당하는 execute가 있다.
이 규칙을 간단히 풀이하자면 " bin_t타입의 파일들을 user_t 타입이 실행하도록 허용한다. "
그외의 다른 4개의 av 규칙또한 정확한 같은 문맥을 가진다.
예) auditallow user_t bin_t : file execute;
AV Role에서의 속성 사용 ( Using Attribute in AV Rules )
이때까지 우리는 type을 선언함에 있어 source type과 target type을 써서 선언을 했다. 하지만 AV Rules에서 속성을 사용하여 멀티 타입을 이용하는 방법
도 있다. 예로 가령 exec_type이라는 일반 유저 프로그램에서의 모든 파일과 접근하는 속성을 정의하고 우리는 bin_t같은 명백한 타입보다 앞에서 언급했던
exec_type 속성을 사용할 수 있다. 다음을 보자
allow user_t exec_type : file execute;
앞의 예와 같지 않다. 이 규칙은 커널에 의해 직접적으로 반영되지 못한다. 속성을 포함하고 있는 규칙은 속성과 함께 결합되어 있는 각 타입을 위한 분리 키안 커널 내부로 확장이 된다.?? 만약 20개파일 타입이 exec_type속성과 결합되어 있다면 커널 AVC는 아마도 20개의 키를 규칙과 결합할 것이다.??
우리는 또한 속성을 AV rule의 소스로써 또는 rule의 소스와 타겟 양쪽으로도 이용할 수 있다 예를 들어 가령 우리가 domain이라는 모든 domain 타입( user_t 포함 ) 과 결합된 속성을 만들고 그 모든 domain 타입이 file_type속성을 가진 파일 타입을 실행하고 싶다면 다음과 같이 작성할 수 있다.
allow dimain exec_type L file execute;
규칙의 더 좋은 확장성에 대한 설명을 하자면 가령 우리의 정책이 user_t와 staff_t타입을 가진 domain속성과 bin_t와 local_bin_t와 sbin_t의 파일
타입을 가진 exec_type속성이 결합된다면 위의 단순한 규칙은 다음과 같은 명백한 규칙과 동등한 의미를 가진다는 것이다.
allow user_t bin_t : file execute;
allow user_t local_bin_t : file execute;
allow user_t sbin_t : file execute;
allow staff_t bin_t : file execute;
allow staff_t local_bin_t : file execute;
allow staff_t sbin_t : file execute;
AV rules에서의 멀티 타입과 속성 ( multiple types and Attributes in AV Rules )
AV_Rules에서의 소스필드와 타겟필드에서의 싱글 타입 또는 속성의 쓰임에 제한은 없다. 다 나아가 차라리 우리는 멀티 타입또는 멀티 속성을 쓸 수가 있다.
하나의 타입 또는 속성보다 더 존재할 경우 다음과 같이 쓸 수 있다.
allow user_t { bin_t sbin_t } : file execute;
이 규칙에서 타겟은 bin_t과 sbin_t 양쪽이 된다.
또한 우리는 소스필드에서도 다음과 같이 쓸 수 있다. 다음 예는 타겟필드와 소스 필드에서 같이 혼합하여 멀티 선언한 것이다.
allow {user_t domain} {bin_t file_type sbin_t} : file execute ;
특별한 타입 self
정책언어는 self라는 정해진 단어가 있다. 이는 하나의 AV_Rule의 타겟 필드에서 쓰일 때 한 타입과 같은 역활을 한다. 예를 들어보자
밑의 예의 두 규칙은 서로 같은 뜻이다.
allow user_t user_t : process signal;
allow suer_t self : process signal;
self라는 키워드는 단순히 각 소스타입을 위한 한 규칙을 대신하여 쓴다는 것을 의미한다. 그래서 이 소스와 타겟 필드의 내용은 같은 것이 되는 것이다.
다음 예를 보자
allow {user_t staff_t} self : process signal;
이 예에서 두개의 정책이 만들어 졌다. 이 규칙은 다음 예의 규칙과 동일하다.
allow user_t user_t : process signal;
allow staff_t staff_t : process signal;
self는 source필드의 자기 자신과 관계가 있다. 특별히 user_t가 staff_t에 접근이 허용되지는 않는다. 그 반대도 그렇다.
self는 특별히 속성, 많은 양의 타입 리스트, AV rule 의 소스로써의 속성에서 가치를 지닌다. 예를 들어 우리가 모든 domain에게 자기 자신에 대해서만 signal할수 있도록 하고 싶다면 우리는 아마도 이런 식으로 작성할 지도 모른다.
allow domain diamin : process signal;
비록 이 규칙도 우리가 원하는 결과를 가지고 오지만 이 또한 모든 도메인끼리의 signal할수가 있다. 이 것은 보안상 좋지 않다. self를 씀으로써 우리는
각 도메인 타입에서 자기 자신에게만 접근을 허용할 수 있도록 보장해 준다.
allow domain self : process signal;
The Negation Special Operator
AV rules에서 타입을 위한 마지막 문맥은 타입 취소이다. 이 문맥은 주로 타입의 리스트와 규칙에 주어진 속성으로부터 타입을 제거할때 주로 쓰인다.
- operator를 이용하여 사용이 되며 타입 이름의 처음에 위치하게 된다. 예를 들어 우리가 sbin_t 타입을 제외한 exec_type 속성을 가지고 그 타입의 파일을
실행하고 싶다면 다음과 같이 작성하면 된다.
allow domain { exec_type -sbin_t } : file execute;
이 규칙은 exec_type 속성이 마치 sbin_t 타입을 포함하지 않는 것 처럼 동작 될 것이다.
타입 취소에 대한 문법은 순서에 의존적이지 않다.
allow domain { -sbin_t exec_type } : file execute;
Specifying Object Classes and Permissions in AV Rules
AV rules는 또한 Permissions와 Object classes 의 리스트를 포함할 수 있다.
예를 보자
allow user_t bin_t : { file dir } { read getattr };
이 규칙은 결과적으로 두 키를 가지며 다음의 규칙과 같은 의미를 가진다.
allow user_t bin_t : file { read getattr } ;
allow user_t bin_t : dir { read getattr };
맨 위의 문법을 쓰면 간편하지만 이 것은 또한 file과 dir인 두 object classes에게 모두 permissions이 허용된다는 의미가 된다.
만일 두 object중 dir이 search에 대한 권한을 부여한다면 우리는 두 규칙을 사용하여 작성해야 할 것이다.
만일 아래와 같이 규칙이 작성된다면...
allow user_t bin_t : { file dir } { read getattr search };
file object class에게도 serach의 권한을 부여하게 됨으로 좋지 않다..
그러면 어떻게 해야할까? 다음과 같다..
allow user_t bin_t : file { read getattr };
allow user_t bin_t : dir {read getattr search };
Special Permiision Operators for AV Rules
우리는 Permissions 리스트를 작성함에 있어 2개의 특별한 operator를 사용할 수 있다. 첫번째는 * operator이다
이것은 object class를 위한 모든 권한을 줄 때 사용된다. 예를 보자
allow user_t bin_t : { file dir } *;
두번째는 ~ operator이다 예를 보자
allow user_t bin_t : file ~{ write setattr ioctl };
컴파일 할때 이 규칙은 write, setattr, ioctl을 제외한 파일의 객체 클래스를 위한 모든 permissions을 허용해 준다.
5.3.2. Allow Rules
앞에서 배운 allow라는 권한 설정 규칙에 대한 예는 Selinux 정책의 가장 첫번쨰 목적을 구현하는데 가장 일반적인 것이다.
여기서 allow라는 규칙은 실행동안 주어질 모든 권한에 대한 명세를 말한다. 이것은 오직 Selinux 정책안에서만 권한이 허용되는 의미이다.
한가지 기억할 것은 비접근은 예외로 되어 있다는 점이다. 예를 보자
allow user_t bin_t : file { read execute };
이 예에서 우리는 user_t는 bin_t 타입의 파일에 대하여 write할 수 없다.
5.3.3. Audit Rules
Selinux는 기록이나 검사(감사), 정책에 의해 허용되었거나 거부된 접근시도에 대한 광범위한 기능을 가지고 있다. 이 감사 메시지를 종종 AVC message라고 부른며 접그시도가 허용되었거나 거부되었거나 또는 소스나 타겟의 보안 문맥, 그리고 접근 시도에 포함된 자원에 대하여 세부정보를 제공한다.
다른 커널 메시지나 /var/log에 로그파일로 저장된 것과 유사한 이 메시지는 정책개발, 시스템 관리, 시스템 모니터링을 위해 없어서는 안될 도구이다.
이 Chapter에서 우리는 접근시도가 메시지로 만들어져 형성되는 정책 형태에 대해 알아 볼것이다. 파트 3에서는 메시지가 디버깅과 정책의 이해에 어떻게
이용되는지에 대해 더 많은 정보를 제공한다.
예외적으로 Selinux는 허용된 것에 대한 접근체크에 대해 기록하지 않는다. 그러나 거부된 것에 대해서는 기록을 한다. 놀랄일은 아니다. 거의 모든 시스템에서
수천개의 접근들이 매초마다 허용되어진다. 그러나 몇몇의 접근들이 거부된다. 접근에대한 접근정보는 이미 기대되어졌던 것이기 때문에 감사 요청을 하지 않는다. 거부된 접근은 종종 일어나지만 기대치 않게 항상 일어나는 것이기도 하다. 이것들에 대한 감사작업은 정책 버그나 침입 시도인지를 모니터하는 관리자를
도와주는 것이다.
SElinux는 접근시도에 대하여 감사되도록 하는 컨트롤에 대한 두개의 AV Rules를 허용한다. dontaudit와 auditallow이다.
dontaaudit 규칙은 가장 일반적으로 사용된다. 이것은 감사되어지지 않아야 한다는 접근거부에 대한 명세를 나타낸다..??
예를 보자
dontaudit httpd_t etc_t : dir search;
이 규칙은 httpd_t타입의 프로세스들이 etc_t타입의 디렉토리에 search에 대해 거부되어질 때에 대한 명세를 한다. 이규칙에 의하면 거부되어질때 감사작업
을 하지 말라는 의미이다. dontaudit규칙은 우리가 기대하고 있던 거부에 대한 감사(검사)를 덮어버리고 싶을 때 사용된다. 그리고 이 규칙은 우리에게
불필요한 접근이 주어지는 것을 피할수 있도록 해준다.
다른 audit(감사,검사) 규칙은 auditallow이다 이 규칙은 접근시도가 허용된 것에 대한 감사에 대하여 컨트롤 할 수 있도록 해준다. 거부된 접근과 다르게
허용된 접근은 예외적으로 기록되지 않는다. 예를 보자
auditallow domain shadow_t : file write;
이 규칙은 domain 속성이 shadow_t 타입의 파일에 write접근을 성공적으로 획득했을때에 대하여 접근 허용에 대한 감사를 명세를 하고 있다.
auditallow 규칙은 주로 중요한 보안 이벤트를 가진 접근에 대해 감사를 실시한다.
shadow password파일에 쓰이는것이 포함된 auditallow 규칙을 가진 접근이나 커널에 새로운 정책이 실리는 것에 대한 예가 있다.
기억하자! audit 규칙은 예외적으로 있는 검사에 대한 세팅을 할 수 있도록 한다. allow 규칙은 접근이 허용되는 것에 대한 명세를 하고
auditallow는 접근허용이 아닌 오직 권한이 허용된 것의 감사를 할 수 있도록 해주는 것이다.
5.3.4. Neverallow Rules
AV Rule의 마지막 규칙은 neverallow 규칙이다 이 규칙은 allow규칙에 의해 절대 허용되지 않아야 하는 확실한 접근들에 대한 명세이다.
이 규칙의 존재이유는 예외에 의해 접근이 거부되기 때문이다. 즉 확실히 허용되기를 바라지 않는다고 하지 않은 것에 의해 정책이 설정되고
그 때문에 우리의 정책내에 그 허용들의 사고적인 포함을 막는다.
neverallow 규칙은 이러한 상황을 막아주는 것이다. 예를 보자.
neverallow user_t shadow_t : file write;
위의 규칙은 컴파일 에러에 의해 user_t 타입에 shadow_t 타입의 파일을 쓰는 규칙을 정책에 추가하는 것을 막아준다.
이 규칙은 접근을 제거하는 것이 아니라 단지 컴파일 에러를 내 주는 것이다. 이 규칙은 allow규칙을 쓰기 시작하기 전에 우리의 정책에 대하여 중요한
것이다. 그리고 이 규칙은 우리가 의도하지 않았던 허용에 대해서 막아주는 역활도 한다.
neverallow 규칙은 다른 AV Rules에서는 할 수 없는 어떤 추가적인 문맥이 있다. 특별히 neverallow 규칙에서의 소스와 타겟타입의 리스트에서는
wildcard(*)와 complement(~) operator을 포함할 수 있다. 예를 보자!
neverallow * domain : dir ~{ read getattr };
이 규칙의 상태는 domain 속성과 결합된 타입들의 하나와 연결된 디렉토리에 read와 getattr접근을 제외한 나머지 permission의 접근을 허용치 않는다는
의미이다. 여기서 *operator는 neverallow 규칙의 source타입에서 필요하다는 것이다. 왜냐하면 앞에서 언급했듯이 일부 또는 모든 타입들이 아직
생성되기 전이기 때문이다. 앞에서 우리는 allow전에 neverallow을 한다고 했다..(7줄 위에..언급)
다른 일반적인 neverallow 규칙의 예를 보자.
neverallow domain ~domain : process transition;
이 규칙은 이 Chapter앞에서 설명한 domain속성의 개념을 보충해주기 위한 것이다. 이 규칙의 상태는 프로세스는 domain속성을 가지지 않은 타입과 transition할 수 없다는 의미이다. 이것은 domain속성을 가지지 않은 프로세스를 위해 타입이 설정되는 정책을 만드는 것이 불가능 해지게 한다.
Rss Feed