☰

보조 그룹에 Gid()를 설정하는 데 priv가 필요한 이유

tag-icon • tag-icon security group system-calls
보조 그룹에 Gid()를 설정하는 데 priv가 필요한 이유

set*gid()드문 경우를 제외하고 다양한 시스템 호출을 수행하려면 그룹 권한을 변경해야 합니다. 기본 그룹을 프로세스의 보조 그룹 중 하나로 변경하는 것은 그 중 하나가 아닌 것으로 보입니다. 즉, 기본 그룹을 전환하려면 newgrp/ 명령에 높은 권한이 필요합니다.sg

setgid()setegid()/// 권한 없이 보조 그룹으로의 전환을 허용하지 않을 이유가 있나요 ? 그렇다면 왜 그렇습니까?setregid()setfsgid()

답변1

물론 여기서 근본적인 어려움은 파일 시스템 권한 확인이 (유효 UID와) 유효 GID와 보충 GID의 조합을 기반으로 한다는 것입니다. 따라서 파일 권한 확인 관점에서 볼 때 유효 GID는 보충 GID와 동일하며 이는 OP의 질문으로 이어집니다. (참고: Linux에 대해 이야기하는 경우 파일 시스템 권한 확인은 실제로 유효한 UID 및 GID 대신 파일 시스템 UID/GID를 사용하지만 전자 ID는 거의 항상 후자 ID와 동일한 값을 갖습니다.)

따라서 실제/유효/세이브 세트 GID가 보충 GID와 동일하지 않은 상황이 발생해야 합니다. (일반 set*gid() 권한 규칙에서는 권한이 없는 프로세스가 이러한 GID 중 하나를 다른 두 GID 중 하나와 동일한 값으로 변경할 수 있다고 명시하기 때문에 실제/유효/세이브 세트 GID를 함께 그룹화합니다.)

실제로 그러한 예가 몇 가지 있습니다. 프로세스에 따라 access(2)진짜사용자 ID 및 그룹 ID. 권한이 없는 사용자가 실제 그룹 ID를 보충 GID 중 하나(유효하거나 저장된 세트 GID가 아님)와 동일하게 변경할 수 있는 경우 access(2)의 동작을 조작할 수 있습니다.

다른 비슷한 상황이 있습니다. 리눅스 보기mkdir(2) 매뉴얼 페이지,예를 들어. set-GID 모드 비트가 상위 디렉토리에 설정되어 있는지 여부에 따라 해당 디렉토리에 생성된 새 파일은 생성 프로세스의 유효 GID에서 그룹 소유권을 가져옵니다. 마찬가지로, 권한이 없는 프로세스가 유효 GID를 보조 GID 중 하나로 변경할 수 있는 경우 예상치 못한 방식으로 새 파일의 그룹 소유권을 조작할 수 있습니다. 유사한 설명이 mknod(2)에도 적용되며 System V IPC는 semget(2), shmget(2) 및 msgget(2)을 호출합니다.

실제/유효/세이브 세트 GID가 보충 GID와 동일하지 않은 일부 Linux 관련 사례도 있습니다. 바라보다process_vm_readv(2)예를 들어 prlimit(2)입니다.

답변2

그 이유는 주로 역사적이라고 생각합니다. 보충 그룹은 4.2BSD(1983년경)까지 추가되지 않았습니다. 이전에는 실제적이고 유효한 uid와 gid만 있었습니다.

setuid/setgid의 동작은 완전히 대칭이므로 비대칭일 이유가 없습니다. 사용자 전환을 사용 su하고 sg/ newgrpall setuid 실행 파일을 사용하여 그룹화할 수 있습니다. 사용자 그룹 멤버십에 대한 정보는 프로세스 속성이 아닌 사용자 데이터베이스에만 있습니다.

보충 gid가 추가될 때 setuid/setgid 인터페이스는 변경되지 않았습니다.

기술적으로 이제 파일 시스템에 대한 쓰기 액세스 권한이 있는 경우(exec 및 setuid/setgid가 비활성화되지 않은 경우) 여전히 유효 또는 실제 사용자 ID를 보조 gid로 설정할 수 있습니다( sg/ newgrpbtw에 의존하지 않음). 사용자 데이터베이스에 정의된 그룹이며 프로세스의 보충 gid 목록과 반드시 ​​동일할 필요는 없습니다).

cp /usr/bin/env .
chgrp any-sup-group env
chmod g+s ./env

실행 후에 env는 EPID가 any-sup-group.

관련 정보