'리눅스'에 해당되는 글 2건

1. Overview

접근제어(Access Control)란??

접근제어는 자원에 대한 권한이 없는 주체(Subject)가 해당 자원의 사용을 막는 것을 의미한다.

접근제어를 하기 위해서 주체를 구별하기 위한 Identification과 본인 여부를 확인하는 인증 절차가 필요하다.

특히 인증의 성공 여부에 따라 리소스에 접근할 권한을 줄지 안 줄지 결정되므로 인증이 핵심 절차이다.

주체(Subject)는 컴퓨터를 사용하는 사람, 그룹, 프로세스, 컴퓨터와 같이 정보를 요청하는 요소이며,

객체(Object)는 파일이나 폴더, 디바이스, 메모리 등 정보를 가지고 있는 요소이다. 

주체는 접근 권한에 따라 객체를 읽거나, 쓰기, 실행이 가능하며 권한은 객체별로 다른 형태로 부여한다.

요구사항

- 신뢰가능한 입력(reliable input) : 신뢰가능함은 인증을 통과한 주체가 행하는 입력을 의미한다.

- 포괄적 vs 세분화 : 권한의 범위를 어느 수준까지 설정하는가 문제

- 최소 권한 : 주체에게 너무 큰 권한을 부여하면 시스템의 문제의 여지가 될 수 있다.

- 열린 정책 vs 닫힌 정책 / 정책 간 충돌 문제

- 정책 관리 : 관리자만이 정책을 변경할 수 있다.

- 동시성 제어 : 하나의 객체에 여러 주체가 동시에 접근할 경우 어떻게 처리할지 문제

- 의무의 분리 : 중요한 행위는 반드시 두 개이상의 user나 권한으로 나누어서 실행한다.

2. DAC(Discretionary Acess Control)

주인장 맘대로

자원의 주인이 해당 자원에 대한 다른 사람들의 권한을 결정하여 접근 제어를 하는 방법이다.

따라서 이 방법을 사용하기 위해서 각자를 구별할 ID와 해당 자원의 소유권, 그리고 다른 유저에게 분배된 권한을 정리할 파일이 필요하다. 권한을 저장하는 방법은 Access Control List, Capability List, Access Matrix가 있다. Access Matrix의 경우에는 사용자가 많고 자원들이 많은 실제 상용 시스템에서 사용하면 공란이 많은 희소 행렬의 형태라 공간 낭비가 심해 사용하지 않는다.

Access Control List vs Capability List

ACLs는 자원에 대하여 각 사용자들의 권한을 저장하는 방법이고 CL은 반대로 사용자에 대하여 각 자원들의 권한을 저장하는 방법이다. 다시 말해 ACLs는 자원 중심, CL은 사용자 중심의 저장 방법이다. 따라서 사용자에 비해 자원이 많은 개인용 PC 같은 환경에서는 ACLs, 사용자의 수가 많은 웹 서버같은 환경에서는 CL이 더욱 유용한 방법이다. 

DAC 장점

- 사용자가 접근 권한을 관리 할 수 있어서 보안 관리자가 업무가 줄어 든다.

- 권한을 수정이 쉽고 새로운 권한을 적용하기 쉽다.

DAC 단점

- 위의 그림처럼 권한을 부여한 사용자의 의도하지 않은 대로 정보가 흘러갈 수 있다.

- 루트의 권한이 너무 강력하다. 

- 주체와 객체의 수가 증가한다면 복잡해지고 크기가 커지는 문제도 있다.

- 소유자를 쉽게 변경이 가능하다는 점을 악용한 프로그램들도 많다 

Unix / Linux의 파일 시스템

리눅스의 파일 시스템의 정보는 inode 저장된다. inode에는 하나의 파일 또는 디렉터리의  UID, GID, 소유권이 명시 되어있으며 12개의 비트로 특수권한 / 읽기 / 쓰기 / 실행 권한을 표기한다. 이 inode들은 디스크 상에 inode 테이블이나 리스트에 저장이 되어진다. 그리고 파일을 열면 해당 파일의 inode는 메인 메모리에 상주하는 inode 테이블에 저장된다. 

DAC 취약점 실습

위 그림은 file1의 소유주 csos가 user1에게 읽기 권한을 부여하는 과정이다.

리눅스에서 setfacl 또는 chacl 명령어로 파일 시스템 상의 ACL을 변경할 수 있고 getfacl 명령어로 해당 파일의 ACL정보를 확인 할 수 있다. 파일의 소유자의 UID, GID 정보와 각 사용자와 그룹에 대하여 권한, 마스크 정보도 추가된 확장된 ACL을 사용한다는 것을 알 수 있다. 파일 시스템에 접근하는 경우 파일의 ACL을 확인하여 소유자 -> 지정한 유저 -> 그룹 -> 외부자로 순으로 연산 처리한다.

user1으로 접속을 변경하고 csos가 읽기 권한을 준 file1을 복사하여 user1의 영역으로 복사하였다. 이제 user1은 file1의 사본 file2의 소유자이므로 file1에 대한 모든 권한을 행사할 수 있다. 이처럼 DAC는 원 소유자 csos의 의도와 다르게 흐름을 변경할 수 있는 취약점이 있다.

1. Overview

Multi-user System

요새는 다 개개인의 책상이 떨어져 있지만 옛날에 초등학교 다닐때 우리학교에는 두 책상이 붙어있는 경우가 있다. 그 경우 꼭 유치하게 넘어오면 내꺼라는 둥하면 티격태격한 기억이 있는 아재들이 있을 것이다. 리눅스도 이 초등학교처럼 하나의 운영체제에서 많은 유저가 사용할 수 있는 운영체제이다. 만일 권한의 경계를 명확하게 하지 않으면 다른 계정에 의해 내가 작업해놓은 파일들이 없어지고 수정되어 있는 참사가 벌어질 수도 있다. 따라서 리눅스는 소유권과 허가권의 개념으로 파일의 읽고 쓰고 접근(실행)하는 권한을 구별한다.

2. Ownership & Permission

소유권(Ownership)

소유권은 파일 또는 디렉터리의 주인이 누구인지 밝히는 것이다. 

1. 리눅스는 파일 또는 디렉터리의 소유권 UID와 GID으로 표기를 한다. 

2. 일반적으로 리눅스 상에 계정을 생성하면 /home/ 안에 계정명과 동일한 디렉터리를 생성한다. 

3. 또한 일반적으로 리눅스의 새로운 계정의 그룹은 계정명과 동일한 그룹에 소속한다.

위의 명령어를 사용하면 파일이나 디렉터리의 소유권을 변경할 수 있다. 

하지만 아무나 변경하면 안되니까 소유권자나 최고 존엄 root 만이 바꿀 수 있다.

허가권(Permission)

허가권은 이 파일 또는 디렉터리에 대해 현재 계정이 어떤 것을 할 수 있는지 보여주는 것이다.

위의 명령어를 사용하면 파일이나 디렉터리의 허가권을 변경할 수 있다. 

하지만 아무나 변경하면 안되니까 소유권자나 최고 존엄 root 만이 바꿀 수 있다.

이 때 권한을 입력하는 방법은 읽기를 4, 쓰기를 2, 접근을 1로 하고 이 수들의 합으로 표현한다.

예를 들면 rwxr-x--x는 751로 표현 가능하다.

3. 특수 권한

SetUID : UID 권한 상승

각각의 프로세스는 Real UID와 Effective UID, Saved UID를 가지고 있다. 실제 프로그램을 수행할 때는 RUID가 아닌 EUID를 사용하여 허가권을 계산한다. 파일의 권한이 SetUID로 설정되어 있으면 일시적으로 상승된 권한을 다시 원래 권한으로 복귀하기 위해 saved UID에 기존의 UID를 저장한 후 Effective UID를 일시적으로 파일의 소유권자의 UID로 변경하여 사용할 수 있다. 일반적으로 SetUID는 실행가능한 파일에 주로 설정한다.

setUID는 권한 상승을 시켜 다른 계정이 사용할 수 없는 프로그램을 일시적으로 사용할 수 있어서 유연성이 있는 권한이지만 취약한 프로그램이 setUID로 설정되어 있다면 쉘코드를 주입하여 남용이 가능하다. 특히 root에 대한 setUID가 악용되면 서버 전체에 큰 피해를 줄 수 있으므로 가급적 사용을 자제하는 것이 좋다.  

SetGID : GID 권한 상승

setGID는 setUID와 비슷하게 권한을 일시적으로 상승시켜주는데 파일 또는 디렉터리의 GID의 권한으로 상승을 시켜준다. 일반적으로 디렉터리나 실행 가능한 파일에 사용하며 디렉터리에 이 권한이 있으면 그 안에서 생성한 새 파일들의 GID는 해당 디렉터리의 GID로 상속받는다.

Sticky bit : 게시판같은 개념

sticky bit는 주로 디렉터리에 사용하여 누구든지와서 파일을 생성할 수 있는 일종의 게시판과 같은 개념이다. 생성된 파일에 대한 삭제권한은 파일의 주인만이 할 수 있다는 점도 게시판과 많이 닮은 부분이다.