[OS] 11-4. File Protection

File Protection

File에 대한 부적절한 접근 방지: 다중 사용자 시스템에서 더욱 필요

 

접근 제어가 필요한 연산들 : Read(R), Write(W), Execute(X), Append(A)

 

File Protection Mechanism

파일 보호 기법은 system size 및 응용 분야에 따라 다를 수 있음

 

1. Password 기법

• 각 file들에 PW부여
• 비 현실적인 방법
  • 사용자들이 파일 각각에 대한 PW를 기억해야 함
  • 접근 권한 별로 서로 다른 PW를 부여 해야 함

2. Access Matrix 기법

 

Access Matrix (접근 행렬)

접근 권한을 표에 기록하겠다 라는 의미 

정확한 의미로는 범위(domain)와 개체(object)사이의 접근 권한을 명시 (object: 파일, domain: 사용자)

 

관련 용어들..

• Object: 접근 대상(File, device 등 HW/SW objects)
• Domain (protection domain): 접근 권한의 집합, 같은 권한을 가지는 그룹(사용자, 프로세스)
• Access right: <Object-name, rights-set> (오브젝트에 대해 도메인이 가지는 권한을 적어두는 것)

Example

2차원 행렬에 Object(파일들), Domain(User) 를 적어두고 각 domain이 파일들에 접근할 수 있는 권한을 적어둔 것

 

실제로 어떻게 구현하는가?

Access Matrix - Implementaion

• Global table
• Access list
• Capability list
• Lock-key mechanism

 

Global Table

• 시스템 전체 file들에 대한 권한을 Table로 유지함 (표 전체를 통채로 저장함)
• <Domain-name, Object-name, Right-set>

Domain name	Object name	Right-set
D1	O1	R1
D2	O2	R2
D3	O3	R3
...	...	...

• 단점: Large table size (빈 공간들까지 고려해서 통채로 저장함 => 크기가 커짐 => 용량이 커짐 => 부담)
• 단점을 보완하기 위해서 빈 공간을 저장하지 않으면 된다
• 보완하는 구현 기법들 => Access list(각 파일마다 Domain들의 권한을 저장), Capability list(Domain 마다 내가 가진 파일들의 권한을 적음)

보완 기법들

Access List

• Access matrix의 열(column)을 list로 표현
  • 각 Object(파일들)에 대한 접근 권한을 나열함
  • A_list(F_k) = { <D1, R1>, <D2, R2>, ... ,<Dm, Rm> } ( _는 아랫첨자를 의미)
  • (어떤 파일k에 대한 접근권한, 어떤 도메인 권한이 없다면 (ex D3) 적지 않는다. => 저장공간을 줄일 수 있음)
• Object 생성 시, 각 domain(User)에 대한 권한 부여함
• Object 접근 시 권한을 검사함
• 실제 OS에서 많이 사용됨:  UNIX의 예

UNIX의 예

ex) ls -l (을 입력하면 파일의 권한들이 나오는 것을 볼 수 있음

출처:&nbsp;https://infosecwriteups.com/setup-armitage-as-a-command-control-c2-framework-for-free-bae590064817

• Owner RWX : 파일을 가지고 있는사람이 RWX를 할 수 있는가 (Domain)
• Group RWX : 해당 그룹이 RWX를 할 수 있는가
• Universe RWX : 누구나 RWX를 할 수 있는가

이 방식의 문제점은 파일을 access할 때마다 파일 권한을 체크하기 때문에 오버헤드가 발생한다.

이를 보완하는 구현 기법 => Capability List

 

Ex) 뷔페에 나갔다가 다시 들어가서 음식을 받으려고 하는데 팔에 찍힌 도장을 보고 확인을 함

(뭐가 다른건가?? -> 추후에 원리 공부할 것..)

 

Capability List

• Access matrix의 행(row)을 list로 표현
  • 각 Domain에 대한 접근 권한 나열
  • C_list(D1) = { <F1, R1>, <F2, R2>, ... ,<Fp, Rp> }
  • 도메인이 가진 capablity list는 파일이 할 수 있는 권한을 적어 둔 것
  • 프로세스(도메인) 어떤 파일에 접근하려면 권한을 가졌다고 신분증 즉, capability list를 보여주고 접근
• Capability를 가짐 =  권한을 가짐
  • 프로세스가 권한을 제시, 시스템이 검증 승인함

단, capability list에 대한 보안이 약하다면 문제점이 발생함. => OS가 Capability list를 보호해야하는 오버헤드 발생

• 시스템이 capability list 자체를 보호 해야 함 => Kernel 안에 저장함

 

Lock-key Mechanism

• Access list와 Capability list를 혼합한 개념
• Object는 Lock을, Domain은 Key를 가짐 (Lock/key: unique bit patterns)
• Domain내 프로세스가 Object에 접근시 자신의 key 와 Object의 lock 짝이 맞아야 함
• 시스템은 Key list를 관리해야 함.

 

구현 방법 비교

• Global table : 간단함, 그러나 매우 커질 수 있음
• Access list
  • Object 별 권한 관리가 용이하다 (파일의 권한을 적어놓기 때문에 각 파일에 대해 권한 관리가 편함)
  • 모든 접근마다 권한을 검사해야 한다. (Object많이 접근하는 경우 -> 느림)
• Capability list
  • List내 Object들(localized Info.)에 대한 접근에 유리함
  • Object별 권한 관리(권한 취소 등) 가 어려움
  • => 여러 도메인이 있을 때 특정 파일의 권한을 바꾸려면 모든 도메인을 탐색하여 해당 파일에 권한을 바꿔야함
• 많은 OS가 Access list와 Capability list개념을 함께 사용함
  • 어떤 도메인이 Object에 대한 첫 접근 -> Access list 탐색
    • 접근 허용 시, Capability(출입증) 생성 후 해당 프로세스에게 전달
    • 이후 접근시에 권한 검사 불필요함.
  • 마지막 접근 후 -> capability 를 OS에 반납함