에 따르면 man 7 capabilities
CAP_DAC_READ_SEARCH
* Bypass file read permission checks and directory read and execute permission checks;
* Invoke open_by_handle_at(2).
이것은 나를 위해 일했습니다. ( '#'로 시작하는 행은 루트이고 '$'가있는 행은 루트가 아닙니다) 루트가 아닌 사용자가 wheel
그룹에 있습니다.
# cp /usr/bin/find /usr/bin/sudofind
# chmod 710 /usr/bin/sudofind
# chown root:wheel /usr/bin/sudofind
# setcap cap_dac_read_search+ep /usr/bin/sudofind
# exit
$ find /root
find: ‘/root’: Permission denied
$ sudofind /root
/root /root
/root/Testbed
...
...
$ sudofind /root -exec cat {} \;
cat: /root: Permission denied
cat: /root/Testbed: Permission denied
$ sudofind /root -printf "%u %g %m %c %p\n"
root root 644 Mon Apr 20 09:20:48.0457518493 2015 /root
root root 755 Fri Dec 4 02:34:03.0016294644 2015 /root/Testbed
...
...
$ # Capability inheritance test..
$ sudofind /root -exec /bin/sleep 10 \; &
[1] 17017
$ getpcaps $(pgrep find)
Capabilities for `17017': = cap_dac_read_search+ep
$ getpcaps $(pgrep sleep)
Capabilities for `17019': =
기능이 부여하는 것을 고려하면 원하는대로 정확하게 맞출 수 있습니다. find
파일 내부에서 바이트를 읽을 수있는 기능이 있는지 철저히 확인하지는 않았지만 LD_PRELOAD
Linux의 setuid 검사의 특성으로 인해 라이브러리 shim 공격과 같은 명백한 것들이 작동하지 않아야하며 기능 비트가 얻지 못합니다. 자식 프로세스에 의해 상속되므로 (원시 setuid와 달리) 또 다른 보너스입니다.
수행하려는 작업은 임시 파일 생성 또는 액세스와 관련하여 프라이버시 문제를 일으킬 수 있으며 프로그램은 경쟁 조건 / 권한 에스컬레이션 시도 (잘 알려진 파일 이름을 생성하는 프로그램에 대한)를 마운트하기위한 기초로 사용될 수 있습니다. 올바른 보안 검사를 수행하지 마십시오).
또한 잘못 작성된 일부 응용 프로그램은 의미를 전달하거나 데이터를 숨기는 방법으로 파일 메타 데이터 또는 트리 구조에 의존 할 수 있습니다. 이로 인해 제한적인 정보가 공개되거나 다른 방법으로 알려지지 않은 권한있는 문서가 공개 될 수 있습니다 (불분명 한 보안을 통해 보안이 제공되지만, 특히 비공개 소스 공급 업체가 유감스럽게도하는 일입니다).
따라서주의를 기울이고 수행하는 데주의를 기울이고 명백한 것이 작동하지 않더라도 여전히 이와 관련된 위험이 있음을 이해하십시오.
아, 그리고 누군가가이 메커니즘을 주석에서 권한 상승의 기초로 사용하는 개념 증명 공격을 가지고 있는지 알고 싶습니다.