system()을 통한 SuSE의 suid 비트는 효과가 없습니다.

system()을 통한 SuSE의 suid 비트는 효과가 없습니다.

[편집: 질문을 다시 방문하여 여전히 중복으로 잘못 표시된 것을 확인했습니다.] SE에 대한 다음 질문은 suid 비트로 bash를 실행하는 방법을 묻기 때문에 중복이 아닙니다. 이는 특별한 경우이고 작동하지 않습니다. 모두: setuid 비트는 bash에 영향을 미치지 않는 것 같습니다. 첫 번째 차이점은 내 예에서는 bash가 아닌 whoami를 실행한다는 것입니다. 두 번째 차이점은 실제로 Ubuntu에서는 예상대로 작동하지만 SuSE에서는 작동하지 않는다는 것입니다.

Suid 비트는 Ubuntu를 실행하는 PC에서는 제대로 작동하지만 SLES 테스트 인스턴스에서는 작동하지 않습니다. SLES 시스템에 마운트된 xfs 파일 시스템에는 nosuid 플래그가 설정되어 있지 않습니다. ls이는 내 시스템과 SLE 서버만이 실행 파일에 대해 동일한 권한 세트를 갖고 있음을 보여줍니다. 그렇다면 실행 파일이 소유자가 아닌 현재 사용자로 계속 실행되는 이유는 무엇입니까?

execsudo.c:

#include <stdio.h>
#include <stdlib.h>

int main(int argc,char *argv[]) {
    system(argv[1]);
    return 0;
}

큰 타격:

gcc -o setuid-test execsudo.c ;
sudo chown nobody ./setuid-test;
sudo chmod +s ./setuid-test;
./setuid-test "whoami" 
# Outputs current user instead of nobody

[EDIT 2] 아직 문제를 해결하지 못했지만 SuSE 머신이 가상 머신이기 때문이 아닐까 싶습니다. 해결 방법은 /etc/sudoers를 통해 이 동작을 구성하는 것입니다.

답변1

이는 setuid"작동"할 수 있지만 나중에 쉽게 감지하고 실행 취소할 수 있습니다. 비슷한 목적의 프로그램과 비교해 봤습니다sue, 대체 계정 dickey(프로그램 이름 dickey)에서 로컬로 사용합니다.

내 Debian 7 시스템에서는 다음과 같은 출력을 얻습니다(시스템은 "foo"입니다):

$ ./foo id;dickey id
uid=1001(tom) gid=100(users) euid=1006(dickey) egid=50(staff) groups=100(users),27(sudo)
uid=1006(dickey) gid=100(users) groups=100(users),27(sudo)

OpenSUSE 13에서는 다른 결과가 나타납니다.

$ ./foo id;dickey id
uid=1000(thomas) gid=100(users) groups=100(users),10(wheel)
uid=1003(dickey) gid=100(users) groups=100(users),10(wheel)

차이점이 있는 이유는 프로그램이 해당 항목을 설정하지 않았기 때문입니다.진짜uid/gid 값 일치효과적인uid/gid 값과 유용한 프로그램(아마도 의류)이 원치 않는 권한을 제거하고 있습니다.

이것은 여전히 ​​완벽한 솔루션이 아닙니다. 다른 유용한 프로그램이 setuid 프로그램을 방해하는 CentOS 7 백로그가 있습니다. 하지만 올바른 방향을 알려주어야 합니다.

추가 자료:

관련 정보