Linux 권한 제어의 기본 원칙

이 글에서는 주로 Linux 시스템의 권한 제어에 대한 기본 원칙을 소개합니다.

보안 모델

Linux 시스템에서 우리의 모든 작업은 본질적으로 파일에 액세스하는 프로세스입니다. 파일에 접근하려면 먼저 해당 접근 권한을 얻어야 하며, 접근 권한은 Linux 시스템의 보안 모델을 통해 획득됩니다.

Linux 시스템의 보안 모델의 경우 다음 두 가지 사항을 알아야 합니다.

1. Linux 시스템의 원래 보안 모델은 DAC라고 하며, 전체 이름은 Discretionary Access Control(임의 액세스 제어)입니다.
2. 나중에 MAC라는 새로운 보안 모델이 추가되고 설계되었습니다. MAC의 전체 이름은 필수 액세스 제어(Mandatory Access Control)로 해석됩니다.

MAC와 DAC는 상호 배타적이지 않습니다. DAC는 가장 기본적인 보안 모델이며 일반적으로 Linux에 있어야 하는 가장 일반적으로 사용되는 액세스 제어 메커니즘입니다. MAC는 DAC를 기반으로 구축된 향상된 보안 메커니즘이며 옵션 모듈에 속합니다. 액세스하기 전에 Linux 시스템은 일반적으로 DAC 검사를 먼저 수행합니다. 실패하면 작업이 직접 실패합니다. DAC 검사를 통과하고 시스템이 MAC 모듈을 지원하는 경우 MAC 권한 검사를 수행합니다.

둘을 구별하기 위해 MAC SELinux를 지원하는 Linux 시스템이라고 부르는데, 이는 Linux용 보안이 강화된 시스템이라는 의미입니다.

여기에서는 Linux 시스템의 DAC 보안 모델에 대해 이야기하겠습니다.

DAC 보안 모델

DAC의 핵심 내용은 다음과 같습니다. Linux에서 프로세스는 이론적으로 이를 실행하는 사용자와 동일한 권한을 갖습니다. 관련된 모든 것은 이 핵심을 중심으로 이루어집니다.

사용자 및 그룹 ID 정보 제어

사용자, 그룹, 비밀번호 정보

사용자 및 그룹 정보는 /etc/passwd 및 /etc/group을 통해 저장하고, 비밀번호 및 변경 정보는 /etc/shadow를 통해 한 줄에 하나씩 저장합니다.

사용자와 그룹은 각각 UID와 GID로 표시됩니다. 사용자는 동시에 여러 그룹에 속할 수 있습니다. 기본적으로 각 사용자는 UID와 동일한 값과 이름을 가진 GID에 속해야 합니다.

/etc/passwd의 경우 각 레코드 필드는 사용자 이름입니다. 비밀번호(암호화되어 /etc/shadow에 저장됨): UID: GID(기본 UID): 설명 설명: 홈 디렉터리: 로그인 셸(첫 번째 실행 프로그램)

/etc/group의 경우 각 레코드의 필드는 다음과 같습니다. 그룹 이름: 비밀번호(일반적으로 그룹 비밀번호는 없습니다): GID: 그룹 구성원 사용자 목록(쉼표로 구분된 사용자 UID 목록)

/etc/shadow의 경우 각 레코드의 필드는 다음과 같습니다. 로그인 이름: 암호화된 비밀번호: 마지막 수정 시간: 최소 시간 간격: 최대 시간 간격: 경고 시간: 비활성 시간:

예

다음은 사용자 및 그룹 정보의 예시입니다. /etc/shadow의 비밀번호 정보는 암호화되어 저장되며, 예시는 제공되지 않습니다.

파일 권한 제어 정보

파일 형식

Linux의 파일 형식은 다음과 같습니다.

• 텍스트 파일과 바이너리 파일을 포함한 일반 파일을 터치로 생성할 수 있습니다.
네트워크 통신에 사용되는 소켓 파일은 일반적으로 실행 중에 애플리케이션에 의해 간접적으로 생성됩니다.
• 파이프 파일은 명명되지 않은 파이프가 아닌 명명된 파이프이며 mkfifo로 생성할 수 있습니다.
• 캐릭터 파일과 블록 파일은 모두 장치 파일이며 mknod로 생성할 수 있습니다.
• 링크 파일은 하드링크 파일이 아닌 소프트링크 파일로, ln으로 생성이 가능합니다.

액세스 제어 그룹

제어를 위해 세 그룹으로 나뉩니다:

사용자는 파일 소유자에 대해 설정된 권한을 포함합니다

• group에는 파일 그룹에 설정된 권한이 포함되어 있습니다
• 다른 사람에게는 다른 사람을 위해 설정된 권한이 포함됩니다

구성 가능한 권한

다음을 포함하여 일반적인(전부는 아님) 권한 값이 아래에 제공됩니다.

r은 읽기 권한을 의미합니다.

• w는 쓰기 권한을 의미합니다.
• x는 일반적으로 실행 파일/디렉터리용으로 실행/검색 권한이 있음을 나타냅니다.
• s는 일반적으로 실행 파일/디렉터리용으로, 파일 소유자에게 권한을 부여하는 권한이 있음을 나타냅니다. 사용자 및 그룹 그룹만 이 권한을 설정할 수 있습니다.
• t 일반적으로 디렉터리의 경우 고정 비트를 설정한 후 권한이 있는 사용자는 자신의 파일만 쓰고 삭제할 수 있습니다. 그렇지 않으면 디렉터리의 모든 파일을 쓰고 삭제할 수 있습니다. 또한 기존 시스템에서는 실행 파일이 실행된 후 속도 향상을 위해 텍스트가 스왑 영역에 복사된다는 의미도 있습니다.

예

ls -l을 통해 파일 형식과 권한을 확인할 수 있고, chmod를 통해 권한을 수정할 수 있습니다.

예를 들어

출력에서 첫 번째 문자는 파일 형식을 나타내며, 그 중 일반 파일(-), 디렉터리 파일(d), 소켓 파일(s), 파이프 파일(p), 문자 파일(c), 블록 파일(b) ), 링크 파일(l); 두 번째 문자부터 시작하는 -rwxr-xr-x 부분은 파일의 권한 비트를 나타내며 총 9비트입니다.

/usr/bin/qemu-i386 파일의 경우 이 권한 제어의 의미는 다음과 같습니다.

1. 비트 2~4의 rwx는 r, w 또는 x 권한을 가진 소유자가 파일에 액세스할 수 있음을 나타냅니다.
2. 5~7 위치의 r-x는 r 또는 x 권한이 있는 파일과 동일한 그룹의 사용자가 파일에 액세스할 수 있음을 나타냅니다.
3. 비트 8~10의 r-x는 r 또는 x 권한을 가진 알 수 없는 다른 사용자가 파일에 액세스할 수 있음을 의미합니다.

test/, test2/, test3/에 대한 권한 설정:

1. r,w,x 권한은 각 권한 제어 그룹에 대해 하나의 8진수로 표시됩니다. 예를 들어 755는 rwxr-xr-x를 의미합니다.
2. s,t 권한은 x 위치 대신 표시됩니다. s,t 권한을 설정하려면 r,w,x 권한을 제어하는 ​​데 사용되는 해당 8진수 권한 제어 그룹이 소유자 그룹에 사용되기 전에 숫자를 추가해야 합니다. 컨트롤, t는 다른 컨트롤에 사용됩니다.
3. 소유자를 설정하려면 4를 추가하고, 그룹을 설정하려면 2를 추가하고, 다른 사람의 권한을 설정하려면 1을 추가합니다. 예를 들어 test/에 대해 t를 설정할 때 rwxrwxr-t를 의미하는 1775를 사용합니다.

처리 권한 제어 정보

처리 권한

프로세스의 경우 다음 속성은 파일 액세스 권한과 관련됩니다.

• 유효 사용자 ID: 프로세스 접근 파일 권한과 관련된 UID(약칭: euid)
• 유효 그룹 ID: 프로세스 접근 파일 권한과 관련된 GID(약칭: egid)
• real user id : 시스템에 로그인 시 프로세스를 생성한 사용자의 UID(약칭 ruid)입니다.
• 실 그룹 ID: 시스템에 로그인할 때 프로세스를 생성한 사용자의 GID(약어로 rgid)입니다.
• 저장된 세트 사용자 ID: euid에서 복사되었습니다.
• 저장된 세트 그룹 ID: egid에서 복사되었습니다.

예

ps 및 top을 사용하여 euid 및 ruid가 포함된 프로세스를 선택하고 볼 수 있습니다. 또는 top을 사용하여 프로세스의 euid 및 ruid를 확인하세요

위에서 본 예:

먼저 top에 들어가면 다음과 같은 결과가 나옵니다

여기서 -d 옵션은 작업 편의성을 위해 top의 새로 고침 빈도를 확장하는 데 사용됩니다. 여기서 볼 수 있듯이 USER 필드만 해당 프로세스의 유효 사용자 ID를 나타냅니다.

사용자 ID 읽기 표시 옵션 열기:

a. top 명령이 실행되는 동안 f를 입력하면 다음과 유사한 줄이 표시됩니다.

b c를 입력하면 실제 사용자 이름 표시 스위치가 켜집니다.

c. 마지막으로 Return 키를 눌러 맨 위로 돌아가면 실제 사용자 ID 옵션이 표시됩니다. 이때 'o'를 입력하면 열 순서를 조정할 수 있습니다. 마지막으로 다음과 같이 `유효 사용자 ID`와 `실제 사용자 ID`가 포함된 출력을 볼 수 있습니다.

프로세스 접근 파일에 대한 권한 제어 전략

규칙

프로세스 액세스 파일에 대한 대략적인 권한 제어 전략

파일에 접근하는 프로세스에서 가장 중요한 것은 euid이므로 권한 속성은 모두 euid를 중심으로 이루어집니다.

• 프로세스의 euid는 일반적으로 ruid 값으로 기본 설정됩니다
• 실행 파일의 실행 권한 비트가 s인 경우 프로세스가 실행 파일에 대해 exec를 호출한 후 euid가 실행 파일의 사용자 ID로 설정됩니다
• 프로세스의 저장된 세트 사용자 ID는 euid에서 복사됩니다.
• 프로세스의 euid가 파일의 사용자 ID와 일치하면 프로세스는 파일의 사용자 권한 비트에 의해 설정된 권한만 갖습니다
• 그룹 권한 egid에 대한 제어 규칙은 비슷합니다.

exec 파일 실행을 통해 권한 속성 수정

exec를 통해 실행 파일을 호출하는 경우:

• 프로세스 ruid 값은 항상 변경되지 않습니다.
• 저장된 세트-사용자 ID는 항상 euid에서 옵니다 ;
• euid 값은 파일의 set-user-ID 비트 설정 여부에 따라 달라집니다.

다음과 같습니다:

setuid(uid) 시스템 호출을 통해 권한 속성 수정

setuid(uid)를 통해 권한 속성을 수정하는 경우:

• 슈퍼유저는 ruid, euid, 저장된 설정된 사용자 ID를 원활하게 수정할 수 있습니다.
• 권한이 없는 사용자는 uid와 ruid가 동일한 경우에만 euid를 수정할 수 있으며, 그렇지 않으면 수정할 수 없습니다.

예

몇 가지 특별한 예:

set-user-id

앞서 언급했듯이 이 출력의 의미는 /usr/bin/sudo 파일에 대해

• 비트 1~3의 rws는 r, w 또는 s 권한을 가진 소유자가 파일에 액세스할 수 있음을 의미합니다
• 비트 4~6의 r-x는 r 또는 x 권한이 있는 파일과 동일한 그룹의 사용자가 파일에 액세스할 수 있음을 나타냅니다.
• 비트 7~9의 r-x는 r 또는 x 권한을 가진 알 수 없는 다른 사용자가 파일에 액세스할 수 있음을 나타냅니다.

이 설정 이후에는 소유자가 읽기, 쓰기, 실행 권한을 갖게 되며 이는 다르지 않습니다. 그러나 루트 그룹에 속하지 않는 일반 사용자 프로세스의 경우에는 상당히 다릅니다.

일반 사용자 프로세스는 sudo 명령을 실행할 때 다른 것에서는 x를 통해 실행 권한을 얻은 후 user의 s를 사용하여 sudo 실행 파일의 소유자(루트) 권한, 즉 슈퍼 권한을 일시적으로 갖습니다. .

이것이 일반 사용자가 sudo 명령을 통해 관리자 권한으로 많은 명령을 실행할 수 있는 이유이기도 합니다.

스틱비트 설정

이 설정 후에는 모든 사람이 /tmp 디렉터리에 대한 읽기, 쓰기 및 실행 권한을 갖게 되며 이는 다르지 않습니다. 그러나 끈적한 비트 t는 다른 부분에 설정되어 있으며 그 기능은 상당히 다릅니다.

디렉토리에 고정 비트가 설정되어 있지 않으면 해당 파일의 소유자가 아니고 읽기 또는 쓰기 권한이 없더라도 해당 디렉터리에 대한 쓰기 권한이 있는 사람은 누구나 해당 파일과 하위 디렉터리를 삭제할 수 있습니다. 고정 비트가 설정되면 사용자는 자신에게 속한 파일 및 하위 디렉터리만 쓰거나 삭제할 수 있습니다.

이것이 누구나 /tmp 디렉토리에 파일과 디렉터리를 쓸 수 있지만 자신이 소유한 파일이나 디렉터리만 쓰고 삭제할 수 있는 이유입니다.

set-user-id 및 저장된 set-user-id의 사용을 설명하기 위해 man 프로그램의 애플리케이션 부분을 인용하세요

man 프로그램은 온라인 도움말 매뉴얼을 표시하는 데 사용할 수 있습니다. man 프로그램을 설치하여 특정 사용자 또는 그룹에 대해 set-user-ID 또는 set-group-ID를 지정할 수 있습니다.

man 프로그램은 일반적으로 구성 파일(보통 /etc/man.config 또는 /etc/manpath.config) 또는 명령줄 옵션으로 구성되는 특정 위치의 파일을 읽거나 덮어쓸 수 있습니다.

man 프로그램은 표시된 매뉴얼 페이지가 포함된 파일을 처리하기 위해 다른 명령을 실행할 수 있습니다.

처리 오류를 방지하기 위해 man은 두 가지 권한, 즉 man 명령을 실행하는 사용자의 권한과 man 프로그램 소유자의 권한 사이를 전환합니다.

파악해야 할 메인 스레드: man만 실행될 때 프로세스 권한은 man 사용자의 권한입니다. man을 통해 하위 프로세스가 실행될 때(예: !bash를 통한 쉘 명령) 사용자는 현재 사용자이고 실행 후 다시 전환됩니다.

과정은 다음과 같습니다.

1. man 프로그램 파일이 사용자 man의 소유이고 해당 파일의 set-user-ID 비트가 설정되어 있다고 가정하면 다음과 같은 상황이 발생합니다. – 실제 사용자 ID = 우리 사용자 UID
   – 유효 사용자 ID = man 사용자 UID
   – 저장된 set-user-ID = man 사용자 UID
   
man 프로그램은 필수 구성 파일과 매뉴얼 페이지에 액세스합니다. 이 파일의 소유자는 man 사용자이지만 유효 사용자 ID는 man이므로 해당 파일에 대한 접근이 허용됩니다.
man이 우리를 위해 어떤 명령을 실행하면 setuid(getuid()))를 호출합니다(getuid()는 실제 사용자 ID를 반환합니다).
3. 우리는 슈퍼유저 프로세스가 아니기 때문에 이 변경은 유효한 사용자 ID만 변경할 수 있습니다.
   이제 man 프로세스가 실행되면 UID를 유효 사용자 ID로 사용합니다. 즉, 자체 권한이 있는 파일에만 액세스할 수 있습니다. 즉, 우리를 대신하여 모든 필터를 안전하게 실행할 수 있습니다.
   – 실제 사용자 ID = 우리 사용자 UID (변경되지 않음)
   – 유효 사용자 ID = 우리 사용자 UID
   – 저장된 set-user-ID = man의 사용자 UID (변경되지 않음)
   
필터가 완료되면 남자는 setuid(euid)를 호출합니다.
4. 여기서 euid는 man 사용자의 UID입니다. (이 ID는 man이 geteuid를 호출하여 저장됩니다.) setuid 매개변수가 저장된 set-user-ID와 동일하므로 이 호출은 괜찮습니다. (이것이 저장된 set-user-ID가 필요한 이유입니다.) 이때 다음과 같은 상황이 발생합니다.
   – 실제 사용자 ID = 우리 사용자 UID (변경되지 않음)
   – 유효 사용자 ID = 남자의 UID
   – 저장된 set-user-ID = man의 사용자 UID (변경되지 않음)
   
유효 사용자 ID는 man이므로 이제 man 프로그램은 자체 파일을 조작할 수 있습니다.
5. 이렇게 저장된 set-user-ID를 이용하면 프로세스 시작 및 종료 시 프로그램 파일의 set-user-ID를 통해 추가 권한을 사용할 수 있다. 그러나 이 기간 동안 우리는 자체 권한으로 운영되었습니다. 마지막에 저장된 set-user-ID로 다시 전환하지 못하면 실행하는 동안 추가 권한을 유지할 수 있습니다.
   

사람이 쉘을 시작하면 어떤 일이 일어날지 살펴보겠습니다.

• 여기서 쉘은 포크와 exec를 사용하여 사람이 시작합니다.
• 이때 실제 사용자 ID와 유효 사용자 ID는 모두 일반 사용자 UID(3단계 참조)이므로 쉘에는 다른 추가 권한이 없습니다.
• 실행된 쉘은 저장된 man의 set-user-ID(man)에 접근할 수 없습니다. 왜냐하면 쉘의 저장된 set-user-ID가 exec에 의해 유효 사용자 ID에서 복사되었기 때문입니다.
• exec를 실행하는 하위 프로세스(셸)에서는 모든 사용자 ID가 일반 사용자 ID입니다.

실제로 사람이 setuid 기능을 사용하는 방법을 설명하는 방식은 특별히 정확하지 않습니다. 왜냐하면 프로그램이 사용자 ID를 루트로 설정할 수 있기 때문입니다. 이 때 setuid는 세 개의 uid를 모두 사용자가 설정한 ID로 변경하지만 우리에게는 필요한 사항만 필요합니다. 유효한 사용자 ID를 설정합니다.

위 내용은 Linux 권한 제어의 기본 원칙의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!