Study

[Linux] 모던 리눅스 교과서 4장 - 접근제어

wwns 2024. 11. 24. 23:22
반응형

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

https://limitrequestbody.com/linux-capabilities-%EB%A6%AC%EB%88%85%EC%8A%A4-%EC%BA%90%ED%8D%BC%EB%B9%8C%EB%A6%AC%ED%8B%B0-297ae87cb3c

 

linux capabilities

리눅스 커널에는 30개가 넘는 Capability(이하 Cap)가 존재합니다. Cap은 스레드 단위로 부여하며 이에 따라 스레드가 할 수 있는 일이 달라지게 됩니다.

limitrequestbody.com

 

반응형