SUID 권한이 필요한 이유는 무엇입니까? [폐쇄]

SUID 권한이 필요한 이유는 무엇입니까? [폐쇄]

실행 가능한 바이너리에 SUID 권한이 필요한 이유에 대한 나의 우려를 이해하려면 이 긴 소개를 읽으십시오.

  • Linux의 프로세스는 EUID를 사용하여 학습합니다.유효한 사용자 ID그 자체.
  • 사용자의 권한은 프로세스가 다른 파일과 상호 작용하는 방식(예: 프로세스가 파일에 쓸 수 있는지 여부)을 결정하는 데 사용됩니다.

다음을 통해 비밀번호를 변경하는 시나리오를 고려해보세요./usr/bin/passwd

실생활에서의 리눅스

  • 비밀번호는 에 저장됩니다 . 파일은 권한( ) 이 있는 파일 /etc/shadow에 속합니다 .rootrw-------
  • 만약에 $passwd권한이 있습니다 rwx--x--x. 이는 루트만 논리를 변경할 수 있음을 의미합니다.비밀번호 프로그램.
  • userA프로그램을 실행할 때 passwd프로세스는 다음과 같이 시작됩니다.루이드=EU 사용자 ID= 사용자A

결과는 다음과 같습니다. 프로그램이 실행됩니다. ㅏpasswd 프로세스시작했지만 암호를 변경할 수 없습니다.EU 사용자 ID사용자A그리고사용자A을(를) 쓸 수 없습니다 /etc/shadow.

이 때SUID 권한이 필요합니다도착하다.수에이드설정 허용EU 사용자 ID프로세스를 생성하기 위해 바이너리가 실행되는 프로세스입니다. 이것EU 사용자 ID바이너리의 소유자로 설정됩니다.

  • 환경SUID 권한/usr/bin/passwd브랜드 소유자의 경우EU 사용자 ID어느passwd 프로세스임의의 사용자에 의해 시작됨EU 사용자 ID~의root
  • root에 쓸 수 있으므로 모든 /etc/shadow사용자가 다음을 사용하여 passwd실행할 수 있습니다.passwd 프로세스이건 바뀔 수 있어/etc/shadow

가지다SUID 권한왜냐하면 리눅스에서는EU 사용자 ID프로세스의 소유자는 실행 가능한 바이너리의 소유자로 하드 설정되지 않습니다(프로세스는 런타임에 생성됩니다).

나의 이상적인 리눅스

불필요한SUID 권한. 실행파일인 경우빈 A작성자(및 소유자)사용자A, 실행할 수 있는 모든 사용자빈 A만들 것입니다프로세스그리고EU 사용자 ID=사용자A.

비밀번호를 변경하는 시나리오에서 이 아이디어의 논리는 다음과 같습니다.

  • 뿌리/usr/bin/passwd유일한 소유자입니다뿌리논리를 변경할 수 있습니다.
  • 내부 논리를 /usr/bin/passwd통해 사용자는 자신의 비밀번호만 변경할 수 있고 다른 사람의 비밀번호는 변경할 수 없습니다.
  • 다른 사용자는 수정할 수 없습니다 /usr/bin/passwd.뿌리할 수 있는.
  • /etc/shadow쓸 수만 있다root

결과는 다음과 같습니다: 권한이 없는 사용자가 userA실행할 수 있습니다 $passwd.passwd 프로세스. 이 프로세스에는EU 사용자 ID=뿌리shadow그래서 파일 에 쓸 수 있습니다 .

이 이론을 통해 우리는 다음을 달성할 수 있습니다. 모든 사람이 별도의 조치 없이 자신의 비밀번호(및 자신의 비밀번호만)를 변경할 수 있습니다.SUID 권한.

답변1

두 예제 모두 setuid 작동 방식을 설명합니다. 그러나 "이상적인 Linux"에서는 모든 실행 파일이 실행 파일 소유자의 EUID로 시작하여 시스템의 모든 실행 파일을 setuid 실행 파일로 만듭니다.

이는 분명히 많은 문제를 야기합니다. 몇 가지 예를 들자면, 모든 루트 소유 실행 파일은 UID 확인을 수행하고 setuid()프로세스의 EUID를 루트가 아닌 사용자로 다시 설정하도록 호출해야 합니다(프로그램에 다른 권한이 없어야 하는 경우). 사용자는 프로세스가 잘못된 EUID로 실행되고 잘못된 관행으로 인해 심각한 결과를 초래할 수 있으므로 다른 사용자는 실행 파일을 제공할 수 없습니다(예: chmod 777이제 사용자가 소유한 모든 파일에 대한 액세스도 허용됨). 그리고 이것들이 더 있습니다.

setuid 바이너리가 없는 일반 권한에는 권한이 없는 사용자가 권한 있는 작업을 수행할 수 있도록 허용하는 다른 메커니즘이 필요합니다. Setuid 바이너리는 이러한 권한 상승을 허용하며 액세스 제어는 프로그램 논리에서 구현됩니다.

답변2

표시된 답변은 내 질문에 완벽하게 답변했습니다. 여기에 넣은 것은 설명하는 데 도움이 되는 추가 논리입니다.SUID 권한비밀번호 변경 시나리오에 대해.

  1. Linux에서는 실행 가능한 bin 파일을 다른 사용자가 실행해야 합니다.

    예를 들어 /usr/bin/nano텍스트 편집기의 bin이므로 동일한 실행 가능한 bin 파일을 다른 사용자가 실행할 수 있다는 것이 합리적입니다(왜 동일한 bin 파일을 각 사용자의 홈 파일 시스템에 복사하겠습니까?)

  2. 많은 사용자가 동일한 bin 파일을 사용할 수 있어야 하지만 해당 bin 파일에 의해 시작된 프로세스는 파일에 대해 서로 다른 권한을 가져야 합니다.

    예를 들어,사용자A그리고사용자 B둘 다 2개의 나노를 생성할 수 있어야 합니다.프로세스동일한 /usr/bin/nanobin 파일을 실행하면 됩니다. 하지만,사용자A나노의프로세스허용되어야 한다사용자A자신의 파일만 수정하고 그 반대의 경우도 마찬가지입니다.

이를 위해서는 메커니즘이 필요합니다.프로세스적용되어야 한다프로세스를 시작한 사용자와 동일한 권한을 가집니다.이 파일에는 파일이 있습니다(실행 가능한 bin 파일을 소유한 사용자의 권한 대신이는 프로세스를 생성하기 위해 수행됩니다).

Linux에서는 모든 프로세스에루이드. 이것루이드프로세스를 시작한 사용자의 ID입니다. 이 논리에 따르면,루이드프로세스의 사용자는 프로세스가 파일에 대해 사용하는 권한을 가진 사용자여야 합니다(예: 프로세스는 파일의 내용을 기반으로 파일에 대해 수행할 수 있는 작업을 결정합니다).루이드사용자는 파일에 대한 작업을 수행할 수 있습니다.

다만, 비밀번호를 변경하는 경우에는루이드다음과 같은 이유로만으로는 충분하지 않습니다.

  1. /etc/shadow해당 파일은 본인 외에는 누구도 수정할 수 없습니다.뿌리.
  2. 비밀번호를 변경하려는 사용자는 /usr/bin/passwd실행 가능한 bin 파일을 실행하여 비밀번호를 변경해야 합니다. 프로그램의 논리는 권한이 낮은 사용자가 자신의 비밀번호만 변경할 수 있도록 보장합니다.
  3. 루트만이 이 bin 파일에 쓸 수 있으므로 루트 이외의 사용자는 이 논리를 변경할 수 없습니다.
  4. 만약에사용자A/usr/bin/passwd실행 되면passwd 프로세스WHO루이드사용자A.
  5. 그러나 이후사용자A글쓰기는 허용되지 않습니다 /etc/shadow.passwd 프로세스그는 또한 처음에는 파일에 쓸 수 없었습니다.

이를 위해서는 메커니즘이 필요합니다.프로세스파일에 대한 다른 사용자의 권한을 기반으로 파일에 대한 한 사용자의 권한을 결정합니다(프로세스를 시작한 사용자의 권한이 아닌).

Linux에서는 파일에 대한 프로세스의 권한은 파일의 권한에서 가져옵니다.EU 사용자 ID그 파일에 있어요.

그리고EU 사용자 ID,뿌리지금 이용 가능SUID 권한허용하다사용자A시작하다passwd 프로세스가지다EU 사용자 ID설정뿌리. 이를 통해 효과적으로passwd 프로세스다음으로 시작됨사용자A/etc/shadow파일을 수정합니다 .

관련 정보