Unix·Linux 구조와 계정

1. 커널은 자원 관리와 보호의 중심이다

커널(Kernel) 은 운영체제의 핵심 부분으로, 하드웨어와 가까운 위치에서 다음과 같은 자원을 관리한다.

• 프로세스와 CPU 실행
• 메모리
• 파일시스템
• 장치
• 네트워크
• 프로세스가 요청한 작업의 권한 검사

응용 프로그램이 디스크 파일을 읽거나 네트워크 소켓을 만들거나 새 프로세스를 실행하려 할 때, 보호된 자원에 대한 실제 처리는 커널의 기능을 사용해야 한다.

프로그램은 보통 라이브러리나 런타임을 거쳐 시스템 호출(System Call) 을 사용한다. 시스템 호출은 사용자 공간 프로그램이 커널 기능을 요청하는 대표적인 인터페이스다.

보안 관점에서 중요한 이유

프로그램이 “파일을 열고 싶다”고 요청했다고 해서 그대로 허용되는 것이 아니다. 커널은 그 프로그램을 실행 중인 프로세스의 사용자·그룹 식별자와 대상 객체의 권한 정보를 바탕으로 접근을 판단한다.

즉 다음 흐름을 기억해야 한다.

사용자 계정
   ↓
프로세스의 UID/GID 등 자격정보
   ↓
시스템 호출
   ↓
커널의 접근 검사
   ↓
허용 또는 거부

파일 권한 rwx와 SetUID·SetGID의 구체적인 계산은 Linux 파일 권한과 특수 권한에서 다룬다.

2. 셸은 커널이 아니라 명령을 해석하고 프로그램을 실행하는 사용자 공간 프로그램이다

셸(Shell) 은 사용자가 명령을 입력하고 프로그램을 실행할 수 있게 해 주는 명령 인터프리터다. 대표적으로 sh, bash, dash, zsh 등이 있다.

셸의 일반적인 역할은 다음과 같다.

1. 사용자가 입력한 명령을 해석한다.
2. 필요한 프로그램을 실행한다.
3. 파이프(|), 리다이렉션(>, <) 같은 명령 조합을 처리한다.
4. 환경 변수와 셸 스크립트 실행 환경을 제공한다.

예를 들어 다음 명령을 생각해 보자.

cat report.txt | grep ERROR

셸은 cat과 grep이라는 프로그램을 실행하고 파이프로 연결한다. 실제 파일 읽기와 프로세스·파이프 자원 처리는 결국 커널 기능을 사용한다.

따라서 다음 구분이 중요하다.

“셸이 사용자의 권한을 최종 판정한다”는 설명은 부정확하다. 셸은 명령 실행의 시작점이 될 수 있지만, 파일·프로세스·장치 등 보호 자원에 대한 핵심 권한 검사는 커널에서 이루어진다.

3. Unix/Linux 파일시스템은 하나의 디렉터리 트리로 보인다

Unix/Linux에서는 파일과 디렉터리가 /를 최상위로 하는 하나의 트리 구조에 배치된다.

/
├── etc
├── home
├── var
├── usr
├── tmp
└── ...

Windows의 드라이브 문자처럼 C:, D:가 각각 별도의 최상위 이름으로 보이는 방식과 다르게, Unix/Linux에서는 다른 파일시스템이나 장치도 특정 디렉터리에 마운트(Mount) 되어 하나의 트리 안에 연결될 수 있다.

보안에서는 이 구조가 중요한 이유가 있다.

• 계정 설정 파일도 파일시스템 안에 존재한다.
• 서비스 설정과 로그도 파일·디렉터리 형태로 관리되는 경우가 많다.
• 파일의 소유자와 그룹, 접근 권한이 시스템 보호의 기본 수단이 된다.
• 잘못된 소유권과 과도한 쓰기 권한은 설정 변조와 권한 악용의 원인이 될 수 있다.

하지만 파일시스템의 inode, 블록 할당 알고리즘, 각 파일시스템 구현의 내부 구조까지 모두 암기할 필요는 없다. 시스템 보안에서는 파일 객체가 소유자·그룹·권한 같은 메타데이터와 함께 관리되고, 커널이 이를 접근 판단에 사용한다는 점이 우선이다.

4. 계정 이름보다 UID와 GID가 핵심 식별자다

사용자는 dev01, websvc, root 같은 이름을 보지만, 운영체제는 사용자와 그룹을 숫자 식별자로 다룬다.

• UID(User ID): 사용자 식별 번호
• GID(Group ID): 그룹 식별 번호

예를 들어 다음과 같은 가상 계정이 있다고 하자.

로그인 이름 : dev01
UID         : 1001
기본 GID    : 1001
보조 그룹    : 10, 2000

파일 시스템에서 소유자를 표시할 때 사람이 보기 쉽게 dev01이라는 이름이 출력될 수 있지만, 핵심 소유권 식별에는 숫자 UID/GID가 사용된다.

이 때문에 다음 상황은 보안상 중요하다.

기존 파일 소유 UID = 1001
기존 계정 삭제
새 계정에 다시 UID 1001을 부여

이 경우 이름이 달라도 기존 UID 1001로 소유된 파일과 예상치 못한 관계가 생길 수 있다. 즉 계정 이름만 보고 소유권을 판단해서는 안 된다.

root의 핵심은 UID 0이다

Linux에서 특권 superuser의 핵심 식별자는 일반적으로 UID 0이다. root라는 이름이 널리 사용되지만 보안 판단에서 더 중요한 것은 숫자 식별자다.

따라서 다음이 핵심이다.

이름이 root인가?      → 참고 정보
UID가 0인가?          → 특권 판단에서 핵심 정보

의도하지 않은 계정이 UID 0을 공유하면 매우 큰 보안 위험이 된다.

5. /etc/passwd는 계정의 기본 정보를 저장하는 대표적인 로컬 파일이다

로컬 계정을 파일 기반으로 관리하는 전형적인 Linux/Unix 환경에서 /etc/passwd는 계정의 기본 정보를 담는다.

한 줄은 일반적으로 콜론(:)으로 나뉜 7개 필드를 가진다.

name:password:UID:GID:GECOS:home:shell

학습용 가상 예시는 다음과 같다.

dev01:x:1001:1001:Developer:/home/dev01:/bin/bash

각 필드는 다음 의미를 가진다.

/etc/passwd에 비밀번호 평문이 들어 있다고 보면 안 된다

현대의 일반적인 shadow password 환경에서는 /etc/passwd의 password 필드에 x가 있고, 실제 비밀번호 검증에 사용하는 해시 정보는 /etc/shadow에 분리된다.

따라서 다음 구분이 중요하다.

/etc/passwd  → 계정 식별·기본 속성
/etc/shadow  → 로컬 비밀번호 해시와 비밀번호 수명 관련 정보

/etc/passwd가 계정 기본 정보를 담는다고 해서 “시스템의 모든 사용자 정보가 반드시 이 파일에만 존재한다”는 뜻은 아니다. 외부 디렉터리의 계정 정보를 사용하는 구성도 있다.

6. /etc/shadow는 로컬 비밀번호 해시와 수명 정보를 분리해 보호한다

비밀번호 해시가 일반 사용자가 쉽게 읽을 수 있는 파일에 있으면 오프라인 추측 공격에 이용될 위험이 커진다. 그래서 shadow password 방식에서는 비밀번호 관련 민감 정보를 /etc/shadow에 분리하고 일반 사용자에게 읽기 권한을 주지 않는 것이 기본 보안 원칙이다.

/etc/shadow의 한 줄은 일반적으로 9개 필드로 구성된다.

login:password:lastchg:min:max:warn:inactive:expire:reserved

학습용 형식 예시는 다음과 같다. 실제 시스템에서 수집한 계정 정보가 아니다.

dev01:$hash$...:20500:0:90:7:14::

실제 빈 필드나 특수문자의 의미는 shadow 도구와 운영체제 구성에 따라 정확히 해석해야 한다. 시험 학습에서는 “비밀번호 해시 분리 보호 + 비밀번호 수명 관리”라는 역할을 먼저 이해한다.

계정 잠금과 비밀번호 잠금은 완전히 같은 말이 아니다

관리 도구가 비밀번호 해시 앞에 ! 같은 값을 사용해 비밀번호 기반 인증을 막는 경우가 있다. 그러나 그 계정이 SSH 공개키나 다른 인증 수단으로도 접근 가능한 환경이라면 “비밀번호를 잠갔다 = 모든 로그인 방법이 완전히 차단됐다”고 단정하면 안 된다.

따라서 실제 운영에서는 다음을 함께 본다.

• 비밀번호 잠금 상태
• 계정 만료 상태
• 로그인 셸
• SSH 등 서비스별 인증 정책
• 외부 디렉터리나 다른 인증 수단 사용 여부

7. /etc/group은 그룹 정보를 저장하며 기본 그룹과 보조 그룹을 구분해야 한다

대표적인 로컬 그룹 파일 /etc/group은 다음과 같은 형식을 가진다.

group_name:password:GID:user_list

예를 들어 다음은 학습용 가상 예시다.

developers:x:2000:dev01,dev02

여기서 2000은 그룹의 GID이고, 마지막 필드는 해당 그룹의 구성원 이름 목록을 나타낸다.

하지만 사용자의 그룹 소속을 판단할 때 /etc/group의 마지막 필드만 보면 안 된다.

사용자에게는 보통 다음 두 종류의 그룹 관계가 있다.

1. 기본 그룹(Primary Group): /etc/passwd 계정 항목의 GID 필드로 지정
2. 보조 그룹(Supplementary Groups): 추가로 소속된 그룹들

즉 어떤 사용자가 그룹의 기본 그룹 구성원인 경우 /etc/group의 구성원 이름 목록에 이름이 없어도 해당 GID와 관계될 수 있다.

보안 문제에서 “사용자가 어느 그룹의 권한을 적용받는가?”를 판단할 때는 기본 GID와 보조 그룹을 함께 확인해야 한다.

8. 로그인 셸은 계정의 사용 목적을 판단하는 단서다

/etc/passwd의 마지막 필드는 로그인 셸 또는 로그인 후 실행할 프로그램을 나타낸다.

일반 사용자 계정에는 다음처럼 실제 셸이 지정될 수 있다.

/bin/bash
/bin/sh

반면 서비스 전용 계정처럼 대화형 로그인이 필요하지 않은 계정은 nologin 계열 프로그램이나 false 계열 값을 사용해 대화형 로그인을 제한하는 구성이 사용되기도 한다.

중요한 점은 특정 경로를 무조건 외우는 것이 아니다. nologin 실행 파일의 경로는 시스템에 따라 다를 수 있다.

보안 판단은 다음과 같이 한다.

이 계정은 사람이 로그인해야 하는가?
        ↓
아니라면 대화형 셸이 정말 필요한가?
        ↓
불필요한 로그인 경로를 줄일 수 있는가?

또한 로그인 셸 제한만으로 모든 인증·서비스 접근이 자동 차단된다고 단정하지 않는다. 실제 허용 여부는 SSH, 파일 전송 서비스, PAM 구성 등 서비스의 동작 방식과 정책에 따라 달라질 수 있다.

9. 로그인 성공 후에는 ‘계정’이 아니라 프로세스의 자격정보가 실제 동작에 사용된다

사용자가 인증에 성공하면 로그인 세션과 셸, 그 이후 실행되는 프로그램들은 해당 사용자와 그룹에 대응하는 프로세스 자격정보(Credentials) 를 갖게 된다.

Linux 프로세스에는 여러 종류의 사용자·그룹 ID가 존재할 수 있다. 여기서는 다음 두 종류를 먼저 이해하면 된다.

• Real UID/GID: 프로세스의 실제 소유 주체를 나타내는 기본 식별자. 일반적인 로그인 세션에서는 로그인 사용자의 ID에서 시작한다.
• Effective UID/GID: 여러 권한 검사에서 현재 프로세스의 권한을 판단하는 핵심 식별자

또한 사용자는 하나 이상의 보조 그룹(Supplementary Groups) 에 속할 수 있으며, 이 그룹들도 파일과 다른 자원의 접근 검사에 사용될 수 있다.

일반적인 권한 문제에서는 Real ID와 Effective ID를 구분한다. 파일 접근에 추가 ACL이나 별도 보안 정책이 주어진 경우에는 그 조건도 함께 확인한다.

자식 프로세스는 어떻게 되는가?

일반적으로 새로 생성된 자식 프로세스는 부모 프로세스의 사용자·그룹 자격정보를 이어받는다.

예를 들어 다음 흐름을 생각할 수 있다.

로그인 성공
  ↓
사용자 셸: UID 1001
  ↓
셸이 편집기 실행
  ↓
편집기 프로세스도 기본적으로 UID 1001의 권한으로 동작

따라서 단순히 “어떤 명령을 실행했는가”만 볼 것이 아니라 그 명령을 어떤 UID/GID의 프로세스가 실행했는가를 함께 봐야 한다.

SetUID·SetGID처럼 실행 중 Effective ID가 달라질 수 있는 특수한 경우는 Linux 파일 권한과 특수 권한에서 파일 권한과 함께 다룬다.

좌우로 이동해 그림을 확인하세요.그림 크게 보기

10. 서비스 계정은 ‘로그인 가능 여부’와 ‘실행 권한’을 따로 판단한다

웹 서버나 데이터베이스 같은 서비스는 사람이 직접 로그인하지 않아도 특정 계정의 권한으로 실행될 수 있다.

예를 들어 websvc라는 서비스 계정이 있다고 하자.

websvc:x:1500:1500:Web Service:/var/lib/websvc:/usr/sbin/nologin

이 계정이 대화형 로그인을 제한하도록 구성되어 있더라도 서비스 관리자가 해당 계정 자격으로 웹 서버 프로세스를 시작할 수 있다.

따라서 다음 두 질문은 다르다.

“사람이 이 계정으로 셸 로그인할 수 있는가?”
“서비스 프로세스가 이 계정의 UID/GID로 실행될 수 있는가?”

서비스 계정 보안에서는 대화형 로그인 제한뿐 아니라 그 계정이 가진 파일·디렉터리·소켓·서비스 접근 권한 자체가 최소화되어 있는지를 함께 확인해야 한다.