02. Linux 보안 모델 이해

Linux 시스템 보안 기초 · 02/50편

이 글은 리눅스 시스템 기초 · 파일 · 권한 · 사용자 관리 · 서비스 · 프로세스 관리 시리즈를 선행 학습으로 두고, 동일한 개념을 보안관제(SOC) 관점에서 한 단계 확장합니다.

선행 학습

• 리눅스 시스템 기초 — Kernel의 역할
• 리눅스 시스템 기초 — User Space와 Kernel Space

1. 들어가며

리눅스 보안은 하나의 큰 스위치가 아니라, 여섯 개의 부품이 맞물린 기계입니다. User, Group, Process, File, Permission, Kernel — 이 중 하나만 이해하면 침해 분석에서 '왜 이 프로세스가 이 파일을 읽을 수 있었나'를 설명하지 못합니다. 이번 편은 그 연결 고리를 세웁니다.

2. 핵심 개념

각 요소의 보안적 역할입니다.

User (UID) ──소속──> Group (GID)
   │
   │ 로그인/실행
   ▼
Process (EUID/EGID로 행동)
   │ open() / read() / write()
   ▼
Kernel ──[Permission 비트 검사]──> File (inode)
          허용 or 거부(EACCES)

3. 동작 원리

핵심은 '파일이 스스로를 지키지 않는다' 는 점입니다. 접근을 허용/거부하는 주체는 커널입니다.

프로세스가 파일을 열려고 open() 시스템 콜을 호출하면, 커널은 그 프로세스의 유효 UID/GID(EUID/EGID) 와 파일 inode에 저장된 소유자·그룹·권한 비트를 비교해 허용 여부를 결정합니다. 그래서 침해 분석에서 '이 파일이 읽혔다'는 곧 '어떤 프로세스가 어떤 권한으로 커널의 검사를 통과했다'는 뜻입니다.

4. 명령어 실습

# 프로세스가 어떤 UID/EUID로 도는지
ps -eo pid,user,euser,comm | head

# 파일 inode의 소유자·권한 확인
stat /etc/shadow

# 한 프로세스가 연 파일들 (커널이 허용한 접근의 결과)
sudo lsof -p 1 | head

5. 실행 결과

실습 환경에서 /etc/shadow의 inode 정보입니다. (실제 캡처)

$ stat /etc/shadow
  File: /etc/shadow
  Size: ...        Blocks: ...     IO Block: 4096   regular file
Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (   42/  shadow)

권한이 0640, 그룹이 shadow 라는 점이 보안의 핵심입니다. 일반 사용자는 소유자도 shadow 그룹도 아니므로 other 비트(---) 에 걸려 읽기가 거부됩니다. 즉 '해시가 노출되지 않는' 기밀성이 바로 이 세 글자로 구현되어 있습니다.

6. 보안 관점 — 정상 사용 vs 악용

• 정상: /etc/shadow가 root:shadow 0640, 실행 바이너리가 적절한 소유자를 가진다.
• 악용 징후: 중요한 파일의 권한이 느슨해지거나(예: shadow가 0644), 프로세스가 예상보다 높은 EUID로 도는 경우. SUID 바이너리 악용은 '프로세스의 EUID를 root로 바꾸는' 대표적 공격으로, 18편에서 깊게 다룹니다.

이 모델을 이해하면 이후 모든 권한 상승(Privilege Escalation) 기법이 결국 '프로세스의 EUID를 어떻게 올렸는가'라는 한 문장으로 정리됩니다.

7. 탐지 방법

• 프로세스-사용자 매핑 이상: ps -eo pid,user,euser,comm 에서 user와 euser가 다른 프로세스 주목
• 중요 파일 권한 변화: stat의 Modify/Change 시각, 이후 편의 auditd watch
• 예상 밖 파일 접근: lsof로 프로세스가 연 민감 파일 확인

8. SOC 관점 — SIEM · Wazuh · IOC

SIEM에서는 프로세스 생성 이벤트(EDR/auditd execve)에 user, euid 필드를 함께 수집해야 권한 상승을 탐지할 수 있습니다. Wazuh의 경우 audit 디코더가 auid/euid를 파싱하며, euid=0 이면서 auid가 일반 사용자인 이벤트는 권한 상승의 강한 지표(IOC)입니다.

9. 실습 체크리스트

[ ] 6요소의 역할을 한 줄로 설명해 본다
[ ] 프로세스의 user와 euser 차이를 확인한다
[ ] 중요 파일의 stat 권한/소유자를 읽는다
[ ] 커널이 접근을 결정한다는 점을 이해한다

10. 핵심 정리

• 리눅스 보안은 User·Group·Process·File·Permission·Kernel의 상호작용이다.
• 접근 허용/거부의 최종 심판은 커널이다.
• 프로세스는 EUID/EGID로 행동하며, 이것이 권한 상승 분석의 축이다.
• 파일 기밀성은 권한 비트 세 글자(other)로 구현된다.
• 권한 상승은 결국 'EUID를 어떻게 올렸는가'의 문제다.

11. 다음 편

다음 편에서는 03. DAC와 MAC의 차이 를 다룹니다. 권한 모델을 DAC와 MAC으로 나누고, SELinux/AppArmor가 왜 필요한지 봅니다.

본 실습은 격리된 테스트 VM(Rocky Linux / Ubuntu, VMware) 및 테스트 계정 환경을 기준으로 하며, 운영 서버를 대상으로 하지 않습니다. 실행 결과는 실제 캡처와 예시 출력을 명확히 구분해 표기합니다.