리눅스에서 어떻게 가짜 루트가 보안 침해가 아닌가?


18

이 질문 에서 꽤 좋은 답변을 읽은 후에도 여전히 근본이되는 이점을 얻지 않고 근본 인 척하는 이유에 대해 여전히 애매합니다.

지금까지 내가 수집 할 수있는 것은 fakeroot가 압축을 풀거나 tar 할 때 루트가되어야하는 파일에 소유권을 부여하는 데 사용된다는 것입니다. 내 질문은 왜 chown으로 그렇게 할 수 없습니까?

여기 에서 Google 그룹스 토론에 따르면 데비안 커널을 컴파일하려면 fakeroot가 필요합니다 (특권이없는 사용자가 원한다면). 내 의견은, 컴파일하기 위해 루트가되어야하는 이유는 아마도 다른 사용자에 대한 읽기 권한이 설정되지 않았기 때문일 것입니다. 그렇다면 fakeroot가 컴파일을 허용하는 보안 위반이 아닌가? (gcc는 이제 루트 용 파일을 읽을 수 있음을 의미합니까?)

이 답변 이곳은 실제 시스템 호출이 실제 UID / GID 사용자의로 만든 것을 설명 곳 fakeroot 사용 도움말을 수행 그래서 다시?

Linux에서 fakeroot는 원하지 않는 권한 에스컬레이션을 어떻게 중지합니까? fakeroot가 tar가 root가 소유 한 파일을 만들도록 속일 수 있다면 SUID와 비슷한 것을 시도해보십시오.

내가 수집 한 것에서 fakeroot는 루트로 빌드 한 패키지 파일의 소유자를 변경하려고 할 때 유용합니다. 그러나 당신은 chown으로 그것을 할 수 있습니다. 그래서이 구성 요소가 어떻게 사용되는지에 대한 이해가 부족합니까?


1
커널을 컴파일하기 위해 fakeroot가 필요하지 않습니다. 커널 빌드 시스템은 그리 미친 것이 아닙니다. 링크 된 토론은 데비안 커널 패키지 만들기 에 관한 것이며 실제 커널 빌드는 한 단계 일뿐입니다.

@ WumpusQ.Wumbley 나는 그것을 교정 할 것이며, 왜 그런지 말해 줄 수 있습니까?
ng.newbie

fakeroot는 데비안이고 Linux는 데비안 그 이상입니까?

@ WumpusQ.Wumbley는 모든 배포에서 실행되어야합니다.
user253751

답변:


33

지금까지 내가 수집 할 수있는 것은 fakeroot가 압축을 풀거나 tar 할 때 루트가되어야하는 파일에 소유권을 부여하는 데 사용된다는 것입니다. 내 질문은 왜 chown으로 그렇게 할 수 없습니까?

chown적어도 루트 사용자가 아닌으로 만 할 수 있기 때문입니다 . 루트로 실행하는 경우에는 필요하지 않습니다 fakeroot. 요점은 fakeroot루트로 실행될 것으로 예상되는 프로그램을 일반 사용자로 실행하고 루트 요구 작업이 성공한 것처럼 만드는 것입니다.

패키지를 빌드 할 때 일반적으로 사용되므로 설치중인 패키지의 설치 프로세스가 오류없이 진행될 수 있습니다 ( chown root:root또는 install -o root등을 실행하는 경우에도 ). fakeroot파일을 제공하는 것처럼 위장한 가짜 소유권을 기억하므로 소유권을 살펴 보는 후속 작업에서 실제 소유권 대신이를 볼 수 있습니다. 이것은 tar예를 들어 루트가 소유 한 파일을 저장하는 후속 실행을 허용 합니다.

Linux에서 fakeroot는 원하지 않는 권한 에스컬레이션을 어떻게 중지합니까? fakeroot가 tar가 root가 소유 한 파일을 만들도록 속일 수 있다면 SUID와 비슷한 것을 시도해보십시오.

fakeroottar아무것도 하지 않더라도 빌드를 호스팅하는 시스템에 이러한 변경 사항을 적용하지 않고 빌드하려는 변경 사항을 유지합니다. fakerootroot와 suid가 소유 한 파일을 포함하는 tarball을 생성 할 필요가 없습니다 . 바이너리가있는 경우 일반 사용자로을 evilbinary실행 tar cf evil.tar --mode=4755 --owner=root --group=root evilbinary하면 evilbinaryroot 소유의 su 및 suid를 포함하는 tarball이 생성됩니다 . 그러나 루트로 그렇게하지 않으면 해당 tarball을 추출하고 해당 권한을 보존 할 수 없습니다. 여기에는 권한 에스컬레이션이 없습니다. fakeroot특권입니다 -에스컬레이션 도구 : 일반 사용자로 빌드를 실행할 수 있으며, 루트로 실행했을 때의 빌드 효과를 유지하여 나중에 해당 효과를 재생할 수 있습니다. "실제로"효과를 적용하려면 항상 루트 권한이 필요합니다. fakeroot그것들을 얻는 방법을 제공하지 않습니다.

fakeroot보다 자세한 사용법을 이해하려면 일반적인 배포 빌드에는 다음과 같은 작업이 포함된다는 점을 고려하십시오.

  • 루트가 소유 한 설치 파일
  • ...
  • 루트가 소유 한 파일을 아카이브하여 압축을 풀면 루트가 소유하게됩니다.

루트가 아닌 경우 첫 번째 부분은 분명히 실패합니다. 그러나에서 fakeroot일반 사용자로 실행 하면 프로세스가

  • 루트가 소유 한 파일 설치 — 실패하지만 fakeroot성공한 척 하고 변경된 소유권을 기억합니다.
  • ...
  • 루트가 소유하고있는 파일을 아카이브합니다. tar(또는 어떤 아카이버가 사용 중인지) 파일 소유권이 무엇인지 시스템에 묻 으면 fakeroot이전에 기록 된 소유권과 일치하도록 응답이 변경됩니다.

따라서 루트가 아닌 패키지 빌드를 실행할 수 있으며 실제로 루트로 실행하는 경우와 동일한 결과를 얻을 수 있습니다. 사용하는 fakeroot것이 더 안전합니다 : 시스템은 여전히 ​​사용자가 할 수없는 일을 할 수 없으므로, 악성 설치 프로세스는 파일을 건드리지 않고 시스템을 손상시킬 수 없습니다.

데비안에서는 빌드 도구가 더 이상 필요하지 않도록 개선되었으며, 없이 패키지를 빌드fakeroot 할 수 있습니다 . 이것은 지시문 으로 dpkg직접 지원됩니다 Rules-Requires-Root(참조 rootless-builds.txt).

fakeroot루트로 실행 의 목적 과 보안 측면 을 이해하려면 패키징의 목적을 고려하는 것이 도움이 될 수 있습니다. 시스템 전체에서 사용하기 위해 소스에서 소프트웨어를 설치할 때 다음과 같이 진행하십시오.

  1. 소프트웨어 빌드 (권한없이 수행 가능)
  2. 소프트웨어 설치 (루트로 또는 최소한 사용자가 적절한 시스템 위치에 쓸 수 있도록해야 함)

소프트웨어를 패키징하면 두 번째 부분이 지연됩니다. 그러나 그렇게하려면 소프트웨어를 시스템이 아닌 패키지에 "설치"해야합니다. 따라서 소프트웨어를 패키지하면 프로세스가 다음과 같이됩니다.

  1. 특별한 권한없이 소프트웨어 구축
  2. 소프트웨어를 설치하는 척 (특별한 권한이없는 경우)
  3. 소프트웨어 설치를 패키지로 캡처 (ditto)
  4. 패키지를 사용 가능하게하십시오 (ditto)

이제 사용자는 루트 (또는 적절한 위치에 쓸 수있는 적절한 권한을 가진 사용자)로 수행해야하는 패키지를 설치하여 프로세스를 완료합니다. 지연된 특권 프로세스가 실현되는 곳이며 특수 특권이 필요한 프로세스의 유일한 부분입니다.

fakeroot 루트로 실행하지 않고 소프트웨어 설치 프로세스를 실행하고 동작을 캡처 할 수 있도록함으로써 위의 2 단계와 3 단계를 도와줍니다.


1
@ ng.newbie 다른 설명을 원한다면 : 16 진수 편집기를 사용하여 루트 또는 다른 가능한 권한이있는 파일을 포함하는 tar 파일을 수동으로 구성 할 수 있습니다. 파일이 실제로 시스템에 존재하기 전에는 정보가 묶여 있습니다.
mbrig

@ ng.newbie fakeroot 또는 fakeroot없이 untar 하시겠습니까?
user253751

2
@ ng.newbie 또한 악의적 인 목적으로 suid-root 바이너리를 사용하여 tarball을 만들려면 다른 컴퓨터에서 실제 루트로 수행 한 다음 대상에 복사하면됩니다. 거기에 가짜 뿌리가 필요하지 않습니다. fakeroot는 tar 파일을 만드는 데 도움이되는 도구 일 뿐이 tar --mode --owner므로 아카이브에 추가 된 모든 파일 을 사용할 필요가 없으며 다른 프로그램에서도 작동합니다. 신뢰할 수없는 tar 파일이나 아카이브를 만들 때가 아니라 루트로 압축을 풀면 잠재적 문제가 발생합니다.
ilkkachu

7

아니. 가짜 루트를 사용하면 권한 조작 및보고 도구를 실행할 수 있으며 일관되게보고됩니다. 그러나 실제로 이러한 권한을 부여하지는 않습니다. 당신이 (가짜)있는 것처럼 보일 것입니다. 환경 밖의 어떤 것도 변경하지 않습니다.

사용자가 설정할 수없는 소유권과 권한을 포함하는 디렉토리 구조를 작성하려는 경우 tar, zip 또는 기타 패키지가 유용합니다.

그것은 하지 않습니다 정말 가짜 권한을 상승. 다른 방법으로는 할 수없는 (삭제, 쓰기, 읽기) 작업을 수행 할 수 없습니다. 패키지없이 이론적으로 패키지를 생성 할 수 있습니다. ls그것없이 가짜 보고서 ( )를 얻을 수 있습니다.

보안 결함 이 아닙니다. 액세스를 허용 하지 않거나 액세스 권한 이 없으면 할 수없는 일이기 때문입니다. 권한없이 실행됩니다. 이 선량 모두에 차단 호출입니다 chown, chmod그것이 일어 났을 것을 기록하는 것을 제외하고, 등 그것은 그들 무 작동합니다. 또한 stat다른 명령이 수행 된 것처럼 자체 내부 데이터베이스에서 권한 및 소유권을보고 하도록 등을 호출하는 것을 차단합니다 . 디렉토리를 압축하면 가짜 권한이 있기 때문에 유용합니다. 그런 다음 루트로 압축을 풀면 권한이 실제가됩니다.

읽기 / 쓰기가 불가능한 모든 파일은 읽기 / 쓰기가 불가능합니다. 생성 된 특수 파일 (예 : 장치)에는 특별한 권한이 없습니다. set-uid (다른 사용자에게) 파일은 set-uid가 아닙니다. 다른 권한 상승은 작동하지 않습니다.

가상 머신의 유형입니다. 일반적으로 가상 머신은 모든 환경 / OS를 시뮬레이션 할 수 있지만 다른 애플리케이션이 수행 할 수없는 호스트에 대해서는 아무것도 수행 할 수 없습니다. 가상 머신 내에서 무엇이든 할 수 있습니다. 보안 시스템을 동일하거나 다른 것으로 재발 명 할 수 있지만 가상 환경을 실행하는 프로세스의 사용자 / 그룹이 소유 한 자원으로 호스트에 모두 존재합니다.


@ ctrl-alt-decor 위에서 언급 한 것처럼 * nix에서는 권한이없는 다른 사용자로부터 소유자를 루트로 설정할 수 없습니다. 따라서 프로그램이 허용한다면 보안 결함이 아닌 이유는 무엇입니까?
ng.newbie

@ ctrl-alt-decor fakeroot를 사용하면 읽기 / 쓰기 / 삭제를 할 수 없지만 syscall에 대한 래퍼를 작성한 경우 해당 작업을 수행 할 수 있다는 이유도 있습니다.
ng.newbie

@ ctrl-alt-decor fakeroot가 존재하는 유일한 이유는 root가 아닌 파일에 대한 권한을 root로 설정하는 것입니다. 이것이 보안 결함이 아니라면 왜 리눅스가 처음부터 그것을 허용하지 않습니까?
ng.newbie

1
아니 그것은 당신을 허용 가짜의 설정 사용자에 대한 사용자 및 가짜 다른 것들. 시도하십시오 : fakeroot를 실행하고 외부에서 파일을보고 파일에 액세스하십시오.
ctrl-alt-delor

4

여기에는 이미 두 가지의 훌륭하고 자세한 답변이 있지만 원본 fakeroot 매뉴얼 페이지 1 의 소개 단락에서 실제로 명확하고 간결하게 설명하고 있음을 지적합니다.

fakeroot 는 파일 조작에 대한 루트 권한이있는 환경에서 명령을 실행합니다. 이는 사용자가 루트 권한 / 소유권을 가진 파일을 사용하여 아카이브 (tar, ar, .deb 등)를 만들 수 있도록하는 데 유용합니다. fakeroot가 없으면 올바른 권한과 소유권을 가진 아카이브의 구성 파일을 생성 한 다음 압축을 풀거나 아카이버를 사용하지 않고 아카이브를 직접 구성해야하는 루트 권한이 있어야합니다.

Fakeroot를 사용하면 루트가 아닌 사용자가 루트 소유 파일을 포함하는 아카이브를 작성할 수 있습니다. 이는 Linux에서 이진 소프트웨어 패키지를 생성하고 분배하는 데 중요한 부분입니다. 이 없으면 fakeroot실제 루트로 실행하는 동안 패키지 아카이브를 생성해야 올바른 파일 소유권과 권한이 포함됩니다. 즉 것입니다 보안 위험합니다. 신뢰할 수없는 소프트웨어를 빌드하고 패키징하는 것은 루트 권한으로 수행하면 크게 노출됩니다. 덕분에 fakeroot권한이없는 파일을 가진 권한이없는 사용자는 여전히 루트 소유권이있는 파일을 포함하는 아카이브를 생성 할 수 있습니다. 2

그러나 파일이 EXTRACTED 될 때까지 실제로 아카이브의 어떤 것도 루트 소유 하지 않기 때문에 보안 위험 이 아닙니다 . 그럼에도 불구하고 권한있는 사용자가 수행 한 경우에만 루트 권한으로 파일을 추출합니다. fakeroot권한있는 사용자가 "루트"파일을 포함 하는 보조 아카이브를 추출하는 단계는 "가짜"루트가 실제로되는 단계입니다. 이 시점까지는 실제 루트 권한을 얻거나 우회하지 않습니다.

노트

  1. fakeroot 사용은로 가장 몇 가지 경쟁 / 모방 낳았다 fakeroot설치를 포함하는 경우 fakeroot-ngpseudo. 그러나 IMHO의 "모방 자"매뉴얼 페이지는이 질문에 대한 요점을 정확히 밝히는 것에 대해 거의 명확하지 않습니다. fakerootOG 만의 오리지널
  2. 다른 배포판 / 패키징 시스템은 단순히 패키지 아카이브에서 루트 소유권을 사용 하지 않음 으로써이를 극복합니다 . 예를 들어 Fedora에서 권한이없는 사용자가 소프트웨어를 컴파일, 설치 및 패키징 할 수 있습니다 fakeroot. 그것은 모든 사용자의 내에서 이루어집니다 $HOME/rpmbuild/공간, 같은 일반적으로 권한 단계 make installGET 리디렉션 (같은 메커니즘을 통해 --prefix그리고 DESTDIRA와) $HOME/rpmbuild/BUILDROOT/(실제로는 사용하지 않고 "fakechroot"공간의 일종으로 간주 될 수있는 계층 구조 fakechroot).

    그러나 동안에도 make install권한이없는 사용자가 모든 것을 실행하고 소유합니다. 추출 된 파일 소유권과 권한이 설정됩니다 root,root0644(또는 0755패키지 정의 (에서 재정의하지 않는 한, 기본적으로 실행 파일) .spec들이 최종 패키지 내의 메타 데이터로 저장중인 경우) 파일. rpm 패키지의 (권한이있는) 설치 프로세스까지는 실제로 권한이나 소유권이 적용되지 않기 때문에 fakeroot패키징 중에 루트도 필요 하지 않습니다 . 그러나 fakeroot실제로 동일한 결과에 대한 다른 경로입니다.


1
첫 번째 메모와 관련하여 우선권을 fakeroot-ng 주장fakeroot 하지만 실제로는 그것을 대체하지 않았으며 AFAIK fakeroot는 여전히 기본적으로 데비안에서 사용되는 도구입니다 (필요한 경우).
Stephen Kitt

트윗 담아 가기 감사. 나는 그것에 대해 궁금했다. 처음에는 fakeroot맨 페이지를 검색했기 때문에 혼란 스러웠 으며 Google은 님에게 fakeroot-ng(매 스매싱 fakeroot(1))을 버렸습니다 . 그러나 지금은 fakeroot 사용-NG는 것을 볼 수 2014 년 이후 업데이트되지 않은 반면, fakeroot 사용이 활성 상태 . 몇 년 전에 그것을 옮긴 의사 도 분명히 있지만 지금은 멈췄습니다. 그에 따라 대답을 조정하겠습니다.
FeRD

1
예, 데비안 사이트 fakeroot맨 페이지는fakeroot-ng 기본적으로의 버전으로 이어 지기 때문에 처음에는 혼란 스러웠습니다 . fakeroot-ng재미있는 트위스트 ;-) 의 마지막 단락을 확인하십시오 .
Stephen Kitt
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.