sudo로 안전하게 찾기 사용


10

Linux 서버에서는 사용자 그룹에서 루트 권한을 제거해야합니다. 그러나 이러한 사용자는 "찾기"유틸리티를 사용하여 파일 이름, 수정 날짜 및 기타 메타 데이터를 기반으로 파일을 검색 할 수있는 합당한 이유가 있습니다.

서버에서 파일 이름은 중요하지 않지만 파일 내용은 민감 할 수 있습니다.

sudo를 사용하여 사용자가 서버의 어느 곳에서나 파일을 검색 할 수 있도록하고 싶습니다. "find"유틸리티는 훌륭하지만 "-exec"를 사용하여 임의의 명령을 생성하는 등 모든 종류의 부작용을 허용합니다.

find제한 사항에 대해 작업 할 수 있습니까 ?


14
일반적으로 당신이 하지 않는 파일 이름 패턴에 대한 검색 결과가 당신이 할 수 실제로 액세스 파일을 포함합니다. 이와 관련하여 귀하의 요구 사항은 약간 이상합니다.
HBruijn

2
아무도 당신이 질문에 참여하도록 강요하지 않습니다. Server Fault의 목적 중 하나는 이상한 상황에 대한 포럼 역할을하는 것입니다.
Troels Arvin

2
Server Fault는 포럼이 아니며 리버스 심리학 시도는 HBruijn의 관찰의 유효성을 변경하지 않습니다 (확실히 도움이 되려고했습니다).
궤도에서 가벼움 경주

답변:


19

에 대해 무엇을 찾아 ?

locate는 updatedb (8)에 의해 준비된 하나 이상의 데이터베이스를 읽고 하나 이상의 PATTERN과 일치하는 파일 이름을 한 줄에 하나씩 표준 출력에 씁니다. --regex를 지정하지 않으면 PATTERN에 globbing 문자가 포함될 수 있습니다. PATTERN에 globbing 문자가 포함되지 않은 경우 locate는 패턴이 PATTERN 인 것처럼 동작 합니다.

기본적으로 locate는 데이터베이스에서 찾은 파일이 여전히 존재하는지 여부를 확인하지 않습니다. locate는 관련 데이터베이스를 가장 최근에 업데이트 한 후에 생성 된 파일을보고 할 수 없습니다.

아니면 어쩌면 따로 :

보안 찾기는 시스템에서 파일을 색인화하고 빠르게 검색하는 안전한 방법을 제공합니다. 검색 속도를 높이기 위해 데이터베이스를 압축하기 위해 GNU 찾기와 마찬가지로 증분 인코딩을 사용하지만 파일 권한과 소유권도 저장하여 사용자가 액세스 권한이없는 파일을 볼 수 없도록합니다.

이 매뉴얼 페이지는 GNU 버전의 slocate를 설명합니다. slocate 시스템 사용자가 무단 파일을 표시하지 않고 전체 파일 시스템을 검색 할 수 있습니다.


좋은 생각. 왜 내가 이것을 생각하지 않았는지 모르겠다. 그러나 sudo 규칙을 통해 사용자가 "locate"명령을 실행할 수있는 경우 "-d"매개 변수를 사용하여 임의의 파일을 읽을 수 있습니다.
Troels Arvin

2
@TroelsArvin : locate필요하지 않습니다 sudo; updatedb작업 에만 특별한 권한이 필요합니다. 따라서 사용자가 실행 중이거나 실행할 수 없어야합니다 sudo locate.
jwodder

1
@jwodder : RHEL 7 서버에서 : 사용자 u가 / data / foo에 액세스 할 수 없다고 가정합니다. / data / foo에는 "somefile.csv"파일이 있습니다. u가 "somefile.csv 찾기"를 수행 할 때 "locate"의 출력에는 /data/foo/somefile.csv가 포함되지 않습니다. 사용자 u가 sudo를 통해 "locate"를 실행하지 않는 한. ( "--nofollow"인수를 사용해도 도움이되지 않습니다.)
Troels Arvin

1
@TroelsArvin 그러나 -d플래그는 데이터베이스 경로 만 설정합니까? 어쩌면 당신을 오해했을 수도 있습니다.
Lenniey

21

에 따르면 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_PRELOADLinux의 setuid 검사의 특성으로 인해 라이브러리 shim 공격과 같은 명백한 것들이 작동하지 않아야하며 기능 비트가 얻지 못합니다. 자식 프로세스에 의해 상속되므로 (원시 setuid와 달리) 또 다른 보너스입니다.

수행하려는 작업은 임시 파일 생성 또는 액세스와 관련하여 프라이버시 문제를 일으킬 수 있으며 프로그램은 경쟁 조건 / 권한 에스컬레이션 시도 (잘 알려진 파일 이름을 생성하는 프로그램에 대한)를 마운트하기위한 기초로 사용될 수 있습니다. 올바른 보안 검사를 수행하지 마십시오).

또한 잘못 작성된 일부 응용 프로그램은 의미를 전달하거나 데이터를 숨기는 방법으로 파일 메타 데이터 또는 트리 구조에 의존 할 수 있습니다. 이로 인해 제한적인 정보가 공개되거나 다른 방법으로 알려지지 않은 권한있는 문서가 공개 될 수 있습니다 (불분명 한 보안을 통해 보안이 제공되지만, 특히 비공개 소스 공급 업체가 유감스럽게도하는 일입니다).

따라서주의를 기울이고 수행하는 데주의를 기울이고 명백한 것이 작동하지 않더라도 여전히 이와 관련된 위험이 있음을 이해하십시오.

아, 그리고 누군가가이 메커니즘을 주석에서 권한 상승의 기초로 사용하는 개념 증명 공격을 가지고 있는지 알고 싶습니다.


5
이것은 실제로 매우 흥미로워 보입니다!
Sven

이처럼? PoC는 없지만 재미 있음 : forums.grsecurity.net/…
Lenniey

이 아이디어가 마음에 들지만 중요한 단점이 있습니다. sudofind는 이제 시스템의 소프트웨어 (예 : RPM) 패키지의 일부가 아닌 바이너리입니다. 따라서 배포판에서 "find"에 대한 패치를 보내면 sudofind는 업데이트되지 않습니다.
Troels Arvin

2
@TroelsArvin 반드시 나쁜 것은 아닙니다. setuid와 유사한 기능을 해당 기능 용으로 설계되지 않은 기존 유틸리티에 추가하는 경우 업데이트 된 유틸리티를 비표준으로 안전하게 사용할 수 있는지 확인하기 전에 기본 유틸리티에 대한 업데이트를 원하지 않습니다 능력. 이 경우 업데이트가 find수행 awk할 수있는 것과 유사한 일부 사용자 제공 코드를 직접 실행할 수 있는 기능 을 제공한다고 가정 해보십시오 .
Andrew Henle

4
내가 볼 수있는 가장 큰 문제는 검색 할 수없는 디렉토리 아래에있는 세계 쓰기 가능 디렉토리가 갑자기 쓰여질 수 있다는 것입니다.
Tavian Barnes

2

사용자에게 적절한 권한을 부여합니다.

기본적으로 umask가 인 경우 022모든 사용자가 파일을 나열하고 통계 할 수 있도록 디렉토리가 작성됩니다. 그렇지 않은 경우 디렉토리 권한을 비트 단위 또는 이전 권한으로 수동으로 변경할 수 있습니다 0555.

chmod +0555 foo

그리고 해당 사용자에게 해당 디렉토리의 모든 상위 (예 : 다른 사용자의 홈 디렉토리)에 대한 실행 권한이없는 경우 첫 번째 디렉토리를 다른 곳에 두어야합니다.

일부 사용자 만 해당 디렉토리를 읽고 실행하게하려면 모드를로 변경하고 0750해당 사용자를 그룹에 넣고 디렉토리의 그룹 소유자를 해당 그룹으로 변경할 수 있습니다.

groupadd can_read_foo
chmod 0750 foo
chgrp can_read_foo foo
gpasswd -a alice can_read_foo
gpasswd -a bob can_read_foo
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.