su를 강화하기 위해 dpkg-statoverride를 사용하는 방법은 무엇입니까?

목적은 일반 사용자가 su 명령을 실행하는 것을 방지하는 것입니다(su는 sudo가 명령을 실행하고 su가 새 사용자로 새 세션을 시작하고 사용자가 종료를 실행할 때까지 계속된다는 점을 제외하면 sudo와 유사합니다).

su의 기본 모드는 4755 또는 rwsr-xr-x이며, "s"는 명령이 set-UID임을 나타냅니다. 즉, 명령을 실행한 사용자가 아니라 항상 명령을 소유한 사용자로 실행된다는 의미입니다. 그것) . 이 경우 su는 루트가 소유하므로 항상 루트 권한으로 실행됩니다.)

su에는 이를 실행하는 사용자가 다른 사용자가 될 수 있는 권한이 있는지 확인하는 자체 보안 조치가 있지만(일반적으로 다른 사용자의 비밀번호를 요청하여) su에는 공격자가 어떻게든 허용하는 보안 구멍이 있을 수 있습니다. 승인 없이 다른 일을 하도록 설득합니다.

모드를 4750으로 변경하면 애초에 일반 사용자(root 및 sudo 그룹의 사용자 이외의 사용자)가 읽거나 실행하는 것을 방지하므로 공격자는 파일의 소유권을 변경하거나 모드를 변경해야 합니다. su의 이론적 취약점을 악용하기 전에 해당 파일에서 유효한 UID/GID를 변경하세요.

dpkg-statoverride 명령은 파일이 최신 버전으로 교체되더라도(즉, apt를 통해 업그레이드됨) 패키지 관리자에게 파일의 소유권/모드 값을 사용하도록 지시하기 때문에 이러한 상황에서 유용합니다. 즉, chown 및 chmod보다 지속성이 높습니다.

이 경우에 제가 권장하는 일반적인 전략은 다음과 같습니다. Linux/UNIX 시스템에서 su/sudo 또는 인증 구성 요소의 구성을 조정할 때마다 해당 서버에 대한 또 다른 ssh/putty 세션을 열고 루트로 로그인하여 실행합니다. 세션을 다른 창에서 열어 두십시오. 이렇게 하면 내가 뭔가를 엉망으로 만들고 나 자신을 잠그더라도 내가 깨뜨린 모든 것을 고칠 수 있는 로그인 세션이 있습니다.

사용자에 따라 이는 좋은 생각일 수도 있고 나쁜 생각일 수도 있습니다.

일반 사용자는 su해당 계정의 비밀번호를 알고 있는 경우 이 명령을 사용하여 수퍼유저 계정뿐만 아니라 다른 계정에 로그인할 수 있습니다.

예를 들어 두 명의 사용자가 프로젝트에서 공동 작업을 하고 있는데 그 중 한 명(사용자 A)이 로그인되어 있고 다른 사용자(사용자 B)만 액세스할 수 있는 파일을 읽어야 하는 경우에 유용합니다. 간단히 실행

su -c 'cat /home/userB/file' userB >file

로그인한 사용자의 홈 디렉터리에 파일을 복사하는 데 사용할 수 있지만 이는 suuserA가 명령을 실행할 수 있는 경우에만 가능합니다.

PostgreSQL 데이터베이스 서버에서 데이터베이스 관리자는 종종 postgres데이터베이스 서버가 실행되는 동안 수행할 수 없는 일부 유지 관리 작업을 수행하도록 사용자로 전환할 수 있습니다 su - postgres.

이 명령에도 동일한 주의 사항이 적용됩니다 sudo(이 명령과는 다르고 더 복잡합니다. su기본 구성일 뿐이므로 이 명령은 주로 그룹에 유용합니다 sudoers. 해당 그룹은 모든 명령을 실행할 수 있기 때문 root입니다. 그러나 다음과 같은 사용자 정의 규칙을 추가하는 경우 모든 사용자가 인수 없이 실행할 수 있도록 하려면 그룹 외부 사용자에 대한 실행 권한이 updatedb필요합니다 .sudoerssudo

게다가 susetuid뿐만 아니라

• sg(그룹 비밀번호가 설정되어 있으면 임시 그룹 가입이 허용됩니다.)
• passwd(비밀번호 변경 허용)
• chfn(사용자 정보 변경 허용)
• chsh(기본 쉘 변경 허용)

그리고 다른 몇몇. 이러한 도구는 명령과 많은 코드를 공유하므로 su모드를 개별적으로 변경해도 /bin/su많은 이점을 얻을 수 없으며 모든 도구의 모드를 변경하면 특히 passwd.

강화된 서버에서는 가능한 한 적은 수의 setuid/setgid 바이너리, 특히 특정 도구가 필요하지 않은 사용자 계정으로 실행할 수 있는 바이너리를 원합니다. 그 이유는 다음과 같습니다.

누군가의 사용을 감시하기 위해 이러한 도구를 정확하게 신뢰하지는 않습니다. 보안 연구원과 공격자는 사용자가 이러한 규정을 우회할 수 있도록 하는 프로그램이나 종속성에서 버그를 발견하고 적극적으로 찾는 경우가 많습니다. 잘못된 구성(su 동작은 PAM 라이브러리 구성에 따라 다름)으로 인해 동일한 문제가 발생할 수 있습니다. 따라서 특정(서비스 또는 사용자) 계정이 실행할 수 있는 모든 setuid/setgid 바이너리는 원치 않는 루트 액세스 권한을 얻을 수 있는 잠재적인 벡터입니다.

이러한 소프트웨어의 알려진 문제로 인해 패치/업데이트가 신속하게 제공되는 경우가 많지만, 강제로 신속하게 설치하면 중단이 발생할 수 있으며, 일부 취약성은 공급업체를 포함한 모든 사람에게 알려지지 않을 수도 있습니다.

따라서 긴급한 문제를 해결할 가능성을 최소화하려면 다음을 수행하는 것이 좋습니다.https://stackoverflow.com/questions/2189976/find-suid-and-gid-files-under-root, 그런 다음 이들 중 어떤 것을 제거할 수 있는지 조사합니다(주로 전용 서버를 실행 중이고 수행 중인 작업을 알고 있는 경우). 이러한 변경 사항을 영구적으로 유지하려면 패키지 관리 시스템에서 지원하는 dpkg-statoverride와 같은 방법을 사용하는 것이 가장 좋습니다.

레거시 NFS의 특정 설정에서 "su"에 대한 액세스를 제한하는 또 다른 이유가 있습니다. 본질적으로 정치적인 이유로 루트 계정에 대한 제한이 있을 수 있습니다(일부 사용자는 정치적인 이유로 계정에 액세스할 수도 있습니다. 그럼에도 불구하고 이는 좋지 않습니다). 연습) su는 NFS 마운트의 root_squash 플래그를 우회하기 때문에 간단합니다.