Linux에서 MAC 모델의 실제 가치
나는 인터넷에서 MAC 대 DAC에 대해 읽었지만 여전히 MAC + DAC + 기능에 비해 DAC + 기능 만 사용하면 보호 할 수없는 공격 유형을 이해하지 못합니다. 프로세스가 루트로 실행되지 않고 CAP_DAC_OVERRIDE, CAP_FOWNER 및 기타 위험한 기능이없는 경우 이미 할당 된 소유권 및 사용하는 리소스의 ACL을 극복 할 수 없습니다. 반면에 프로세스가 루트로 실행되고 CAP_MAC_ADMIN이있는 경우 MAC에서 적용하는 보안 컨텍스트를 덮어 쓸 수 있습니다.
그렇다면 MAC은 최신 Linux 시스템에서 실질적인 이점이없는 "단지 추가 보호 계층"일까요?
Update1 여기에 특정 인수에 대한 "답변"을 추가하겠습니다. 어떤 프로세스도 루트로 실행되지 않고 불필요한 기능 (시스템 시작 프로세스 / 스크립트 제외)이 있다고 가정합니다.
인수 : 임의의 셸 명령을 실행하지 못하도록 웹 서버를 보호 할 수 있습니다.
답변 : (컨테이너화 된 웹 앱을 제쳐두고) 서버 UID / GID가 액세스 할 수있는 모든 명령에 대해 허용 ACL을 추가하고 호스트의 나머지 명령에 금지 ACL을 추가 할 수 있습니다.
인수 : 사용자는 권한이 0777 인 파일을 가질 수 있습니다 [기본적으로 시스템의 모든 사람에게 유출].
답변 : 시스템 시작 스크립트는이 파일이 생성 된 디렉토리에 기본 ACL을 설정할 수 있으므로 해당 디렉토리에서 사용자 프로세스가 생성하는 모든 것이 항상 해당 ACL을 상속 받게됩니다. 일반적으로 "others"에 7을 사용하는 것은 좋지 않은 생각처럼 보이며 파일에 이러한 권한이있는 경우 여기에서 시스템 롤아웃 (배포 설치) 또는 시스템이 부팅 될 때마다 시작시 임의 정책을 적용 할 수 있습니다.
답변
차이점은 파일에 대한 권한을 결정하는 사람입니다. DAC는 파일 소유자에게 파일 사용 권한에 대한 모든 권한을 부여합니다. MAC은 레이블을 사용하여 중앙 집중식 제어를 시행합니다. 즉, 결정할 파일 소유자가 아닌 추가 보안 계층이 있습니다. 예를 들어 사용자에게 rwxrwxrwx (777) 권한이있는 파일이있을 수 있지만 MAC은 특정 보안 레이블 집합에만 rwx를 적용하여 DAC를 효과적으로 재정의합니다.
DAC는 MAC에서 발생하는 모든 잠재적 보안 권한 상황을 다루지는 않습니다. ACL은 DAC에 비해 매우 유연합니다.
단순함을 위해 DAC는 rwx 만 제어 할 수 있습니다. DAC를 사용하면 시스템 호출 수준에서 허용되는 것을 훨씬 더 명확하게 제어 할 수 있습니다. 예를 들어, 누군가가 파일에 추가하도록 허용 할 수 있지만 덮어 쓰거나 삭제할 수는 없습니다.