Step 24. 권한 2 — 소유권과 sudo, 힘을 다스리는 법

Level 0 — 컴퓨터 조작과 구조의 이해 | 난이도 ★★☆☆☆ | 예상 소요 시간 3시간

전제: Step 23(rwx 권한)을 끝냈어야 합니다. 우분투 가상머신(또는 WSL)이 필요합니다.

준비물: 우분투 터미널.
주의: 오늘은 시스템 영역(/etc)을 읽는 실험이 나옵니다. 조회는 안전하지만, 3-5절의 파일 생성·삭제 실험은 챕터의 지시 대상(test-write.txt)에만 정확히 사용하세요.
안내: 시스템 파일의 권한 조회는 실측했고, sudo로 실행하는 명령의 출력은 "출력 예시"로 표기했습니다.

지난 챕터에서 우리는 "누가 무엇을 해도 되는가"를 배웠습니다. 그런데 질문이 하나 남습니다. 그 규칙 위에 있는 존재는 없을까? 모든 파일을 읽고, 모든 설정을 바꾸고, 모든 사용자를 지울 수 있는 존재 말입니다.

있습니다. 리눅스에는 root라는 최고 관리자 계정이 있습니다. root 앞에서는 Step 23의 권한 문자열이 무의미해집니다 — 권한이 ----------이어도 root는 읽습니다. 문제는 그 힘을 평소에 쓰면 재앙이라는 것입니다. 오늘의 주제는 sudo의 사용법이기 이전에, "힘을 어떻게 다스릴 것인가"라는 보안 철학의 첫 수업입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

root(UID 0)가 무엇이며, 왜 권한 검사를 우회하는지 설명한다
sudo의 동작 순서(자격 확인 → 본인 확인 → 그 명령만 root로)를 설명한다
/etc/shadow가 왜 보호되는지, 저장되는 것이 비밀번호가 아니라 해시(hash)임을 안다
최소 권한 원칙(Principle of Least Privilege)을 자기 말로 설명한다
어떤 명령에 sudo가 필요한지(내 홈 안 vs 시스템 영역) 스스로 판단한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	우분투 터미널(배시 셸), 인터넷 불필요
오늘의 명령어	`whoami`(나는 누구), `sudo 명령`(그 명령만 root로), `sudo -i`(root로 상주), `ls -l /etc/shadow`(보호된 파일 관찰)
필요한 개념	root와 UID 0, sudo와 sudoers, 해시, 최소 권한 원칙

2-1. root — 모든 것의 소유자

root는 사용자 번호(UID) 0번인 특별한 계정입니다. 커널(운영체제의 심장)은 UID가 0이면 권한 검사를 사실상 건너뜁니다. 시스템 파일 수정, 사용자 추가·삭제, 다른 사람 파일 읽기, 네트워크 설정 변경 — 전부 가능합니다.

그래서 root 비밀번호는 시스템 전체의 열쇠입니다. 해커가 서버를 공격할 때 최종 목표가 "root 권한 획득"인 이유이고, 공격자가 "어떻게든 자기 코드를 UID 0으로 실행시키려는" 시도를 권한 상승(privilege escalation)이라 부릅니다. 방어자는 그 경로를 전부 막으려 합니다 — 이 한 줄이 이후 공격·방어 모든 기술의 출발점입니다.

2-2. sudo — 임시 통행증

sudo는 "superuser do(슈퍼유저로서 실행하라)"의 약자입니다. 명령 앞에 붙이면 그 명령 하나만 root 권한으로 실행됩니다:

sudo cat /etc/shadow

이 명령의 흐름은 이렇습니다. ① 시스템이 "이 사용자가 sudo를 쓸 자격이 있나?"를 확인합니다 — 설정 파일 /etc/sudoers에 등록된 사용자만 가능하고, 우분투는 설치 시 만든 첫 계정이 자동 등록됩니다. ② 내 비밀번호로 본인 확인. ③ 그 명령 하나만 root로 실행. ④ 끝나면 다시 평범한 사용자.

Step 21에서 apt를 쓸 때 비밀번호를 입력해도 화면에 아무것도 안 보였던 기억이 있을 겁니다. 그게 sudo의 본인 확인이었습니다. 표시가 없어도 입력은 되고 있으니 치고 Enter를 누르면 됩니다. 그리고 한 번 확인하면 기본 15분 동안은 다시 묻지 않습니다.

2-3. 최소 권한 원칙

보안의 제1원칙으로 꼽히는 철학입니다:

모든 사용자·프로그램은, 자기 일을 하는 데 필요한 최소한의 권한만 가져야 한다.

평소에 root로 로그인해서 웹서핑까지 하는 것은, 통장 비밀번호를 포스트잇에 써서 모니터에 붙여 놓는 것과 같습니다. 실수 한 번, 악성코드 한 번이 곧바로 시스템 전체 파괴로 이어집니다. 반면 평소엔 일반 사용자로 있다가 필요한 순간만 sudo를 쓰면, 피해 범위가 "내 계정"에 머뭅니다. sudo는 이 원칙을 실천하기 위한 도구입니다.

2-4. /etc/shadow — 왕국의 보물함

리눅스의 사용자 비밀번호는 /etc/shadow 파일에 저장됩니다. 정확히는 비밀번호 자체가 아니라, 그것을 일방향으로 뭉갠 해시(hash)가 저장됩니다. 해시는 계산은 빠르지만 거꾸로 풀 수 없게 설계된 함수입니다.

왜 해시를 저장할까요? 이 파일이 털리더라도 실제 비밀번호를 모르게 하려는 것입니다. 다만 "생일축하1234" 같은 흔한 비밀번호는 후보를 하나씩 해시해 비교하는 공격(패스워드 크래킹)에 뚫릴 수 있어서, 해시 목록 자체를 아무에게나 보여 주지 않습니다. 그래서 이 파일은 root만 읽을 수 있게 보호되어 있고, Level 2에서 패스워드 크래킹을 배울 때 다시 만납니다.

3. 따라 하기

3-1. 나는 누구인가 — whoami

whoami

lee

(출력 예시 — 여러분의 우분투 설치 시 만든 계정 이름이 나옵니다.)

sudo whoami

root

(출력 예시 — 처음 sudo를 쓰거나 마지막 사용 후 15분이 지났다면 먼저 비밀번호를 묻습니다. 화면에 아무것도 안 떠도 입력은 되고 있습니다.)

읽는 법: 같은 whoami인데 sudo를 붙이자 대답이 root로 바뀌었습니다. "sudo는 명령 하나에 root의 옷을 입히는 것"이라는 정의를 눈으로 확인하는 실험입니다.

3-2. 보호된 파일 열어 보기 — /etc/shadow

먼저 Step 23에서 배운 대로 이 파일의 권한 문자열을 읽어 봅시다:

ls -l /etc/passwd /etc/shadow /etc/sudoers

-rw-r--r-- 1 root root   1490 Sep  8 21:12 /etc/passwd
-rw-r----- 1 root shadow  746 Sep  8 21:12 /etc/shadow
-r--r----- 1 root root   1800 Jan 30  2024 /etc/sudoers

(2026-09-09 우분투 24.04 실측. 크기·날짜는 다를 수 있습니다.)

출력 읽는 법:

/etc/passwd — 644. 비밀번호가 아니라 사용자 명단이 들어 있어 모두 읽기 가능입니다
/etc/shadow — 640에 root shadow. 소유자 root는 rw-, 그룹 shadow는 r--, 기타(우리 포함)는 --- — 아무것도 못 합니다
/etc/sudoers — 주목할 점: 소유자인 root조차 r--, 즉 읽기 전용입니다. 쓰기 권한이 아무에게도 없습니다

권한대로라면 우리는 shadow를 읽을 수 없습니다. 확인해 봅시다:

cat /etc/shadow

cat: /etc/shadow: Permission denied

(출력 예시.)

예측해 보기: 그렇다면 sudo cat /etc/shadow는 어떻게 될까요? 실행 전에 예측해 보세요.

sudo cat /etc/shadow

root:$6$abc...:19000:0:99999:7:::
lee:$6$xyz...:19000:0:99999:7:::
...

(출력 예시 — 실제 해시 값은 시스템마다 다르며, 남에게 보여 주면 안 되는 값입니다.)

읽는 법: 한 줄이 한 사용자입니다. lee: 뒤의 긴 문자열이 여러분 비밀번호의 해시이고, $6$ 은 SHA-512 기반 해시 방식이라는 표시입니다. 실제 비밀번호는 어디에도 적혀 있지 않습니다. root의 옷을 입으니 권한 문자열의 벽을 넘었습니다 — 이것이 "권한 상승"의 정상적인 모습입니다. 동시에 여러분은 방금 "이 해시 목록이 외부로 새어 나가면 안 되는 이유"를 눈으로 본 겁니다.

3-3. sudoers 파일과 visudo

3-2절 실측에서 /etc/sudoers는 root조차 읽기 전용(-r--r-----)이었습니다. 왜 이렇게 지킬까요? 이 파일은 "누가 sudo를 쓸 수 있는가"를 정하는 명단이고, 문법 오류 하나만 있어도 시스템의 sudo 전체가 마비될 수 있기 때문입니다.

그래서 이 파일은 직접 vim으로 고치는 것이 아니라 sudo visudo라는 전용 도구로 편집합니다. visudo는 저장할 때 문법을 검사해 오류가 있으면 경고해 줍니다. 지금 단계에서는 "함부로 손대지 않는 파일"이라는 것만 기억하세요.

3-4. root로 상주해 보기 — 그리고 왜 위험한지

sudo -i
whoami

root

(출력 예시.)

읽는 법: 프롬프트가 root@ubuntu:~#처럼 #으로 끝나게 바뀝니다. # 프롬프트는 "지금 당신은 root다"라는 경고등입니다. 일반 사용자는 $입니다. 이 상태에서는 sudo 없이 모든 명령이 root로 실행됩니다.

왜 위험한가: 이 상태에서 rm -rf / 같은 실수를 하면 되돌릴 방법이 없습니다. 편해 보이지만, 평소 작업을 root로 상주하며 하는 습관은 최소 권한 원칙의 정면 반대입니다. 확인했으면 반드시 돌아오세요:

exit

3-5. sudo 필요 여부 스스로 판단하기

어떤 명령에 sudo를 붙여야 할지 헷갈릴 때의 실전 규칙을 몸으로 익혀 봅시다. 시스템 설정이 모인 /etc에 파일을 만들어 보면:

touch /etc/test-write.txt

touch: cannot touch '/etc/test-write.txt': Permission denied

(출력 예시.)

sudo touch /etc/test-write.txt
ls -l /etc/test-write.txt

-rw-r--r-- 1 root root 0  9월 9일 11:05 /etc/test-write.txt

(출력 예시.)

읽는 법: /etc는 일반 사용자가 쓸 수 없는 시스템 영역입니다. sudo를 붙이자 만들어졌고, 소유자가 root입니다.

⚠️ rm은 파일을 복구 불가능하게 지우는 파괴적 명령입니다. 리눅스에는 휴지통이 없습니다. 지금은 방금 우리가 만든 실험 파일 하나만 지웁니다 — 대상 경로를 두 번 확인하고 실행하세요.

sudo rm /etc/test-write.txt

판단 규칙은 간단합니다. 내 홈 폴더(/home/lee, 즉 ~) 안의 일은 sudo가 필요 없고, 그 바깥 — /etc, /var, /usr 같은 시스템 영역 — 을 건드리는 일은 sudo가 필요합니다. "이 파일이 내 집 안에 있나, 공공시설에 있나"라고 물으면 됩니다. 공공시설의 열쇠가 sudo입니다.

덤으로 하나 더. sudo nano ~/note.txt처럼 내 집 안의 파일까지 sudo로 편집하면, 그 파일의 소유자가 root로 바뀌어 정작 나(일반 사용자)가 못 고치는 일이 생깁니다. sudo는 필요한 곳에만 쓰는 것이 원칙입니다.

4. 미션과 연습문제

미션 — 권한 감시관 되어 보기

ls -l /etc/passwd /etc/shadow /etc/sudoers를 실행하고, 세 파일의 권한 문자열 각각을 "누가 무엇을 할 수 있는가"로 해석해 종이에 적으세요
sudo cat /var/log/auth.log 2>/dev/null | grep sudo | tail -5를 실행해, 방금 여러분이 쓴 sudo 명령들이 로그에 기록되어 있음을 확인하세요 (WSL 등 auth.log가 없는 환경이라면 sudo journalctl 2>/dev/null | grep sudo | tail -5를 시도해 보세요)
"root로 상주하는 것이 위험한 이유"를 최소 권한 원칙의 관점에서 5문장 이상으로 정리해 least-privilege.txt에 저장하세요
현재 자신이 root인지 아닌지 판단하는 두 가지 방법(프롬프트 기호, whoami)을 직접 확인하세요

답은 여기 쓰지 않습니다 — 5절에서 검증합니다.

연습문제

문제 1. 다음 명령 중 sudo가 필요한 것에 O, 아닌 것에 X를 매겨 보세요: ls ~, sudo apt update, cat /etc/shadow, nano note.txt, nano /etc/hosts, mkdir ~/test

문제 2. /etc/shadow에 실제 비밀번호 대신 해시를 저장하는 이유는 무엇이며, 그런데도 이 파일을 root만 읽게 막는 이유는 무엇일까요?

문제 3. sudo echo "x" > /etc/some.conf가 "Permission denied"로 실패했습니다. sudo를 붙였는데 왜 실패할까요?

문제 4. 회사에서 sudo 권한을 함부로 주지 않는 이유를 "로그"의 관점에서 설명해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

ls -l /etc/passwd /etc/shadow /etc/sudoers
sudo cat /var/log/auth.log 2>/dev/null | grep sudo | tail -5
nano least-privilege.txt   # 5문장 이상 작성 후 저장
whoami                     # 프롬프트 끝 글자($/#)와 함께 확인

검증하는 법:

① 세 파일의 해석이 3-2절 실측 표와 같은 구조면 정상입니다 — passwd는 644(모두 읽기), shadow는 640+root:shadow(기타 차단), sudoers는 440(root조차 읽기 전용)
② 로그에 lee : TTY=... ; COMMAND=/usr/bin/... 같은 줄이 보이면 확인 완료 — 여러분이 쓴 sudo가 전부 기록되고 있다는 것이 핵심입니다
③ 문단에 "실수·악성코드의 피해 범위가 계정에 머문다"는 뜻이 들어갔는지 스스로 확인하세요
④ 일반 사용자라면 프롬프트가 $로 끝나고 whoami가 내 이름을 출력해야 합니다

연습문제 해답

문제 1 해답. O, O, X, X, O, X 순서입니다 — 정리하면 ls ~(X, 내 집 보기), apt update(O, 시스템 목록 갱신), cat /etc/shadow(O, root 전용 파일), nano note.txt(X, 내 집 파일), nano /etc/hosts(O, 시스템 파일이라 쓰기에 root 필요), mkdir ~/test(X, 내 집 안). 기준은 하나입니다: "내 홈 안인가, 시스템 영역인가."

문제 2 해답. 해시는 일방향이라 파일이 털려도 실제 비밀번호를 직접 알아낼 수 없게 하려는 것입니다. 그런데도 막는 이유는, 흔한 비밀번호는 "후보를 해시해 비교"하는 크래킹으로 뚫릴 수 있어 해시 목록 자체가 공격 재료이기 때문입니다.

문제 3 해답. sudo는 echo에만 적용되고, >로 파일을 여는 것은 원래 사용자(권한 없음)의 쉘이 하기 때문입니다. sudo는 파이프·리다이렉션 뒤편까지 책임지지 않습니다. 이럴 땐 echo "x" | sudo tee /etc/some.conf를 씁니다.

문제 4 해답. sudo는 "감시되는 권한"이기 때문입니다. 누가 언제 어떤 명령을 sudo로 썼는지 전부 /var/log/auth.log에 남습니다. 침해 사고 조사에서 이 로그의 sudo 기록은 핵심 증거입니다 — "해킹당한 서버에서 sudo를 쓴 흔적"은 공격자가 이미 정상 계정을 탈취했다는 뜻이니까요.

완료 기준 체크리스트

[ ] root(UID 0)가 무엇이며 권한 문자열을 무시할 수 있는 이유를 설명할 수 있다
[ ] whoami와 sudo whoami의 차이를 보여 줄 수 있다
[ ] /etc/shadow의 권한 문자열을 읽고 보호 이유를 설명할 수 있다
[ ] 최소 권한 원칙을 자기 말로 설명할 수 있다
[ ] 프롬프트의 $와 #의 차이를 안다
[ ] sudo 사용 기록이 로그에 남는 것을 확인했다
[ ] 미션: 권한 감시관 4개 임무를 완수했다

6. 흔한 실수와 해결

벽 1. "sudo를 쳤는데 ‘not in the sudoers file’이 나와요."

증상: "사용자가 sudoers 파일에 없습니다"라는 오류가 뜹니다.
원인: 이 계정은 sudo 사용 명단에 등록되지 않은 사용자입니다.
해결: 우분투 설치 시 만든 첫 계정으로 로그인했는지 확인하세요. 새로 만든 연습 계정은 기본적으로 sudo 권한이 없습니다 — 오히려 "권한은 기본적으로 없고, 부여되는 것"이라는 좋은 교훈입니다.

벽 2. "sudo를 붙였는데도 Permission denied가 나와요."

증상: sudo echo "x" > /etc/파일 류가 거부됩니다.
원인: 리다이렉션의 함정입니다. sudo는 echo에만 적용되고 >는 원래 사용자의 쉘이 처리합니다.
해결: echo "x" | sudo tee /etc/파일을 쓰세요. "sudo는 파이프·리다이렉션 뒤편까지 책임지지 않는다"만 기억하면 됩니다.

벽 3. "sudo su를 쓰라는 글을 봤어요. sudo -i와 뭐가 다른가요?"

증상: 인터넷 명령 모음마다 root가 되는 방법이 제각각입니다.
원인: sudo -i, sudo su, sudo -s는 모두 "root 셸 열기"이지만 환경 설정이 미묘하게 다릅니다.
해결: 지금 단계에서는 어느 쪽이든 "root로 상주하게 되는 것"이 본질이고, 그래서 평소에 쓰지 않는 것이 정답입니다. root가 필요하면 명령 하나에 sudo를 붙이는 습관을 만드세요.

벽 4. "비밀번호를 치는데 화면에 아무것도 안 나와요."

증상: sudo 비밀번호 입력 시 커서가 움직이지 않고 별표도 안 뜹니다.
원인: 고장이 아니라 보안 기능입니다. 비밀번호 길이조차 옆 사람에게 노출하지 않기 위한 유닉스의 오래된 전통입니다.
해결: 정상이니 그냥 치고 Enter를 누르세요. 틀리면 다시 물어봅니다.

벽 5. "내 파일인데 못 고쳐요. 소유자가 root가 됐어요."

증상: ls -l을 보니 내 홈의 파일 소유자가 root입니다.
원인: sudo nano ~/note.txt처럼 내 집 안 파일을 sudo로 만들거나 편집했기 때문입니다.
해결: sudo chown lee:lee 파일명으로 소유자를 되돌리세요. 그리고 앞으로는 내 홈 안 일에 sudo를 쓰지 마세요.

7. 정리

오늘의 개념

개념	한 줄 설명
root	UID 0의 최고 관리자 — 모든 권한 검사를 우회
sudo	"이 명령 하나만 root로" 실행하는 임시 통행증 — 전부 로그에 기록
/etc/shadow	비밀번호 해시의 보관함 — root만 읽기 가능
해시(hash)	거꾸로 풀 수 없는 일방향 변환 — 비밀번호의 안전한 저장 형태
최소 권한 원칙	필요한 만큼의 권한만, 필요한 순간에만

오늘의 명령어

명령	하는 일
`whoami`	현재 사용자 확인
`sudo 명령`	그 명령 하나만 root로 실행
`sudo -i` → `exit`	root로 상주 → 반드시 복귀
`ls -l /etc/shadow`	보호된 파일의 권한 관찰
`sudo rm 파일`	파일 삭제 (⚠️ 복구 불가, 대상 확인 필수)

명령어보다 중요한 감각

오늘 배운 것은 명령어가 아니라 태도에 가깝습니다. "평소에는 작은 권한으로, 필요할 때만 크게" — 이 한 줄이 서버를 운영하는 모든 전문가의 공통 습관입니다. sudo를 쓸 때마다 한 번씩 물어보세요. "지금 이 명령에 정말 신의 힘이 필요한가?"

두 가지를 더 기억해 두세요. 첫째, 같은 문을 두고 한쪽은 지키는 법을, 다른 한쪽은 여는 법을 연구합니다 — 공격자의 핵심 연구 주제가 "작은 권한에서 큰 권한으로 올라가기(권한 상승)"이고, 오늘 여러분은 그 문의 정당한 구조를 본 것입니다. 둘째, 윈도우의 "관리자 권한으로 실행"(UAC 팝업)도 sudo와 같은 철학입니다. 최소 권한 원칙은 리눅스만의 이야기가 아니라, 운영체제 전체를 관통하는 보안의 공용어입니다.

전부 체크되면 Step 24 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.