Linux) DAC의 한계 [Limitations of Discretionary Access Control]

DAC의 문제점

 

1. Confused Deputy Problem

 

예제. 파일 → 바이너리 컴파일

 

	main.c (m)	a.out (a)	log.txt (l)
Vendor (V)			Read, write
User (U)	Read, write	Read, write

ACL matrix for files

 

위와 같이 file DAC가 설정되어 있다고 가정.

- 컴파일 시 컴파일러 Vendor는 디버깅을 위해 log.txt를 남기기를 원한다.

- 따라서, User는 log.txt에 대한 read, write 권한이 없다.

 

	Compiler (c)	main.c (m)	a.out (a)	log.txt (l)
Vendor (V)				Read, write
User (U)	call	Read, write	Read, write
Compiler (C)		read	write	write

ACL matrix with the compiler running

 

1. 유저가 컴파일러 실행 시, checks for Access(U, c, call)

2. 컴파일러가 컴파일 시, checks for Access(C, m, read)

3. 컴파일러가 컴파일 도중 로그를 남길 시, checks for Access(C, l, write)

4. 컴파일러가 컴파일 후 바이너리 write 시, checks for Access(C, a, write)

 

문제

- Compiler.compile(“main.c”, “a.out”) 대신 Compiler.compile(“main.c”, “log.txt”) 호출 시 Vendor가 원하는 log.txt가 지워지고 덮어써지는 현상 발생

 

문제 원인.

- Compiler의 권한이 두 명 이상의 주체에 의해 결정 된다.

:= Compiler는 실행 될 때 자신이 Vendor의 권한으로 실행되는지 User의 권한으로 실행되는지 알 방법이 없다.

 

해결방법

 

- Capability transfer (Capability model)

:= 메시지에 권한을 담아서 보내는 방식. (여기서 메시지는 read, write, call 과 같은 콜을 뜻함)

:= 일을 시키려는 쪽이 자신의 권한을 메시지에 담아서 전송하는 방식.

 

1. User는 compile 시 Access(U, m, read) 그리고 Access(U, a, write) 권한을 담아 보낸다

2. Compiler는 컴파일 시 파일 reading을 위해 받은 Access(U, m, read) 권한을 사용

3. Compiler는 컴파일 도중 로그 작성을 위해 갖고 있는 Access(V, l, write) 권한을 사용

4. Compiler가 컴파일 후 바이너리 writing을 위해 받은 Access(U, a, write) 권한을 사용