리눅스 ROOT(UID 0)가 가지는 특별함

주요정보통신 기반시설 취약점 진단 가이드를 읽다보면,
/etc/shadow 퍼미션을 400으로 수정하라는 항목이 있다.

단순하게 생각하면 /etc/shadow를 400으로 수정하면 (R : 4, W: 2, X: 1)의 구조니까,
루트가 읽기만 할 수 있는데 이렇게 하면 일반 유저는 본인의 패스워드를 바꿀 수 없을 것만 같다.

하지만 이것이 정상 동작하는 이유는 무엇일까?
정답은 패스워드를 변경할 때 사용되는 "/usr/bin/passwd" 바이너리가 setuid를 가지고 있기 때문이다.

다음 궁금점은, root도 Read(400) 권한만 가지고 있는데 어떻게 패스워드가 수정될 수 있을까?
여기서 리눅스 권한 관리 개념의 DAC에 대해 짧게 보고 넘어가야하는데,
DAC (Discretionary Access Control)는 리눅스의 기본 권한 모델로

• UID / GID
• 퍼미션 비트 (rwx)
• ACL (setfacl)

를 구성 요소로 가진다.

일반 유저는,

open("/etc/shadow", O_WRONLY)
↓
커널: UID / GID 확인
↓
inode 퍼미션 비트 검사
↓
권한 없으면 → -EACCES

의 순서대로 권한을 검사하는 흐름을 가지는데,

root(UID 0)는 CAP_DAC_OVERRIDE / CAP_DAC_READ_SEARCH 의 두가지 CAPABILITY를 가지는데,
전자는 파일의 read/write/execute 비트를 무시하고, owner/group/other 검사 스킵한다.
후자는 디렉터리 대상으로 read (ls), execute (cd), search 권한을 우회한다.

이러한 차이 때문에,

• 일반 사용자는 커널의 퍼미션 체크에 완전히 종속되서 write 비트 없으면 수정이 불가하지만,
• root는 write 권한이 없어도 파일 열기 (O_WRONLY, O_RDWR), 파일 truncate, inode 메타데이터 변경, chmod / chown이 가능해진다.

하지만 SELinux 같은 MAC 정책이나 immutable 속성, read-only mount는
root도 우회할 수 없기 때문에 꼭 통제하고 싶다면 이러한 부분을 통해 컨트롤 할 수 있다는 점도 기억하자.

마지막으로 일반적으로 /etc/shadow의 기본 권한값은 640이다.
기본값이 400이 아닌 이유는 호환성에 의해서 변경시에 구 어플리케이션이나 특정 서드파티 유틸리티는 오류가 발생할 수 있기 때문에 반드시 테스트하고 검증하고 적용하여야 하는 것을 잊지 말자.

본 주제와는 크게 상관없지만,
주요정보통신 기반시설 취약점 진단 항목 중에 다른 항목들도,
아무 생각없이 가이드대로 따라하다가는 시스템 장애를 불러오는 사항들이 많이 있다.

예를 들자면 /etc/hosts파일 권한을 수정해서 유저 권한 어플리케이션이 로컬에 설정해 둔 호스트 정보를 읽지 못한다거나 setuid를 잘못 제거해서 특정 환경에서 로그인이 동작하지 않게 된다거나하는 등의 문제가 많이 발생할 수 있으니 꼭 주의하도록 하자.