[Linux] 모던 리눅스 교과서 4장 - 접근제어
4장에서는 리눅스의 보안 부분과 관련하여 리소스, 파일에 대한 접근제어를 다룬다.
특히 여러 사용자가 파일을 공유하는 상황에서 고민했던 접근제어 방식을 생각하며 내용을 정리해 본다.
기본 개요
- 사용자
- 프로세스를 실행하고 파일을 소유한다.
- 파일
- 소유자가 존재하며 기본적으로 파일을 만든 사용자가 파일을 소유
- 프로세스
- 커널이 메인 메모리에 로드해 실행하는 일종의 프로그램
- 의사소통과 지속성? 을 위해 파일을 사용 (프로세스-프로세스 의사소통을 얘기하는 듯)
- 사용자가 파일을 사용하려면 프로세스를 통해야 함 (syscall)
접근 제어 유형
- 임의 접근 제어 (Discretionary Access Control, DAC)
- 파일이나 디렉터리의 소유자가 누구에게 어떤 권한(읽기, 쓰기, 실행 등)을 줄지 결정할 수 있음
- 파일의 소유자와 그룹, 그리고 읽기/쓰기/실행 권한으로 구현
- 강제 접근 제어(Mandatory Access Control, MAC)
- 시스템 관리자나 보안 정책이 접근을 강제로 통제
- 각 자원과 프로세스에 대해 보안 레이블(Security Labels)을 지정
all-or-nothing
모든 것을 변경할 수 있는 수퍼유저이거나 접근이 제한된 일반 사용자 중 하나로 구분
예시:
대부분의 리눅스 시스템은 기본값으로 거의 모든 파일에 대해 읽기 접근을 허용 - 보안 취약 요소가 될 수 있음
하지만 SE리눅스가 활성화된 상태에서 웹 서버 포트를 제한한다던지, 특정 디렉터리의 파일과 스크립트만 공유할 수 있으며 특정 위치에만 로그를 쓸 수 있도록 하여 접근 제어하여 서버를 운영한다.
방대한 개수의 서버마다 SE리눅스로 접근제어를 한다면 관리할 수 있을까 라는 생각이 들었다..
관리 포인트를 줄이기 위해 L2, L3 Layer에 보안 장비를 두고 트래픽, 프로토콜, 접근 기록을 관리하는 Trade off이지 않았을까 생각이 든다.
중앙집중식 사용자 관리
큰 시스템 규모일 경우 중앙에서 사용자를 관리하는 방법을 설명한다.
- 디렉터리 기반
- LDAP(Lightweight Directory Access Protocol)은 IP를 통해 분산 디렉터리에 접근하고 유지 관리하는 방법
- LDAP로 관리되는 디렉터리에 접근 시 인증과정(질의)을 거쳐 액세스 하게 됨
- AD(ctive Directory) LDAP 프로토콜을 기반으로 한 MS의 디렉터리 서비스로 공유 파일 서버로 활용됨
- 사용자 인증 및 권한 제어 후 LDAP 프로토콜은 디렉터리 오브젝트를 찾아주는 역할
- LDAP와 AD
- 네트워크 기반
- 커버로스 프로토콜을 이용해 네트워크 방식으로 사용자 인증할 수 있음
- 커버로스 작동방식
- 구성 관리 시스템 사용
- 앤서블, 셰프, 퍼핏, 솔트스택 등의 시스템을 사용해 일관되게 사용자 생성
- VMware의 vCenter 혹은 vSphere에서 VM을 생성할 때 템플릿으로 찍거나, UI 클릭으로 사용함 - 관리자 특화 -> 해당 방식도 앤서블을 활용하여 플레이북 형태로 관리할 수 도 있음
- 앤서블로 VMware 생성하기
- 앤서블, 셰프, 퍼핏, 솔트스택 등의 시스템을 사용해 일관되게 사용자 생성
프로세스 권한
- RUID: 프로세스를 실행한 실제 사용자 ID.
- EUID: 프로세스가 현재 사용하는 권한 ID
- 리눅스 커널은 메시지 대기열과 같은 공유 리소스에접근할 때 EUID를 통해 프로세스가 갖는 권한을 결정
- SUID: 이전 EUID를 저장하여 원래 권한으로 복귀할 수 있게 지원
- 프로세스가 특정 포트를 사용하려면 root 권한이 필요한데, 이때 저장된 SUID를 가져올 수 있다.
- 실행한 프로세스의 EUID가 1001이었고 Suid가 설정된 실행 파일에 대해 root 권한을 얻게 되면 EUID와 SUID가 변경될 수 있음
캐퍼빌리티
커널은 프로세스가 리소스를 요청할 때 두 가지만 확인한다.
- EUID가 0(root)인 권한 있는 프로세스는 커널 권한 검사를 우회한다.
- EUID가 0이 아닌 프로세스는 커널 권한 검사를 수행한다.
만약 EUID를 root로 실행되어야 하는 상황에 왔을 때 커널은 권한 검사를 수행하지 않게 된다. 이때 우리가 생각하지 않았던 다른 동작을 수행하게 된다면? 보안적으로 취약한 부분이 발생할 수 있다는 것이다.
따라서 필요한 수행을 할 수 있도록 캐퍼빌리티를 설정하던지, 캐퍼빌리티를 사용하여 수행을 제한하던지의 방식을 사용할 수 있다.
- setuid를 통한 보안 취약점을 제공하지 말자 (애플리케이션에서 필요하대요로 예외를 만들지 말자)
네트워크 패킷 전송 시 원시 소켓을 열 때
루트 권한을 부여하는 것 대신 cap_net_raw 권한을 부여해서 필요 최소한의 권한만 사용자에게 할당하는 시스템
References
https://www.redhat.com/ko/topics/linux/what-is-selinux
SELinux 간편 가이드: 개념, 설정 및 사용법
SELinux 개념과 시스템 액세스 권한을 제어하는 리눅스 보안 아키텍처를 이해하고, SELinux 설정 방법, 보안 확인 절차, 무료 다운로드 및 사용법을 알아보세요
www.redhat.com
linux capabilities
리눅스 커널에는 30개가 넘는 Capability(이하 Cap)가 존재합니다. Cap은 스레드 단위로 부여하며 이에 따라 스레드가 할 수 있는 일이 달라지게 됩니다.
limitrequestbody.com