Access Control MAC (2)

이전 DAC의 문제점

---

주체는 중요한 정보를 위부로 유출 시키지 못하게 하여야함.

->어떤 객체에 대해 접근 권한을 가진 주체가 그 객체안에 포함된 정보를 그 객체에 접근 할 수 없는 주체에도 유출 시킬 수 있다.

객체 안의 정보의 의미를 고려하지 않는다. => 객체들 마다 보안에 대한 민감도가 있는 데, 민감도를 표현할 수 없다

e.g open가능한것, A만 볼 수 잇는것, 이사만 볼 수 있는것

 

왜 새로운 접근 제어 모델이 리눅스에서 필요한가?

- 유저가 멀웨어를 실행하면 기밀성과 무결성이 위협받음.

- DAC는 위와 같은 공격에 대해 방어가 불가능하다.

 

따라서 시스템 전반적이고 세부적인 접근제어가 필요하다.

 

만약, local 컴퓨터에서는 읽고 쓰기가 가능하지만 네크워크를 통한 읽기나 쓰기를 막으려면? DAC는 불가능하다.

따라서 MAC이 도입

 

만약 사용자 A가 웹서핑도하고, 레포트도 작성하며, 방화벽을 관리하듯이 다양한 역할을 가질 때?

DAC에서는 어렵다. 어떤 사용자는 owner가 되고 group에 속함 => 다양한 역할을 가지기 어렵다.

 

개인(user) 중심으로, 개별자 중심으로 접근제어를 하기 때문에 다양한 역할에 대한 고려가 부족하다.

따라서 RBAC이 도입

 

 

Mandatory Access Control

운영체제(실질적으론 관리자)가 주체의 능력을 제한 시키는 것이다.

(주체가 어떤 객체에 대해서 어떤 연산을 할 수 있는 지 결정)

 

SELinux는 리눅스에서 돌아가는 보안 프레임워크 중 하나이며, MAC을 집행할 수 있다.

 

DAC => ACL

MAC => SELinux

 

- 전역적인 보안 정책을 집행한다. => 모든 유저에게 (중앙집중식임)

 

- 신뢰되는 관리자가 보안 정책을 정의한다. => 어떤 프로세스가 어떤 파일들을 접근할 수 있는지 혹은 어떤 방식으로 접근 할 수 있는지 나타낸다.

- 접근은 시스템에 의존(kernel governs all access)

 

- 개별 사용자는 이러한 정책에 대해 disable 불가 <=> DAC와 다름, DAC는 소유자가 자기 자신의 파일에 대해 재량권이 많았음

 

- 정책보다 약하게 제어설정이 불가하다.

 

- 객체의 민감도(정보의 민감도)에 따라 객체에 대한 접근을 한정시킨다.

 

- Authorization은 어떤 조건이 만족된다는 필수조건에 근거한다.

 

 

- 관리자만이 보안 정책을 정의할 수 있고 집행할 수 있다. 개별사용자는 그 정책을 무조건 따라야한다.

따라서 보안상 굉장히 안전

=> system이 정책을 정의하므로

 

결론적으로, 오로지 관리자(커널)이 정한 정책을 따르고, 사용자들이 자기 자신이 생성한 자원에조차도 완전한 통제를 할 수 없도록함.

 

DAC와 MAC을 비교하면,

 

DAC:

주체의 재량에 따른다.

다른 주체에게 권한을 줄 수도 있다. (Identity based access Control(IBAC))

 

단점

군대와 같이 user identity와 ownership에 근거한 결정일 경우 부적합

악의적인 소프트웨어에 대한 보호기법이 없다.

각각 사용자가 자신의 객체에 대해 완전한 재량을 가진다.

사용자 주요카테고리가 2개이다. (superuser, other)

superuser가 아니면 시스템 서비스나 특권프로그램이 coarse-grained privilege로 동작한다.

 

MAC : (보안 강함)

운영체제에 의해 통제된다. (Rule-based AC or Policy based AC)

객체에 대한 접근을 통제하는 것은 시스템이 정한 방식임(객체의 민감도나 사용자 승인 여부로)

객체와 주체를 잘 분리해야한다.

자원에 대한 접근이 시스템, 관리자가 정한 보안정책에의해 관리된다.

Strong seperation of security domains (Security domain 은 subject 와 object의 집합 (collection) 으로 같은 보안 정책을 공유하는 도메인이라고 볼 수 있다.)

시스템과 데이터 무결성 제공

변조에 강인한 보호기법(우회도 되지않음)

프로그램에 대한 권한 제한제공

적법한 사용자가 할 수 있는 일 제한가능

 

MAC은 다양한 모델과 연결된다. (multi-level security(MLS) Policy와 같은)

최근 시스템은 유연한 seucrity model들을 제공한다.

 

Security Frameworks

 - SELinux : Security Enhanced Linux on Centos, Red Hat

    SEAndroid

 - AppArmor : Application Armor on Ubuntu, SuSE Linux

 - SMACK : Simplified MAC Kernel on Tizen

 - tomoyo Linux

 

 

 

System Defined Policy

- 고정된 집합의 주체, 객체 lable => 주체나 객체에게 lable이 붙여짐. (e.g 객체일 경우 top secret - secret .....)

- 고정된 개수의 허가할당

- 고정된 label 할당 (e.g file to object label)

- 전이 방식 고정(e.g setUID)

allow user_t(주체) passwd_exec_t:file(객체) execute(operation)

=> 주체는 객체에 대해 실행할 수 있다.

각 문장은 접근 정책이며 3번째 줄을 보면 read/write/exeute에서 getattr, search, lock, ioctl와 같이 접근제어가 세분화 된 것을 알 수 있다.

주체도 owner/Group/Others에 비해 세분화 되었다. 따라서 관리도 더 어려워졌다.

위의 정책을은 SELinux가 활성화 되면 적용이 된다.

- sestatus : SELinux가 활성화 되었는지 확인

- ls -l /etc/selinux : SELinux 설정파일 확인 => SELinux가 설치되어있는지 확인

- getenforce : SELinux disable/enable 확인

- cat /proc/version : /proc/version파일에는 운영체제명, 커널버전, gcc컴파일버전, 생성한 날짜 등 정보 볼 수 있음

- cat /etc/*release : 리눅스 os버전 확인

/etc/selinux/config : SELinux 설정파일 내 SELINUX가 disabled 되었으므로 getenforce할 경우 disabled로 나타남

SELinux 설정

• enforcing

• permissive

• disabled

SELinuxType

• targeted

• minimun : only selected process are protected

• mls : MAC을 나타내는 대표적인 방법중 하나 (DAC 구현시 Capability list와 Authorlization tabel 같이)

 

SELinux Enable

sestatus로 SELinux의 동작모드를 확인 할 수 있다.

 

-z는 SELinux와 관련 있는 옵션이다. SELinux의 보안 문맥을 보여준다.

 

 

 

MAC and Security Policy

----------------

 

보안 정책은 시스템의 상태가 안전한 상태인지 아닌지 나타내는 문장이다.

보안 정책 모델은 정책들의 집합이며, 보안 모델이 따라야하는 룰들의 모음이며, 시스템이 가져야하는 보호 특성을 나타내는 간결한 문장이다.

 

정책의 3가지 분류

1. 기밀성 정책

2. 무결성 정책

3. 가용성 정책

(Allow/ Deny)

 

MAC은 주체와 객체의 레벨에 기반한다. (레벨은 미리 정한다.)(e.g top secret - secret - confiedntial, classified)

 

MAC pattern => multilevel security model = lattice model

MAC pattern은 DAC 문제들(계층적인 구조환경에서 생길 수 있는 문제들)을 해결가능하다 (security level을 할당하여서)

 

 

Information Flow Control

한 객체 안에 있는 정보가 다른 객체로 어떻게 흘러갈 수 있는지 나타낸다. (정보는 객체(file)에 있다)

주체들이 class와 결합하여 일을 한다.

보안정책, 보안 class는 한번 설정되면 잘 변하지 않는다.

 

The Lattice Model

잘 알려진 Information Flow Model이다.

부분적으로 순서가 있는 집합구조를 가지게됨

일반적으로 방향이 있는 비순환 그래프로 표현됨

처음 출발지는 하나 끝나는점도 하나이다.

정보가 낮은 클래스로 부터 높은 클래스로가는것은 허용함

 

보안 정책 모델

1. Multilevel Security(MLS)

  lattice기반의 정보흐름 모델의 특별한 경우임.

  보안등급 : Unclassified -> Confiedntial -> Secret -> Top Secret

  clerance level(승인 레벨) : 주체는 허가 레벨을 가짐

  Classification level : 객체(민감한 정도)

     --> DAC에선 표현 불가

  

  모든 객체와 주체는 Security Level로 라벨되어 있음

     Sensitivity : 계층적 속성 (Unclassified -> Confiedntial -> Secret -> Top Secret)

     Category : 비 계층적 속성(e.g US only, UN, 00과에서만 봐야한다.(범위, 지역적인 것을 나타냄)) 

 

  MLS는 다시 두가지로 나누어짐

  1. Bell-LaPadula Model(BLP) => 기밀성에 중점

      No read up(높은 정보 read X), No write down(등급 낮은 객체 write X)

      => No read up : 객체 level <= 주체 레벨, 주체는 객체를 읽을 수 있음

      => No write down : 주체 level >= 객체 레벨, 주체는 객체에 쓸 수 있음

 

B,C,D read가능

A read불가 write만 가능

B read/write 가능

 

=> 객체와 주체가 같은 label이면 읽고 쓰기 가능

=> 객체가 주체의 label보다 위면 쓰기만 가능

=> 객체가 주체의 label보다 밑이면 읽기만 가능

(군대와 유사)

 

=> 등급이 같고 카테고리도 같음 = read, write

=> 등급이 높고, 카테고리 같음 = read

=> 등급이 낮고, 카테고리도 다름 = X

=> 등급이 낮고, 카테고리 같음 = write만

A의 level이 더 높고 더 큰 카테고리를 가지고 있으면 A,C 는 A',C'를 dom함

 

  2. Biba Model => 무결성에 중점, 권한이 높은 사람만이 정보변경가능

       no write up, no read down

       자기보다 높은 등급 write 불가,

       자기보다 낮은 등급 데이터 신뢰x

       => 높은 등급은 낮은 등급의 객체를 쓸 수만 있다.(무결성, 높은 사람만 정보변경가능)

       => 낮은 등급은 높은 등급의 객체를 읽을 수만 있다.(낮은 등급 데이터 신뢰 X)

 

 

2. Domain Type Enforcement(DTE)

  주체들은 Domain을 가지게 되고, 객체들은 type을 가짐.

  어떤 주체가 어떤 Domain에서 어떤 type의 객체를 어떻게 접근할 수 있는지 집행(강제로)

 

   주체 - 도메인 =>주체에 할당되는 label

   객체 - 타입 => 객체에 할당되는 label

    

   도메인이 어떤 타입을 어떻게 접근할 수 있는지 정의

   주체들은 접근할 수 있는 객체들에 대해서 type이라는 형식으로 나타냄

   어떤 접근이 어떤 객체에 대해서 허용되는지 모델링하는 방식

 

 

주체에 대해서는 도메인(label 붙임)이 할당됨, object는 type 

위 그림은 Type Enforcement이다. 

TE에서는 주체 객체 둘다 Type이다.

 

- 각 객체는 type으로 할당된다.

- 유사한 type의 객체들을 class로 묶는다.

  e.g file, socket, ipc channel, capability

 

- Process는 도메인과 연결된다.

httpd_t, sshd_t ~~~ : 주체에게 해당되는 도메인

 

- rule은 도메인과 타입사이의 권한을 정의한다.

주체 : httpd_t

객체 : httpd_config_t:file

operation : read, getattr, lock, ioctl

 

모든 파일들은 보안 정책에 따라서 타입을 가지게 된다. 어떤 type은 어떤 lable을 접근할 수 있는지 컨트롤한다.

새 객체에 대한 타입은 도메인에 기반하여 lable이 붙여진다.

 

 

Type Enforcemnet 장점

- Application separation - 운영체제의 기능 중 하나

- 슈퍼유저 특권 조절

- 최소권한 원칙

- 시스템콜에 대한 접근을 컨트롤 할 수 있다. ex) ioctl 같은

 

DTE 는 TE의 향상된 버전이다.

 

=> system call에 대한 통제 가능 (기존 DAC는 r/w/x)

=>같은 도메인이더라도 각 타입이 다름 객체에 접근할 수 있는 방식은 다 다름 => 분리가 잘 되어 잇음

 

 

=> entrypoint : 도메인이 변환 될 수 있음, transition이랑 같이 씀

=> user_t에서 passwd_t 도메인으로 변환 가능

-> passwd_exec_t 타입의 객체를 실행함으로써 user_t에서 passwd_t 도메인으로 변환 가능 (DAC에서 setUID 프로그램과 유사)

 

 

DTE : 

  암묵적인 typing 지원

  type문장은 하나 이상의 type을 선언할 수 있다.

  주체에 대해선 도메인을 붙임. e.g bin/sh => 객체이면서 주체가 될 수 있음

  Assign statements : 어떤 객체에게는 type 할당가능, 어떤 주체에겐 도메인 할당 가능

 

active entity => domain

passive entity => type

 

entry point 프로그램을 실행함으로써, 한 도메인에서 다른 도메인으로 전이가 가능함.

 

 

-----------------------------------------------------------------------------------------------------------------------------------Security:

 - 루트 프로세스에 대해 접근 제어 (DAC보다 강력한 보안 제공, 루트가 모든것을 하진 못함)

 - 네트워크 daemon들도 제어 가능

 - 시스템 프로세스 보호가능

 - 커널도 보호 가능

 

usability

 - 시스템이 보안 정책을 구동할 수 있도록 enable 시킬 수 있다.

 

일반적으로 MAC은 제한적임. 사용하기 어렵고 불편하다.

 

 

정리

 

장점

 - 트로이 목마 공격 막을 수 있음 (DAC는 정보흐름 통제 어려우나 MAC은 가능)

 - 사용자: 도메인, object: type 중재자(신뢰할만한 사람 = 장단점이 됨)에 의해 중앙집중식으로 함

 - security level에 따라 접근제어 정책 집행(특히 MLS에서는 보안 레벨에 따라 )

 

단점

 - 새로운 사용자/객체가 들어올때 마다 classification을 잘 해야, MLS같은 경우 카테고리도 잘 정해 주어야함=>룰 충돌, 헛점 발생 가능