Linux 권한·ACL·특수 권한

01rwx를 8진수로 계산하고 요청한 동작에 대입하기

• 권한 비트의 8진수 값각 권한은 r=4, w=2, x=1의 비트다.
• 소유자·읽기0640은 소유자 6=읽기+쓰기, 그룹 4=읽기, 기타 0=허용 없음이다.

  • 선행 0은 8진수 표기를 분명하게 해 준다.
• 인터프리터와 직접 실행실행 비트가 없는 일반 문서를 쉘 인터프리터가 읽어 처리하는 것과 커널이 그 파일 자체를 실행하도록 요청하는 것은 다르므로 noexec나 x 비트를 모든 코드 실행의 완전한 금지로 해석하면 안 된다.
• 읽기디렉터리의 r은 이름 목록 읽기, x는 이름을 통해 내부 객체 탐색, w는 항목 생성·삭제·이름 변경에 관여한다.
• 탐색·권한파일 내용을 읽으려면 상위 디렉터리마다 탐색 권한과 대상 파일의 읽기 권한이 필요하다.

  • 반대로 파일의 쓰기 비트가 없어도 부모 디렉터리의 쓰기와 탐색이 허용되면 이름을 삭제할 수 있으며 sticky bit 같은 추가 조건이 이를 제한한다.

02소유자·그룹·기타는 순서대로 더하는 권한이 아니다

• 파일 소유자일반 모드 비트 판정에서 프로세스의 파일 접근용 사용자 ID가 파일 소유자와 일치하면 소유자 비트만 적용한다.
• 소유자·읽기소유자에게 읽기 권한이 없다고 그룹 읽기나 기타 읽기로 다시 내려가지 않는다.
• 소유자·그룹소유자가 아니면서 파일 그룹이 프로세스의 유효 그룹 또는 보조 그룹 중 하나와 일치하면 그룹 비트를 적용하고, 그 밖의 경우 기타 비트를 사용한다.
• capability·ACLLinux의 자격 정보와 capability, ACL, LSM 정책이 함께 작용하므로 이 설명은 일반 DAC 모드 판정의 골격이다.

  • 예를 들어 owner=learner, group=team, mode=0040인 파일은 learner가 team에 속해 있어도 소유자 분류에서 읽기가 거부된다.
  • 반면 소유자가 아닌 다른 team 사용자는 읽을 수 있다.
• UID·GID사용자의 이름이 아니라 UID와 GID 숫자로 비교한다는 점 때문에 같은 이름이 여러 시스템에 존재해도 숫자 매핑이 다르면 NFS 등의 결과가 달라질 수 있다.

id
stat -c "%A %a %u:%g %n" report.txt
namei -l /srv/team/report.txt
# owner/group/other 중 실제로 선택되는 분류를 먼저 결정한다.

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

03POSIX ACL의 named entry와 mask

• 이름별 ACL 항목ACL은 특정 사용자나 여러 그룹에 별도 권한을 주기 위해 모드 비트를 확장한다.
• 소유자user::는 소유자, user:learner:는 이름이 붙은 사용자 항목, group::와 group:team:은 그룹 항목, other::는 기타다.
• mask·named usermask::는 named user와 그룹 클래스가 실제로 얻을 수 있는 권한의 상한이다.
• 소유자·기타소유자 user::와 기타 other::에는 같은 방식으로 mask를 적용하지 않는다.
• 그룹 자리와 ACL mask확장 ACL이 있으면 ls -l의 그룹 자리만 보고 소유 그룹 권한이라고 단정할 수 없다.

  • 예를 들어 user:learner:rw-와 mask::r--가 함께 있으면 learner의 유효 권한은 읽기만이다.
• named usernamed user가 일치한 뒤 권한이 부족하다고 other로 재시도하지 않는다.
• 그룹그룹 판정에서는 일치하는 그룹 항목들의 허용 관계와 mask를 함께 고려한다.
• default ACL디렉터리 default ACL은 새 자식이 상속받을 ACL의 기본값이며 기존 자식에 소급 적용하지 않는다.

getfacl report.txt
# 설명용 발췌
# user::rw-
# user:learner:rw-       #effective:r--
# group::r--
# mask::r--
# other::---

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

07umask는 빼기가 아니라 생성 권한의 비트를 지운다

• 생성 비트 제거프로그램이 요청한 생성 모드에서 umask에 설정된 비트를 제거한다.
• 0027 계산 예일반 파일을 0666으로 요청하고 umask가 0027이면 0666 & ~0027 = 0640이 된다.

  • 디렉터리를 0777로 요청하면 0750이다.
• umask·실행umask가 실행 권한을 새로 추가하는 것은 아니므로 일반 파일의 기본 요청에 x가 없으면 실행 파일로 바뀌지 않는다.

  • 프로그램이 더 좁은 모드를 요청하면 그 제한 역시 유지된다.
• default ACLdefault ACL이 있는 디렉터리에서는 상속 ACL과 요청 모드의 조합을 보아야 하므로 항상 umask만으로 결과를 계산할 수는 없다.
• chmod와 생성 기본값기존 파일에 chmod를 적용하는 작업과 새 파일의 기본 생성 권한을 정하는 작업도 다르다.
• setgid·그룹공유 디렉터리에서는 부모 setgid가 그룹을 이어 주고 default ACL이 접근 정책을 이어 주도록 역할을 나누어 설계할 수 있다.

umask
# 새 실습 셸에서 umask 0027을 가정하면:
# 일반 파일 요청 0666 -> 결과 0640
# 디렉터리 요청 0777 -> 결과 0750

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

08setuid·setgid·sticky와 capability의 작용 범위

• 실행·setuid실행 파일의 setuid는 성공적인 실행 시 유효 UID를 파일 소유자의 UID로 바꿀 수 있다.

  • 실제 로그인 사용자를 나타내는 real UID와는 구별된다.
• setgid·실행setgid 실행 파일은 유효 GID에 같은 종류의 영향을 주고, setgid 디렉터리는 새 자식의 그룹 상속에 쓰인다.
• setgidsetgid 디렉터리라는 사실만으로 모든 자식에게 실행 비트나 쓰기 권한이 생기지는 않는다.

  • nosuid와 실행 파일 형식 등도 결과에 영향을 준다.
• sticky·쓰기sticky 디렉터리에서는 쓰기 권한이 있더라도 파일 소유자·디렉터리 소유자 또는 필요한 권한을 가진 프로세스만 해당 항목을 삭제·이름 변경할 수 있다.

  • /tmp의 1777이 대표 사례다.
• s·t와 S·T 표시ls의 s와 t는 해당 실행 비트도 켜졌음을, S와 T는 특수 비트만 켜지고 대응 x는 꺼졌음을 나타낸다.
• 관리 권능의 분리Linux capability는 관리자 권능을 CAP_NET_BIND_SERVICE 같은 단위로 나눈다.
• Capability 집합effective는 현재 검사에 쓰이는 집합, permitted는 활성화 가능한 범위, bounding은 실행을 통한 획득을 제한하는 상한이며 inheritable과 ambient는 실행 시 전달에 관여한다.
• 프로그램 신뢰와 권능파일 capability는 프로그램 자체가 안전하다는 보증이 아니다.

getcap /usr/bin/ping
getpcaps 1234
# 설치 환경에 따라 capability가 없거나 출력이 다를 수 있다.

교육용 예시. 표시된 결과는 설명을 위한 예시이며 실제 실행 기록이 아니다.

수업 원본 자료

부모 디렉터리의 그룹을 새 디렉터리가 상속하는 실습

원본 크기로 보기 ↗

이 자료에서 읽어낼 것

1. chgrp tester 뒤 test2의 그룹 열이 root에서 tester로 바뀐다.
2. chmod 2755 뒤 그룹 실행 위치가 s로 표시된다.
3. root가 하위 test3을 만들었지만 그룹은 tester이고 새 디렉터리에도 setgid가 이어진다. 이 설정 자체가 모든 사용자에게 쓰기 권한을 주지는 않는다.

09접근 거부를 확인하는 순서

• 실행·그룹실행 계정과 그룹, 상위 경로의 통과 권한, 대상의 모드와 ACL을 차례로 확인한다.
• SELinux·읽기여기에 SELinux, 읽기 전용 마운트, 서비스 자체 정책도 영향을 준다.
• 과도한 쓰기 허용의 한계권한 오류를 모두 동일한 문제로 취급해 전체 쓰기 권한을 주는 방식은 원인 해결이 아니다.

id
ls -ld .
umask

현재 사용자·디렉터리 권한·생성 마스크를 조회한다.

10요청한 권한을 실제 계정에 대입하기

• 동작별 접근 요청읽기와 쓰기는 별도의 요청으로 생각한다.
• 프로세스 자격 정보일반 계정의 접근을 판정할 때 먼저 프로세스의 사용자·그룹 자격 정보와 파일 소유권을 대조한다.
• 파일 소유자파일 소유자에 해당하면 소유자 항목으로 결정하며, 거기서 권한이 부족하다고 기타 사용자 항목으로 넘어가 더 넓은 권한을 얻지는 않는다.
• ACL확장 ACL이 있다면 명명 사용자 항목과 그룹 항목 및 mask가 판정에 포함된다.
• DAC와 추가 정책Linux의 파일 접근에는 fsuid 같은 세부 자격 정보도 있지만 여기서는 일반 로그인 프로세스를 가정한다.

  • 예를 들어 파일 소유자가 아닌 계정 reader에 user:reader:rw-가 있고 mask::r--라면 표시상 rw-여도 유효 권한은 r--다.
  • 쓰기 요청은 이 지점에서 거부된다.
• ACL 적용 순서reader가 어떤 그룹에도 속해 있다는 이유로 더 뒤의 그룹 항목을 대신 선택해 허용하지 않는다.
• 읽기·ACL읽기는 이 ACL 조건을 통과할 수 있지만 SELinux가 해당 프로세스 도메인의 파일 읽기를 허용하는지는 별도로 확인해야 한다.

  • 상위 디렉터리의 탐색 권한도 이미 충족됐다는 조건이다.

1. 읽기 요청파일 소유자가 아닌 reader가 r 권한을 요청한다. 상위 디렉터리 탐색 권한은 충족되었고, reader에 해당하는 named user ACL이 있다고 가정한다.
2. 소유자 범주 제외요청자의 UID가 파일 소유자와 다르므로 owner 항목으로 판정하지 않는다. named user ACL에서 reader와 일치하는 항목을 찾는다.
3. ACL과 mask 결합reader 항목이 rw-이고 mask가 r--이면 두 비트 집합의 교집합인 r--만 유효하다. 이 사례의 읽기는 허용되지만 쓰기는 거부된다.
4. 그룹·기타 재시도 생략named user 항목이 선택됐으므로 그룹·기타의 더 넓은 권한을 합치거나 거부 뒤 다른 범주로 재시도하지 않는다.
5. 추가 정책 적용파일 접근이 완료되려면 DAC 판정뿐 아니라 적용되는 SELinux 등 다른 접근 정책도 허용해야 한다.

11읽기·삭제·실행을 구분하는 관찰

• 삭제파일 내용은 읽을 수 있는데 삭제할 수 없는 경우에는 부모 디렉터리의 쓰기·탐색 권한과 sticky bit를 조사한다.

  • 반대로 파일 자체가 읽기 전용이어도 부모 디렉터리에서 항목을 제거할 권한이 있으면 삭제할 수 있는 조건이 생긴다.
• 실행 실패의 조건실행 실패에서는 x 비트뿐 아니라 상위 경로, 인터프리터의 존재, noexec 마운트 같은 다른 조건도 구분해야 한다.
• 모드 변경의 한계권한 숫자 하나를 바꾸는 것으로 모든 실행 오류를 해결할 수 없다.
• maskgetfacl 결과의 effective 표시와 mask를 읽고, 실제 서비스 프로세스가 사용하는 계정과 그룹을 대조한다.
• 실제 프로세스 자격터미널에서 확인한 id는 그 터미널 세션의 자격 정보이므로 다른 서비스의 자격 정보와 같다고 가정하지 않는다.
• 권한·umask생성 권한은 요청 모드와 umask에 영향을 받으며, 기본 ACL이 설정된 디렉터리에서는 상속 규칙도 살펴야 한다.
• 특권의 예외특권과 capabilities에 따른 예외는 일반 계정의 기본 판정 사례와 분리해 해석한다.