DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

특수 권한을 활용한 리눅스 파일 시스템 보안 모범 사례

SUID, SGID, Sticky Bit와 같은 특수 권한을 활용하여 리눅스 파일 시스템 보안을 마스터하세요. 이 가이드는 8진수 표기법을 사용하여 이러한 모드를 안전하게 적용하는 방법을 설명합니다. 실행 컨텍스트를 강화하고, 공유 폴더에서 그룹 상속을 보장하며, /tmp와 같은 디렉토리에서 무단 파일 삭제를 방지하는 방법을 실용적인 예제와 함께 제공하여 시스템을 강화합니다.

특수 권한을 활용한 리눅스 파일 시스템 보안 모범 사례

특수 권한은 ls -l 출력에서 작게 보이지만 프로덕션 환경에서 매우 중요한 리눅스 기능 중 하나입니다. 루트 소유 바이너리에 추가된 s 하나로 일반 사용자가 제한된 권한 작업을 수행할 수 있습니다. 공유 업로드 디렉토리에 t가 없으면 사용자가 서로의 파일을 삭제할 수 있습니다. 프로젝트 디렉토리에 SGID 비트가 설정되어 있으면 그룹 소유권 문제를 지속적으로 해결할 수 있습니다.

목표는 특수 비트를 무분별하게 사용하는 것이 아닙니다. 목표는 SUID, SGID, Sticky Bit가 실제 접근 문제를 해결하는 경우와 나중에 후회할 권한 경로를 생성하는 경우를 아는 것입니다.

표준 권한 요약 이해

특수 권한을 살펴보기 전에 표준 3중 표기법(소유자, 그룹, 기타에 대한 rwx)을 기억하는 것이 중요합니다. 이러한 권한은 8진수 값(예: 755 또는 644)을 사용하여 숫자로 표시됩니다.

  • r (읽기) = 4
  • w (쓰기) = 2
  • x (실행) = 1

특수 권한은 이 기본 동작을 수정하며 네 번째 선행 8진수(4, 2 또는 1)로 표시됩니다.

특수 권한: SUID, SGID 및 Sticky Bit

특수 권한은 표준 접근 제어 이상의 기능을 추가합니다. 일반적으로 긴 목록(ls -l) 출력에서 표준 x 플래그를 대체하는 s 또는 t로 표시됩니다.

권한 8진수 값 효과
SUID (Set User ID) 4 파일이 파일 소유자의 권한으로 실행됩니다(실행하는 사용자가 아님).
SGID (Set Group ID) 2 파일이 파일 그룹의 권한으로 실행되거나, 새 파일이 상위 디렉토리의 그룹 ID를 상속받습니다.
Sticky Bit 1 공유 디렉토리에서 다른 사용자가 소유한 파일을 삭제하거나 이름을 바꾸는 것을 방지합니다. 디렉토리에 쓰기 권한이 있어도 마찬가지입니다.

1. Set User ID (SUID)

SUID 비트는 강력하지만 잘못 사용하면 잠재적으로 위험합니다. 실행 파일에 설정되면 해당 파일을 실행하는 모든 사용자가 소유자의 권한으로 프로세스를 실행합니다.

실용적인 사용 사례: 특정 작업을 수행하기 위해 루트 권한이 필요하지만 사용자에게 일반적인 루트 액세스를 부여해서는 안 되는 유틸리티.

예: /usr/bin/passwd에 SUID 설정

/usr/bin/passwd 명령은 일반적으로 보안이 중요한 /etc/shadow 파일을 수정하기 위해 루트 액세스가 필요합니다. SUID 비트가 설정되어 있어 일반 사용자가 자신의 암호를 변경하기 위해 passwd를 실행하는 동안에만 소유자(루트)의 권한을 일시적으로 얻을 수 있습니다.

SUID 확인: 소유자 실행 슬롯의 s를 확인하세요.

ls -l /usr/bin/passwd
# 출력 예시: -rwsr-xr-x 1 root root ... /usr/bin/passwd

SUID 설정: 표준 권한과 함께 8진수 값 4를 사용합니다(예: 755는 4755가 됨).

# 'my_script'가 'appuser' 소유라고 가정
chmod 4755 /path/to/my_script

SUID 보안 경고: 범용 셸(예: /bin/bash)이나 외부 입력을 해석하는 광범위한 유지 관리 스크립트에는 SUID 비트를 절대 설정하지 마세요. 스크립트에 권한이 필요한 경우, 좁은 sudoers 규칙, 작은 검토된 도우미 또는 서비스 API가 일반적으로 더 안전합니다.

호스트를 감사할 때 SUID 파일은 의도적인 권한 교차점이므로 주의를 기울여야 합니다.

sudo find / -xdev -type f -perm -4000 -ls 2>/dev/null

-xdev는 현재 파일 시스템에서 검색을 유지합니다. /proc, 마운트된 백업 또는 네트워크 파일 시스템이 결과를 복잡하게 만들 수 있는 경우 유용합니다. 별도 마운트가 있는 서버에서는 각 실제 파일 시스템을 의도적으로 검색하세요.

2. Set Group ID (SGID)

SGID 비트는 파일에 적용되는지 디렉토리에 적용되는지에 따라 두 가지 주요 기능이 있습니다.

A. 실행 파일의 SGID

실행 파일에 설정되면 프로세스는 사용자의 기본 그룹이 아닌 파일의 그룹 소유권과 관련된 권한으로 실행됩니다.

B. 디렉토리의 SGID (공유 환경에 중요)

디렉토리에 설정되면 그 안에 생성된 모든 새 파일이나 하위 디렉토리는 파일을 만든 사용자의 기본 그룹이 아닌 상위 디렉토리의 그룹 소유권을 자동으로 상속받습니다.

실용적인 사용 사례: 모든 기여자가 협업을 위해 통합된 그룹 액세스 권한을 가져야 하는 공유 프로젝트 폴더.

디렉토리에 SGID 설정: 표준 권한과 함께 8진수 값 2를 사용합니다(예: 775는 2775가 됨).

# 그룹 소유권을 'developers'로 설정하고 SGID 활성화
chgrp developers /srv/shared_project
chmod 2775 /srv/shared_project

이렇게 하면 그룹 상속이 처리되지만 모든 새 파일이 그룹 쓰기 가능하다는 보장은 없습니다. 사용자의 umask는 여전히 중요합니다. 기여자가 077과 같은 제한적인 umask로 파일을 생성하면 파일은 developers 그룹을 상속받지만 그룹이 읽거나 쓸 수 없을 수 있습니다. 공유 디렉토리의 경우 예상되는 umask, 기본 ACL 또는 애플리케이션 수준 파일 생성 설정을 확인하세요.

getfacl /srv/shared_project
setfacl -d -m g:developers:rwx /srv/shared_project

기본 ACL은 경로 아래에 생성된 새 파일 및 디렉토리에 권한을 적용하기 때문에 공동 작업 디렉토리에서 누락된 부분인 경우가 많습니다.

3. Sticky Bit

Sticky Bit(또는 텍스트 저장 속성)은 파일 삭제를 제어하기 위해 거의 독점적으로 공유 디렉토리에 사용됩니다.

디렉토리에 Sticky Bit가 설정되면 해당 디렉토리 내 파일의 소유자 또는 루트 사용자만 해당 파일을 삭제하거나 이름을 바꿀 수 있습니다. 디렉토리 자체가 '기타'에 대한 쓰기 액세스(o+w)를 허용하더라도 마찬가지입니다.

실용적인 사용 사례: /tmp와 같은 공용 공유 디렉토리 또는 사용자가 자신이 만든 파일만 관리할 수 있어야 하는 부서 업로드 폴더.

예: /tmp 디렉토리

/tmp 디렉토리는 종종 1777과 같은 권한을 갖습니다. 1은 Sticky Bit가 활성화되었음을 나타냅니다.

ls -ld /tmp
# 출력 예시: drwxrwxrwt 15 root root 4096 Mar 10 11:30 /tmp

끝에 있는 t는 Sticky Bit가 설정되었음을 확인합니다. 이것이 없으면 모든 사용자가 /tmp에서 다른 사용자가 만든 파일을 삭제할 수 있습니다.

Sticky Bit 설정: 표준 권한과 함께 8진수 값 1을 사용합니다(예: 777은 1777이 됨).

chmod 1777 /var/public_uploads

포괄적인 관리: 특수 권한 결합

특수 권한은 종종 결합됩니다. 네 번째 선행 숫자는 원하는 특수 비트의 합입니다(4+2+1 = 7).

원하는 권한 8진수 값
표준 rwxr-xr-x (755) 755
SUID + rwxr-xr-x 4755
SGID + rwxr-xr-x 2755
Sticky Bit + rwxrwxrwx 1777
SUID + SGID + Sticky Bit + rwx (거의 필요하지 않음) 7777

공유 폴더에 SGID와 Sticky Bit를 결합한 예:

모든 사용자가 'team' 그룹의 일부이고, 새 파일이 'team' 그룹을 상속받으며, 사용자가 서로의 파일을 삭제할 수 없는 안전한 공유 협업 디렉토리를 만들려면:

  1. 그룹 소유권 설정: chgrp team /data/projectX
  2. SGID (2) + 표준 rwx (7) + Sticky Bit (1) 적용 $\rightarrow 2+1 = 3$ (특수 비트의 경우).
    • 명시적 합계 사용: SGID (2) + Sticky Bit (1) = 3. 표준 권한 775.
    • 전체 명령: chmod 3775 /data/projectX

ls -ld로 볼 때 그룹 실행 위치에 s가, 기타 실행 위치에 t가 모두 표시되어야 합니다.

drwxrwsr-t 2 root team 4096 Mar 10 11:30 /data/projectX

실행 비트가 없으면 대문자 S 또는 T가 표시됩니다. 이는 일반적으로 디렉토리에서 경고 신호입니다. 실행 권한은 사용자가 디렉토리를 탐색할 수 있는지 여부를 제어하기 때문입니다.

실제 사고를 유발하는 일반적인 실수

가장 위험한 실수는 적절한 권한 부여를 설계하지 않기 위해 SUID를 사용하는 것입니다. 유지 관리 스크립트가 하나의 애플리케이션 소유 파일을 교체해야 하는 경우 모든 사용자에게 스크립트 전체를 효과적으로 루트로 만들지 마세요. 애플리케이션에 제어된 서비스 명령을 제공하고, 좁은 sudoers 규칙을 사용하거나, 서비스 계정이 루트 없이 작업을 수행할 수 있도록 소유권을 변경하세요.

또 다른 일반적인 실수는 Sticky Bit 없이 공유 디렉토리를 세계 쓰기 가능하게 만드는 것입니다.

chmod 777 /srv/uploads

테스트 중에는 편리해 보입니다. 프로덕션에서는 디렉토리에 액세스할 수 있는 모든 로컬 사용자가 다른 사용자의 파일 이름을 바꾸거나 삭제할 수 있습니다. 디렉토리가 실제로 많은 관련 없는 사용자가 쓸 수 있어야 하는 경우 1777이 일반적으로 더 안전한 기준선입니다.

chmod 1777 /srv/uploads

팀 소유 디렉토리의 경우 세계 쓰기보다는 2775와 실제 그룹이 더 나은 경우가 많습니다. 팀 구성원이 서로의 파일을 삭제하지 못하도록 하려는 경우에만 Sticky Bit를 추가하세요. 일부 팀은 공유 정리 권한을 원하고 다른 팀은 원하지 않습니다. 권한 모델은 해당 워크플로와 일치해야 합니다.

백업 및 배포는 특수 권한을 손상시킬 수도 있습니다. 일부 아카이브 및 복사 도구는 기본적으로 모드를 보존합니다. 다른 도구는 올바른 플래그를 전달하지 않으면 그렇지 않습니다. 시스템을 복원하거나 바이너리 패키지를 배포한 후에는 특수 비트를 명시적으로 확인하세요.

stat -c '%A %a %U %G %n' /usr/bin/passwd /tmp /srv/shared_project

/tmp가 1777 대신 0777로 돌아오면 미적인 차이가 아닙니다. 사용자가 서로의 파일을 방해할 수 있습니다. 필수 SUID 비트가 시스템 유틸리티에서 누락되면 일반 사용자가 예상된 동작을 갑자기 상실할 수 있습니다. 예상치 못한 SUID 비트가 /home, /tmp 또는 애플리케이션 업로드 경로의 파일에 나타나면 반대가 입증될 때까지 의심스러운 것으로 처리하세요.

출력에 압도되지 않고 감사하기

전체 파일 시스템 검색은 특히 빌드 머신과 개발자 워크스테이션에서 시끄러울 수 있습니다. 가장 중요한 영역부터 시작하세요.

sudo find /usr /bin /sbin /opt -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null
sudo find /tmp /var/tmp /dev/shm -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null

첫 번째 명령은 일반 실행 파일 위치를 검토합니다. 두 번째 명령은 권한 있는 실행 파일이 훨씬 더 우려되는 쓰기 가능한 임시 영역을 확인합니다. 깨끗한 서버에서는 세계 쓰기 가능 경로의 사용자 정의 SUID 파일이 드물어야 합니다. 찾은 경우 소유권, 패키지 소스, 수정 시간 및 구성 관리에 나타나는지 확인하세요.

디렉토리의 경우 Sticky Bit 없이 세계 쓰기 가능한 경로를 찾으세요.

sudo find / -xdev -type d -perm -0002 ! -perm -1000 -ls 2>/dev/null

이것이 모든 결과가 위반임을 의미하는 것은 아닙니다. 모든 결과에는 이유가 있어야 함을 의미합니다. 일부 애플리케이션 디렉토리는 의도적으로 서비스 그룹이 쓸 수 있지만 Sticky Bit 보호 없이 공개 쓰기 가능한 디렉토리는 일반적인 함정입니다.

특수 권한 보안을 위한 모범 사례

SUID 및 SGID가 부여하는 상승된 권한으로 인해 매우 주의해서 관리해야 합니다.

  1. SUID 범위 제한: passwd, ping과 같은 표준 작업에 필요한 컴파일된 바이너리 실행 파일에만 SUID를 설정하세요. 입력의 유효성을 검사하는 보안 래퍼 실행 파일로 래핑되지 않는 한 해석된 스크립트(Shell, Python, Perl)에는 SUID를 절대 적용하지 마세요.
  2. 정기적인 감사: find 명령을 사용하여 파일 시스템에서 비정상적인 SUID/SGID 파일을 정기적으로 검색하세요.
    # SUID가 설정된 모든 파일 찾기
find / -perm /4000 2>/dev/null
# SGID가 설정된 모든 파일 찾기
find / -perm /2000 2>/dev/null
  3. 그룹 일관성을 위해 SGID 사용: 공유 데이터 구조에서 파일 그룹 소유권을 수동으로 관리하는 것보다 SGID를 선호하세요. 그룹 상속을 자동화합니다.
  4. 공개 쓰기 가능 영역에 Sticky Bit 사용: Sticky Bit는 비소유자에 의한 삭제가 제한되어야 하는 일반 사용자 사용을 위한 모든 디렉토리(예: /tmp, /var/tmp)에 필수적입니다.
  5. 협업이 중요할 때 SGID를 ACL과 함께 사용: SGID는 그룹 소유권을 처리하고 기본 ACL은 새 파일이 받는 권한을 처리합니다.
  6. 사용자 정의 예외 추적: 조직에서 사용자 정의 SUID 또는 SGID 바이너리를 승인하는 경우 목적, 소유자, 예상 경로 및 배포 소스를 기록하세요. 미스터리 권한은 나중에 문제가 되는 부분입니다.

특수 권한은 정확하기 때문에 유용합니다. 그 상태를 유지하세요. 좁은 권한 전환에는 SUID를, 공유 소유권에는 SGID를, 삭제 권한에 보호 장치가 필요한 공유 디렉토리에는 Sticky Bit를 사용하세요.