Study · 운영체제 · 권한 검사 · 계정과 권한

열기를 막는 자리는 한 곳이 아니다

장면

cat /etc/shadow 가 Permission denied 로 막힌다. 커널은 어느 지점에서 무엇을 보고 막았을까? 그리고 막는 자리는 하나일까?

tghan@ubuntu:~$ cat /etc/shadow
cat: /etc/shadow: Permission denied
# 왜 막혔는지는 이 화면만 봐서는 알 수 없다 — 막는 자리가 둘이라서다

먼저 알아야 할 말

커널: 컴퓨터가 켜져 있는 동안 늘 돌고 있는 프로그램 하나다. 파일을 만들고 지우는 일, 프로그램을 띄우는 일은 내 프로그램이 직접 못 하고 전부 커널에 부탁한다. 터미널에 친 명령이 실제로 무언가를 하는 순간은 늘 커널 안이다.
rwx: 읽기(r) · 쓰기(w) · 실행(x) 권한이다. 주인 · 그룹 · 나머지 셋으로 나뉘어 아홉 자리가 된다 — ls -l 의 rw-r--r-- 가 그것이다.
LSM: Linux Security Module. rwx 검사를 통과한 뒤에 한 번 더 묻는 자리다. SELinux · AppArmor 가 여기에 꽂혀 「그래도 안 된다」고 말할 수 있다.
inode: 파일 하나의 정보를 모아 둔 커널 안의 기록이다. 크기 · 주인 · 권한 비트가 여기 있고, 파일 이름은 여기 없다(이름은 디렉터리가 들고 있다). 파일 항목들에서 「알맹이」라고 부르는 것이 이것이다.
root: 번호가 0 인 계정이다. 권한 검사를 거의 다 통과해서 무엇이든 할 수 있다. 우분투를 설치하면 처음부터 있는 계정이고, 내 계정과는 별개다.
능력: root 가 가진 힘을 여러 조각으로 쪼개 놓은 것이다. 예를 들어 CAP_DAC_OVERRIDE 조각 하나만 있으면 rwx 검사를 건너뛸 수 있다. root 가 무엇이든 되는 것은 이 조각을 전부 갖고 있어서다.
훅: 커널이 「여기서 한 번 물어본다」고 미리 비워 둔 자리다. 보안 모듈이 그 자리에 자기 검사를 꽂아 두면, 커널이 그 지점을 지날 때마다 불러 준다.
SELinux: LSM 에 꽂히는 보안 모듈 가운데 하나다. 프로세스와 파일에 붙은 이름표(label)를 보고 정책표와 맞춰 허용 여부를 정한다.
셸: 명령을 받아 실행해 주는 프로그램이다. 우분투 기본은 bash 이고, 터미널에서 보이는 $ 앞이 그것이다.
/proc: 커널이 지금 상태를 파일인 것처럼 보여 주는 가짜 폴더다. ls -l /proc/self/fd 를 치면 지금 열어 둔 것이 나온다. 디스크에 진짜 파일이 있는 것은 아니다.
프로세스: 돌고 있는 프로그램 하나다. ps 가 줄마다 보여 주는 것이 프로세스이고, 각각 번호(PID)가 있다.
컨테이너 (Docker): Docker 이미지를 실제로 실행한 상태다. 프로그램 하나를 자기만의 작은 방에 넣어 돌리는 것과 비슷해서, 그 안에서는 자기 파일과 네트워크만 보이고 다른 컨테이너나 호스트 컴퓨터와 섞이지 않는다. 같은 이미지로 컨테이너를 여러 개 띄울 수 있고, 컨테이너 하나를 지워도 이미지는 그대로 남는다.
호스트: 네트워크에 연결된 컴퓨터 한 대, 또는 그 컴퓨터를 가리키는 이름이나 주소다. 주소 example.com 에서 호스트는 example.com 부분이고, 포트는 그 컴퓨터 안의 특정 프로그램을 가리키는 번호다. localhost는 「지금 이 컴퓨터」를 가리키는 특별한 호스트 이름이다.
strace: 프로그램이 커널에 무슨 부탁을 하는지 옆에서 받아 적어 주는 명령이다.
시스템 콜: 프로그램이 커널에게 일을 시키는 창구다. 파일 열기 · 스레드 만들기처럼 커널만 할 수 있는 일은 전부 이 창구를 지난다. 자바의 FileInputStream 도 결국 이 창구를 부른다.
sudo: 명령 하나를 root 권한으로 실행하는 명령이다. sudo useradd 처럼 앞에 붙여 쓴다.

아래 재생기의 ▶를 누르면 한 스텝씩 진행된다. 금색 테두리가 지금 이야기하는 곳이고, 캡션이 무슨 일이 일어났는지 말해 준다. 굵게 밑줄 친 말은 누르면 뜻이 나온다. 빨간 딱지는 그때 벌어지는 일의 이름이고, 캡션 바로 위 회색 글자는 지금 스텝이 속한 묶음의 이름이다.

카드 아래 회색 줄은 그 일이 실제로 적혀 있는 소스의 파일 이름 : 줄 번호와 함수 이름이다. 글 안에 (:669)처럼 줄 번호만 적힌 것은 바로 앞에 적은 파일의 그 줄이라는 뜻이다. 캡션 한가운데 박힌 긴 영어 이름과 괄호 속 파일 · 줄 번호도 같다 — 건너뛰고 한글만 읽어도 뜻이 통하게 써 두었다.

장면 · 열기를 막는 자리는 한 곳이 아니다 0 / 12

▶ 를 누르면 cat /etc/shadow 가 어디서 무엇 때문에 막히는지 따라간다. 막는 관문이 하나가 아니라는 것, 그리고 화면에 찍히는 Permission denied 만으로는 어느 관문에서 막혔는지 알 수 없다는 것이 이 장면의 요지다.

키보드 · ← → 한 스텝 · Space 재생/멈춤 · Home 처음

막는 자리는 하나가 아니다. rwx 검사와 LSM 판정이 서로 다른 지점에서 일어나고, 둘 중 하나만 막아도 열기는 실패한다.

어떻게 확인했나

소스 어디를 보고 적었는지와 무엇을 돌려서 쟀는지를 남긴 자리다. 처음 읽을 때는 건너뛰어도 된다.

inode_permission(fs/namei.c:628)은 rwx 결과를 그대로 돌려주지 않는다 — 마지막 줄이 return security_inode_permission(inode, mask);(:661)이고 그것이 security/security.c:1838 로 간다. 소스에서 확인했다.
rwx 는 do_inode_permission(fs/namei.c:653) → generic_permission(:521) → acl_permission_check(:438) 순으로 내려간다. 주인 · 그룹 · 나머지 셋 중 하나만 보고 끝나는 것(:468 주인 분기, :471 · :496 의 두 -EACCES)을 확인했다.
경로를 지나는 디렉터리마다 x 를 본다 — link_path_walk(fs/namei.c:2578)이 칸마다 may_lookup(:1955)을 부르고, 경로 끝에서만 may_open(:4231)이 inode_permission(:4269)을 부른다.
root 가 통과하는 것은 rwx 비트 때문이 아니라 능력 때문이다 — generic_permission 이 -EACCES 직전에 CAP_DAC_OVERRIDE(fs/namei.c:558-561)를 본다.
이 커널에서 inode_permission 훅을 등록하는 모듈은 SELinux(security/selinux/hooks.c:7710 → 함수는 :3251)와 Smack(security/smack/smack_lsm.c:5178)뿐이다. AppArmor 의 훅 목록에는 없다 — AppArmor 는 file_open(security/apparmor/lsm.c:1790 → 함수는 :464)과 file_permission(:1792) 쪽에 꽂힌다. 목록을 직접 세어 확인했다.
avc_has_perm_noaudit(security/selinux/avc.c:1144)의 판정은 selinux_inode_permission 안의 rc 에 담긴다(security/selinux/hooks.c:3288). 기록할 것이 없으면 그 값이 그대로 돌아가고(:3296-3297), 기록할 것이 있으면 audit_inode_permission(:3299)을 거친 뒤 역시 같은 rc 를 돌려준다(:3303). 앞서 같은 판정을 캐시에서 찾으면 avc 까지 가지도 않고 0 을 돌려준다(:3270).
우분투 24.04(커널 7.0.0-31-generic)에서 확인했다. 켜져 있는 LSM 은 lockdown,capability,landlock,yama,apparmor,ima,evm 이고 — 목록에 apparmor 가 들어 있으며 /sys/module/apparmor/parameters/enabled 도 Y 다. /etc/apparmor.d 에 프로파일 112개가 실려 있다. 그러니 우분투 기본이 AppArmor 라는 것이 맞다. 다만 일반 계정 셸은 /proc/self/attr/apparmor/current 가 unconfined 라 어느 프로파일에도 안 갇혀 있다. 그 상태에서 cat /etc/shadow 를 하니 여전히 EACCES 로 막혔다 — AppArmor 가 이 프로세스를 안 가두는데도 막혔으니, 막은 것은 AppArmor 가 아니라 rwx 검사다. 앞서 소스에서 「AppArmor 훅에 inode_permission 이 없다」고 읽은 것이 실제 기계에서 그대로 나왔다. (이 컴퓨터의 도커로는 못 쟀다 — 컨테이너가 쓰는 호스트 커널이 우분투 커널이 아니라 WSL2 커널이라 AppArmor 가 없다. 같은 랜의 우분투 기계로 쟀다.)
openat 에서 나온다. 일반 계정으로 strace -e trace=openat cat /etc/shadow 를 하니 openat(AT_FDCWD, "/etc/shadow", O_RDONLY) = -1 EACCES (Permission denied) 한 줄이 찍혔다 — 읽기 전에 여는 자리에서 이미 막힌다.

‹ 이전 목차로 ›