최신 시스템에서 여전히 suid 비트가 필요한 작업은 무엇입니까? [폐쇄]

Ping이 setuid 루트에서 setcap로 이동되었습니다 net_admin. 프로그램이 예상치 못한 동작을 보이는 경우 setuid 루트에서 setcap로 마이그레이션하면 위험을 줄일 수 있습니다. 그러나 기본 메커니즘은 동일합니다. 즉, 프로세스는 인스턴스화된 실행 파일의 메타데이터를 기반으로 추가 권한을 받습니다. 이 개념은 낡은 것이 아니지만 지속적으로 개선되고 있습니다.

이는 새로운 현상이 아닙니다. 프로그램에 부여된 권한 수를 줄이는 것은 장기적인 추세입니다. 20년 전에는 루트가 아닌 사용자를 위한 setuid 실행 파일이 일반적이었지만 (운영 체제 권한 모델을 변경하지 않고) 이러한 실행 파일은 사실상 사라졌습니다. 요즘에는 추가 파일 권한에 대한 액세스가 필요한 실행 파일은 setuid가 아닌 setgid이므로 해당 파일이 손상되더라도 공격자는 프로그램이 보유한 것보다 더 많은 권한을 얻지 못합니다. setuid 실행 파일의 위험은 유출될 경우 공격자가 실행 파일의 내용을 트로이 목마로 대체하여 프로그램을 실행하는 모든 사람의 계정을 손상시킬 수 있다는 것입니다.

또한 프로그램이 setuid 또는 setgid를 설정하도록 허용하지 않고 대신 sudo를 통해 사용자에게 실행할 수 있는 권한을 부여하는 장기적인 추세도 있습니다. Sudo의 장점은 보다 세밀한 제어(프로그램을 실행할 수 있는 사람 및 프로그램에 전달할 수 있는 매개변수), 네트워크 배포가 더 쉽다는 것( /etc/sudoers설치 시 권한에 주의할 필요 없이 구성 파일만 배포하기만 하면 됨)입니다. , 프로그램 업그레이드 및 배포) 및 로깅.

마운트에는 루트가 아닌 사용자가 파티션을 마운트할 수 있도록 하려면 setuid 루트가 필요합니다. 이는 실제로 pmountsetuid 루트가 필요한 다른 프로그램이나 udisk와 같은 서비스 기반 메커니즘 으로 대체될 수 있습니다 .

실제로 setuid 루트여야 하는 프로그램은 두 개뿐입니다: su및 sudo. (및 기타 유사한 프로그램.) 모든 권한을 부여할 수 있어야 하므로 시스템에서 가장 높은 권한을 가지고 있어야 합니다.

SSH는 su와 sudo를 완전히 대체하지는 않습니다. SSH는 권한 상승 메커니즘으로 사용될 수 있지만 모든 상황에 적합한 것은 아닙니다. SSH 세션의 모든 내용은 터널을 통과합니다. 이는 항상 바람직한 것은 아닙니다. SSH 채널을 통해 파일 설명자나 공유 메모리를 전달할 수 없으므로 성능 저하가 발생합니다(SSH는 로컬로 통신하는 경우에도 데이터를 암호화합니다). 또한 SSH 데몬이 충돌하거나 잘못 구성된 경우 시스템을 복구하려는 시스템 관리자에게 SSH는 쓸모가 없습니다.

¹ _{또는 setcap 이지만 루트가 되는 것과 해당 권한으로 간접적으로 수행할 수 있는 작업 (예: setuid 루트 바이너리를 사용하여 파티션을 마운트하거나 또는 를 통해 무언가를 마운트하는 것) sys_admin사이에는 실질적인 차이가 없습니다 .sys_admin/etc/bin}