[server] sudo로 안전하게 찾기 사용

Server / 글쓴이

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

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

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

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

답변

에 대해 무엇을 찾아 ?

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

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

아니면 어쩌면 따로 :

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

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

답변

에 따르면 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와 달리) 또 다른 보너스입니다.

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

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

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

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

답변

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

기본적으로 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

답변