Access Control & DAC (1)

Access Control

• 접근제어에는 주체(유저, 프로세스 등), 객체(파일, 디렉토리 등), 권한이 있다.
• 주체가 객체를 어떻게 접근(권한)할 수 있는지 정의하는 것이 접근제어이다.
  (active한 객체가 passive한 객체를 어떤 형태로 접근하는지 통제하는 기능)

Subject ----> Object
           ^
            |
Access

• Subject : active한 entity 로 객체나 객체안의 데이터에 대한 접근을 요청함 (유저, 그룹, 프로그램, 컴퓨터..)
• Object : passive한 entity로 정보를 포함하고 있다. (파일, 디렉토리 메모리, IPC ...)
• Access right : operation(read, write, append ....) = Permission

|참고|

파일의 정보는 inode에서 관리함  
하나의 파일에는 최소 하나의 inode가 존재하며, 하나의 inode가 여러개 이름이 연결되면 Hard link(바로가기 유사)이다.  
active한 inode는 하나의 파일만 연결되어있다.  
파일이 많은 경우 디렉토리로 관리한다. => 같은 부류의 파일들을 같은 디렉토리로 구분하고 어떤 사람이 접근할 수 없는 디렉토리를 만들 수 있음.

SetGID  
해당 파일의 소유자의 그룹의 권한으로 실행함.

Sticky bit  
설정된 디렉토리 밑에 누구나 파일 생성이 가능함.  
해당 파일을 이름을 바꾸거나 이동하거나 삭제하는것은 소유자나 root만 설정 가능하다.

Super user  
접근 제어에 대한 제약이 없다.

• 자원에 대한 인가되지 않은 사용을 막는다.

|-------------------------Auditing(기록 남김)-------------------------------|
User ---> Authentication function ---> Access Control Function ---> Resource
                                              ^                                     ^
                                              |                                       |
                                           인증                              접근 제어
                               (id/pw , 공인인증서 등)

• Access control은 사용자가 본인이라고 가정한다.

• 인증 과정은 접근제어 앞단에서 필요하다.

• Authorization : 주체가 접근제어 정책에 따라 자원에 접근할 수 있는지에 대한 판단

• Access : 주체와 객체 사이의 정보의 흐름

Access control이 필요한 이유?

• 기밀성, 무결성을 지키기 위해서
• 사용자가 비의도적으로 중요한 시스템 파일을 일거나 변경 하지 못하게 해주거나
• 사용자가 비의도적으로 중요한 개인 파일에 대한 변경을 막아줌
  • 기밀성 = no read
  • 무결성 = no write

Access Control Requirements

1. 신뢰되는 입력
   접근 시스템 앞단에 인증 기법이 필요하다. 인증 기법(사용자 인증)을 통과한 주체만이 접근제어의 대상이 된다.

2. fine, coarse specifications 지원
   coarse => 크기가 큰 단위로 접근제어 수행 (초기 리눅스는 r/w/x)
   fine => 크기가 작은 단위로 접근제어 수행

3. least privilege 최소권한
   업무를 하는데 필요한 최소권한만을 준다.

   • 일을 하는데 필요한 권한만 가저야한다.
     Ring구조는 HW적으로 최소권한을 제공해준다.

   • SetUID 프로그램들을 적게 만들어야한다.
     SetUID 프로글매이 취약시 문제가 커진다.

   • Need to know
     주체가 일을 하는데 객체에 대한 접근이 필요없다면 권한이 없어야한다.
     만약 append를 해야한다면 write권한이 아닌 append 권한만 주어야한다.
     => fine specification

4. Separation of duty
   중요 업무를 처리하는 절차를 여러 단계들로 나누고, 각 단계를 서로 다른 주체가 자신의 권한으로 책임지게 한다
   • 거짓행위나 오류를 방어하는것이 목적

5. open and closed policies
   closed policy : default 접근 허용하지 않고 명시된 접근만 허용한다.명단에 적힌 주체만 허용한다.
   open policy : default는 접근 허용 단 명시된 접근은 불허(블랙리스트와 유사)

6. policy combinations and confilct resolution
   여러개의 접근 저책이 하나의 자원에 적용될 수 있음.
   한 자원에 대한 접근 권한 충돌이 날 수도 있음. 따라서 충돌이 발생되지 않게 해야함.

7. 관리적 정책
   보통 super user만이 가능하며, 어떤 주체가 어떤 규칙을 만들거나 삭제, 수정가능한지 명시

8. dual control
   일을 할때 둘 이상의 주체가 동시게 관여해야한다(특히 중요한일)

• SOD = 2개 이상의 서로 다른 step에 대해 각각 다른사람이 수행

• dual control = 한 step에 대해 2 사람 이상이 관여

• BSD에선 root 계정을 가지게 된다면 1. root 비밀번호를 알고 있으며, 2. wheelgroup(GID = 0)이어여 한다.

=> 접근제어는 어떤 주체가 어떤자원, 어떤객체를 접근할 수 있는지 나타낸 것이다.

-> 비인가 사용자의 자원에 대한 접근을 막는다.

-> 적법한 사용자가 비인가된 방법으로 자원에 대해 접근하는 것을 막는다.

Access Control Models

1. DAC : 임의 접근 제어
   owner가 알아서 함. 임의로 권한을 주었다 뺏었다 가능

2. MAC : 강제 접근 제어
   관리자나 super user가 제어 통제한다.
   (e.g 군대 행정병(ovwner)이 문서를 썻다고 해도 마음대로 하지 못한다.)

3. RBAC : 역할 기반 접근 제어
   역할에 따라 접근 제어
   (e.g 사원, 대리, 과장)

DAC

---

Discerionary Access Control

• 자원의 소유주가 주체들이 객체에 접근할 수 있는지 임의대로 정한다.
  객체의 owner가 객체에 대한 허가를 가진다. => UID 기반으로 접근에 대한 허가, 일반적인 사용자가 접근제어 정책을 조정할 수 있음.

• 사용자 신원과 객체의 소유권, 권한 위임에 기반하여 접근제어를 강제한다.

• DAC는 security(인터넷이 연결되고 악의적 공격에 방어)보다 protection(멀티유저 - 비의도적 문제방어)에 집중

• 사용자들은 악의적이지 않고 프로세스(악의적인 프로세스가 아님)는 신뢰한다고 가정함.

• DAC Model = Access Matrix Mdel = Access control Matrix Model

(* 디렉토리 read = 접근 가능(들어감), execute = 검색 가능)

• Access Matrix는 빈공간이 많을 수 잇으므로 리스트 형태나 희소행렬 형태 등으로 나타낸다.

1.  Access Control List => ACL : 객체 중심

    -   접근 할 수 있는 사람을 지정  
        \=> 새로운 사람 추가, 권한 위임 다른 사람에게 불가능, 사람 인증해야함

    -   장점 : 접근 가능한 객체 집합의 경계가 지정되지 않음. => object가 새로 생기면 이름을 붙이고 권한을 지정해줌.

    -   단점 : 웜, 바이러스 백도어, 스택 오버플로우, 큰 ACL을 사용할 경우 overhead가 큼, 분산환경에서 확장하기 어려움(  
        사진=>그룹의 사용자 수가 적고, permission bit 가 작으면 ACL이 편리

2.  Capability List : 주체 중심

    -   키를 나누어 키를 가진 사람이 접근 할 수 있게 함  
        => 새로운 사람 추가는 키를 나누어주면됨, 키를 주면 다른사람에게 권한이 위임됨, 키를 돌려받기 어렵고 복제할 수 있음
    -   장점 : 최소 권한 원칙지키기 쉬움 =>주체가 접근할 수 있는 객체들만 나열해서 관리, 확장하기 쉬움(티켓만 확인) => 분산 환경에서 쓰기 좋음(분산환경은 한번만 인증하고 여러 서버에서 접근함)
    -   단점 : 접근 가능한 객체 집합의 경계가 지정됨. => 통제됨

 3. Authorizaion Table
     - DB에서 많이 씀



4. Protection Domains
    - 주체 중심으로 봄, 주로 프로세스
    - 어떤 프로세스가 어떤 객체를 어떻게 접근할 수 있는지 표현한 집합
    - 어떤 프로세스가 어떤 일을 요청할때마다 관리해야할 정보의 양을 줄일 수 있음 => 상속을 하므로 (fork - 부모가 연 파일을 자식이 상속받아 사용가능)
    - 역할 기반으로 protection domain 사용 가능
    - 어떤 프로세스가 접근할 수 있는 자원들의 집합
    - access matrix에선 하나의 행이 protection domain을 정의함
    - capability와 연결되면 protection domain 개념과 가까움(ACL보다 capability가 protection domain 개념에 가까움)
    - 사용자는 프로세스를 생성 하는데, 새 프로세스는 사용자가 갖는 권한의 부분집합을 가지게 됨, 하나의 protectino domain이 생김 => 어떤 프로세스가 접근할 수 있는 자원들의 집합이기 때문에
    - 프로세스가 사용자 모드일 경우 => 일반 명령어(자원 제한)
    - 프로세스가 특권 모드 => 특권 명령어(자원 제한 x)




5. Extended ACL
    - user/group/others 에 named user와 named group을 도입
    - named user와 group을 통제하기 위해 mask entry가 필요하다.
    - mask entry : named user, group이 가질 수 있는 최대 permission
    - 새로운 명령어들을 지원함.
    - getfacl : 확장된 ACL 정보를 가져온다.
    - setfacl : named user, group에 대한 ACL을 수정하거나 추가 => permission 추가
    - chacl : change acl of file or directory



- 임의의 수 naemd user, group이 하나의 파일과 연결될 수 있음. 따라서 추가적인 protection bit가 사용됨
     => 세분화 시켜서 특정인에게 named user라는 권한을 주고, group이 아닌 일반 특정인한테 특정 permission을 줌

 - 다양한 class => named user, group 추가됨

 - ACE => user나 group을 위해서 permission을 정의하는 entry들의 집합

 - ACL Caching을 하여 속도를 높이기도 함

  - 접근 체크
    1. 객체 중심으로 체크 => 소유주 인가? named user인가? 그룹인가? others인가? 체크
    2. 그 후 권한 할당

 

 

 

 * 장점

• 사용자/소유주가 스스로 접근 권한을 설정할 수 있어서 시스템 관리자의 부담이 작음
  • 개별 사용자의 접근제어, 그룹 단위의 접근 제어도 제공한다.
  • 권한 변경 쉬움 => chmod, setfacl, chacl
  • 새로운 권한 설정도 쉬움
  •  

• 단점

  • 소유주가 파일에 대해 전체적인 권한을 가짐 => 사용자를 절대적으로 신뢰
    • 사용자가 실행시킨 프로세스는 사용자의 권한을 가진다. (기본적으로 사용자의 EUID로 실행한다.)
    • 만약 사용자가 실행시킨 프로세스가 악성코드에 감염이 되어있으면 문제가 생긴다. 따라서 권한을 분리해야한다.
    • SetUID root 프로그램이 취약점이 있으면 문제가 생긴다.
    • 12개의 bit로 permission 관리시 문제가 있을 수 있다. 따라서 세분화 해야함.
    • 전역적인 접근제어 정책이 있다면, 그 전역적인 접근제어 정책에 대해서 일관성을 유지하는 것이 어렵다.
      => 병원 에서 환자리스트를 주치의만 접근가능하게 했지만, 다른 의사에게 위임이 가능하다. 따라서 전역적인 접근제어 정책 유지가 어렵다.
    • 정보가 한 객체로부터 다른 객체로 임의로 복사 할 수 있다.
      =>원본객체 소유자가 자신이 소유한 객체에 대해서 복제되지 않는 것을 원하지만, 소유자의 동의없이 임의로 복제가 발생할 수있다.
    • 정보흐름 정채긍ㄹ 정확하게 원하는 방향대로 집행하는데 적합하지 않다.
    • 주로 군에서 문제가 발생한다.

  =========================================================================
  만약
  파일 A => a가 소유하고 b가 읽을 수 있음
  파일 B => b가 쓸 수 있고, c가 읽을 수 있음
  => a는 c가 파일 A를 읽지 못하게 함.
  이러한 상황일때
  b가 나쁜맘을 먹고 파일 A를 읽고 파일 B에 쓸 수있다. 그러면 c는 A의 내용을 읽을 수 있게 된다.

  파일 A => a가 소유하고 b가 읽을 수 있음
  파일 B => b가 쓸 수 있고, c가 읽을 수 있음
  트로이 목마 => b가 실행할 수 있다. c가 r/w/x 가능

  b가 나쁜맘을 먹지 않아도, c가 트로이 목마를 만들어 b에게 주면 b가 자신의 권한으로 트로이 목마르 실행하게 되고
  A의 내용을 읽어서 B에 쓰도록 트로이 목마가 작동하면 c가 내용을 알 수 있다.

  ========================================================================

• 한계

  • 악성 프로그램 :소유주에 의해서 실행된느 악읮거인 프로그램이 그 소유주를 대신해서 DAC정책을 변경할 수 있다.
  • 결함이 있는 프로그램 : 취약한 SetUID 프로그램과 같이 취약점을 이용하여 DAC정책 변경 가능
  • 특정한 권한을 취소하지 않는 이상 그 권한을 제한 시키는 것은 어렵다
  • 사용자나 자원의 수가 증가할수록, 접근 권한을 관리하는 것은 복잡하고 어렵다.
  • 부여한 권한이 합리적인지 판단하기 어렵다
  • 접근 허가에 대한 개별적인 위임으로 인해서 접근제어 정책에 있어 불일치가 발샐할 수도 있다.(e.g 주치의만 환자리스트 접근가능 -> 다른 의사에게 위임)
  • 객체의 소유주가 모르는 어떤 사용자한테 접근이 허용될 수도 있다.
  • 권한을 한정시키는 수단이 비실용적임.