[Security] Capability 에 대한 이해

[Security] Capability 에 대한 이해

http://www.eros-os.org/essays/capintro.html

1. The Problem : Access Control

-

컴퓨터 보안의 기본 문제 중 하나는 프로그램에게 어떤 오브젝트에 접근할 권한을 주느냐이다.

오브젝트는 파일, 사운드 카드와 같은 하드웨어, 다른 프로그램, 네트워크 등이 있겠다.

Access 라고 함은 이 오브젝트들에 대해 어떤 operation 을 할 수 있게 할 것인가이다.

파일을 읽을 수 있게 할 것인가, 파일을 쓰거나 지울 수 있게 할 것인가, 다른 프로그램이랑 communication 할 수 있게 할 것인가 등.

-

Access Control 이라고 하면 주로 다음 4가지 중 하나를 이야기한다.

     Preventing Access - 접근 못하게 하기

     Limiting Access - 접근을 제한하기

     Granting Access - 특정인에게만 접근하도록 하기

     Revoking Access - 접근 권한 빼앗기

-

컴퓨터 세계에서는 Access Control 은 사람이 아닌 프로그램 기준이다.

이런 real world 와의 차이는 다음과 같은 고려사항을 만들어낸다.

     같은 사람이 다른 user id 로 로그인 할 수 있다. ( 시스템 권한, 일반 유저 권한 )

     같은 프로그램이 다른 유저 & 다른 권한으로 & 다른 시간대에 접근할 수 있다.

     특별한 프로그램이 가끔 다른 유저들보다 더 많은 권한을 가질 수 있다.

     사람들은 자신이 어떤 프로그램을 사용하여 Access 하는지 모르기도 한다.

2. What a Capability Is

-

Capability 의 기본 아이디어는 이렇다.

어떤 object 에 access 하기 위해서는 프로그램은 반드시 special token 을 가지고 있어야 한다.

이 토큰은 그 object 를 지정하고 있으며, 그 토큰이 프로그램에게 특별한 action set 을 수행할 수 있는 권한을 준다.

그 토큰을 capability 라고 부른다.

-

Capability 는 열쇠와 같다.

자동차 열쇠를 상상해보라. 이 열쇠는 특정 차의 문만 열 수 있다.

이 자동차 열쇠는 다른 쪽으로 전달할 수 있고, 그 키를 가진 사람은 이 자동차에 대한 액션을 할 수 있다.

자동차 열쇠 자체는 사용자를 판단하지 않는다.

그냥 그 열쇠를 가진 사람이 주인이라고 생각한다.

Capability 는 사용자가 누구인지 고려하지 않는다.

다만 그것을 가지고 있느냐가 중요하다.

-

2개의 Capabilities 는 한 object 에 대해 다른 권한을 가질 수 있다.

다시 한 번 자동차 열쇠를 예제로, 하나는 차의 문만 열 수 있는 키가 있고, 다른 하나는 실제 자동차를 작동시킬 수 있는 키인 경우이다.

프로그램 기준으로 하나의 capability 는 read-only 이고, 다른 하나의 key 는 read-write 일 수 있는 것이다.

-

Capability 는 양도될 수 있다.

-

Capability 는 복사될 수 있다.

그러나 이것은 신용할 수 있는 사람에게만 키를 전달하는 개념으로 볼 때 큰 문제가 되지 않는다.

만약 도난당한 것이라면 자동차의 열쇠부를 바꿀 수 있다. Capability 에 동일하게 적용된다.

-

Capability 와 Real life key 의 차이점은 다음과 같다.

     Capability 는 복사하기 더 쉽다.

     Capability 는 bypass 가 더 어렵다. ( 자동차 문 부수고 문 여는 등의 행위가 여럽다. )

     Capability 는 더 variation 이 많다.

-

Capability 는 그런 것이지만, 사실 Capability 가 유용하려면, 위조가 어려워야 한다.

위조를 막는 작업은 hardware 나 software 적으로 구현한다.

Software 방법이 훨씬 편리하다.

3. Capability-Based Computer Systems

-

Capability-Based Computer System 에서는 모든 object 에 대한 access 는 capability 를 통해 이루어진다.

만약 프로그램 A 가 B 에게 이야기하는 capability 를 가지고 있다면, 두 프로그램은 서로에 대한 capability 를 들고 있다.

그리고 그것은 특정한 형태의 communication 을 통해서 서로 grant 한다.

-

많은 capability 를 가지고 있는 것은 보통 멍청하다고 여겨진다.

목표는, 최대한 특정적이고(Specific), 적은 수의 권한을 가지는 것이다.

이것이 “Principle of Least Privilege” 이다.

-

UNIX 의 system call read(fd, buf, sz) 는 capability-based 라고 볼 수 있다.

fd 라는 capability 에 buf 와 sz 를 전달하며 read 라는 operation 을 수행한다.

UNIX 의 file descriptor 는 capability 이다.

-

Capability 는 닭이 먼저냐 달걀이 먼저냐 문제가 있는데,

Capability 를 획득한 후 시스템 재부팅 등의 상황이 발생했을 때 이 Capability 를 다시 어떻게 얻을 수 있는가이다.

-

기존 방법 :  Access Control Lists ( ACL )

     특정 파일 시스템에 어떤 프로그램에 어떤 권한을 줄 것인가를 써 놓는 것이었다.

     그러나 이 방법은 권한 관리에 효율적이지 않다.

     Authority 를 양도하기도 어렵다. ( 해당 파일을 쓰는 권한이 없기 때문에 )

-

더 나은 방법 : Universal Persistence

     Common file system 을 갖지 않고, 어떤 프로그램에게도 file system 에 접근하는 권한을 주지 않는 것이다.

     그리고 시스템에서 주기적으로 현재 capability 에 대한 “모든 것” 을 적어놓는 것이다.

     시스템이 재부팅되면 모든것을 시스템에서 써 놓은 것으로부터 바로 복구한다.

     

     비효율적인 방법이라 생각할지 모르겠지만, 사실 이 방법이 훨씬 간편하고 빠르다.

     이 방법은 KeyKOS 와 EROS 에서 사용되며 잘 작동한다.

Access, Access Control, Access Control Lists, ACL, buf, Capability, capability based computer system, fd, granting access, limiting access, object action set token, Operation, preventing access, principle of least priviliege, revoking access, Security, special token, system call read, SZ, Universal persistence, [Security] Capability 에 대한 이해, 네트워크 접근 권한, 시스템 권한, 일반 유저 권한, 접근 권한, 파일 접근권한, 프로그램 접근 권한, 하드웨어 접근권한