스크립트에서 setuid를 활성화하면 보안 문제가 있으므로 기본적으로 비활성화되어 있지만 실행 파일에서는 작동 할 것으로 예상합니다. 이 게시물에 설명 된 지침에 따라 uid를 출력으로 보여주는 실행 파일을 만들었습니다. 쉘 스크립트에서 setuid 허용
그러나 실행 전후에 동일한 uid (1000)를 반환합니다 sudo chmod +s ./setuid-test. 이것은 setuid가 실행 파일에 아무런 영향을 미치지 않는다는 것을 의미한다고 생각합니다. 왜, 어떻게 해결합니까?
소스 코드 :
#include <stdio.h>
#include <unistd.h>
int main(int argc, char** argv) {
printf("%d", geteuid());
return 0;
}
내장 및 실행
$ gcc -o setuid-test setuid-test.c
$ ./setuid-test
1000
$ sudo chown nobody ./setuid-test; sudo chmod +s ./setuid-test
$ ./setuid-test
1000
실행할 때 ls -la이것이 내가 얻는 것입니다.
me@me:~$ ls -la setuid-test
-rwsrwsr-x 1 nobody me 8572 Aug 19 16:39 setuid-test
답변
유닉스 / 리눅스 용으로 설계된 대부분의 파일 시스템은 nosuid속성 으로 마운트 될 수 있으며 , 이로 인해 해당 파일 시스템에있는 setuid 또는 setgid 바이너리가 프로세스의 유효 uid 또는 gid를 변경하지 못하게됩니다. 관리자가 아닌 사람이 제어하는 ”신뢰할 수없는”파일 시스템을 마운트 할 때 자주 사용됩니다.
귀하의 경우, 사용하는 파일 시스템은 ecryptfs 유형입니다 . askubuntu 에 따르면 : 암호화 된 홈 디렉토리에서 루트 setuid를 사용하여 바이너리를 실행할 때 오류가 발생 하면 몇 년 전부터 시작하여 nosuid (및 nodev)가 자동으로 적용됩니다.
다음은 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-3409 의 변경 이유에 대한 설명입니다 .
Vincent Danen 2012-07-20 11:25:56 EDT
setuid-root 인 개인 ecryptfs 마운트 도우미 (/sbin/mount.ecryptfs_private)는 권한이없는 로컬 사용자가 사용자 제어 ecryptfs 공유를 마운트 할 수 있다고보고되었습니다. 로컬 시스템에서. ecryptfs 헬퍼는 “nosuid”및 “nodev”플래그를 사용하여 파일 시스템을 마운트하지 않기 때문에 사용자가 setuid-root 바이너리 및 / 또는 디바이스 파일을 포함하는 파일 시스템을 마운트하여 권한을 에스컬레이션 할 수 있습니다. 사용자가 시스템에 물리적으로 액세스 할 수있는 경우 USB 장치를 통해 수행 할 수 있습니다.
…
강제 MS_NOSUID 및 MS_NODEV 마운트 플래그가 버전 99에 추가되었습니다.
답변
실행 파일의 SetUID 비트를 사용하면 파일 소유자 (수퍼 유저 아님) 에서 실행 파일을 실행할 수 있습니다 . 실행 파일을 루트로 실행하려면 다음을 실행하십시오.
sudo chown 0:0 ./setuid-test