☰

fakeroot는 어떻게 Linux의 보안 허점을 구성하지 않습니까?

tag-icon • tag-icon linux chown fakeroot
fakeroot는 어떻게 Linux의 보안 허점을 구성하지 않습니까?

좋은 답변을 읽은 후이 문제, 실제로 루트가 되는 이점을 전혀 얻지 못한 채 루트인 척하려는 이유가 무엇인지 아직도 잘 모르겠습니다.

지금까지 제가 수집할 수 있는 것은 파일 압축 해제/압축 시 루트 권한이 필요한 파일의 소유권을 부여하는 데 fakeroot가 사용된다는 것입니다.내 질문은 왜 chown으로 이것을 할 수 없습니까?

Google 그룹스 토론여기데비안 커널을 컴파일하려면 fakeroot가 필요함을 나타냅니다(권한이 없는 사용자가 이 작업을 수행하려는 경우).내 의견은 컴파일하기 위해 루트가 필요한 이유는 아마도 다른 사용자에게 읽기 권한이 설정되지 않았기 때문일 것입니다. 그렇다면 컴파일을 허용하는 것은 fakeroot에 대한 보안 위반입니까(이제 gcc가 루트의 파일을 읽을 수 있다는 의미)?

이 답변여기사용자의 실제 uid/gid를 사용하여 수행되는 실제 시스템 호출을 설명합니다., 그렇다면 fakeroot는 어떻게 도움이 되나요?

fakeroot는 Linux에서 불필요한 권한 상승을 어떻게 방지합니까?fakeroot가 tar를 속여 루트에 속하는 파일을 생성할 수 있다면 SUID를 사용하여 유사한 작업을 수행해 보는 것은 어떨까요?

내가 수집한 바에 따르면 fakeroot는 루트로 빌드된 패키지 파일의 소유자를 루트로 변경하려는 경우에만 유용합니다. 하지만 chown을 사용하면 가능합니다.그렇다면 이 구성 요소가 어떻게 사용되는지에 대한 이해가 부족합니까?

답변1

지금까지 제가 수집할 수 있는 것은 파일 압축 해제/압축 시 루트 권한이 필요한 파일의 소유권을 부여하는 데 fakeroot가 사용된다는 것입니다.내 질문은 왜 chown으로 이것을 할 수 없습니까?

chown적어도 루트가 아닌 사용자로는 으로 만 할 수는 없기 때문입니다 . (root로 실행 중인 경우에는 필요하지 않습니다 fakeroot.) 이것이 요점입니다 fakeroot. 루트로 실행하려는 프로그램이 루트가 필요한 작업이 성공한 것처럼 가장하면서 일반 사용자로 실행되도록 허용하는 것입니다.

이는 일반적으로 설치되는 패키지의 설치 프로세스가 원활하게 진행될 수 있도록 패키지를 빌드할 때 사용됩니다(실행되는 경우에도 chown root:root) install -o root. fakeroot파일의 잘못된 소유권을 제공하는 척하므로 소유권을 확인하는 후속 작업에서는 실제 소유권 대신 이 소유권을 보게 됩니다. tar예를 들어, 이를 통해 후속 실행에서 파일을 루트 소유로 저장할 수 있습니다.

fakeroot는 Linux에서 불필요한 권한 상승을 어떻게 방지합니까?fakeroot가 tar를 속여 루트에 속하는 파일을 생성할 수 있다면 SUID를 사용하여 유사한 작업을 수행해 보는 것은 어떨까요?

fakeroot아무것도 하기 위해 속임수를 쓰지 않으며 tar, 빌드를 호스팅하는 시스템에 변경 사항이 적용되지 않도록 빌드에서 원하는 변경 사항을 유지합니다. 루트 및 suid가 소유한 파일이 포함된 타르볼을 생성할 필요가 없습니다 fakeroot. 바이너리가 있고 evilbinary일반 사용자로 실행하면 루트 및 suid가 소유한 타르볼이 포함된 타르볼이 생성됩니다. 그러나 루트로 이 작업을 수행하지 않으면 tarball을 추출하고 이러한 권한을 유지할 수 없습니다. 여기서는 권한 상승이 없습니다. 특권이다tar cf evil.tar --mode=4755 --owner=root --group=root evilbinaryevilbinaryfakeroot덕-업그레이드 도구: 루트로 실행할 때 빌드의 효과를 유지하고 해당 효과를 나중에 재생할 수 있도록 하면서 일반 사용자로 빌드를 실행할 수 있습니다. "실제" 응용 프로그램 효과에는 항상 루트 액세스가 필요합니다. fakeroot이를 얻을 수 있는 방법은 제공되지 않습니다.

사용법을 더 자세히 이해하려면 fakeroot일반적인 릴리스 빌드에 다음 작업이 포함된다는 점을 고려하세요.

  • 루트가 소유한 설치 파일
  • ...
  • 여전히 루트가 소유하고 있는 파일을 보관하여 추출 시 루트가 소유하게 됩니다.

루트가 아닌 경우 첫 번째 부분은 분명히 실패합니다. fakeroot그러나 아래에서 실행될 때

  • 루트가 소유한 파일 설치 - 실패하지만 fakeroot성공한 척합니다.변경된 소유권을 기억하세요
  • ...
  • 여전히 루트가 소유하고 있는 이 파일을 보관합니다. tar(또는 사용 중인 보관 프로그램이 무엇이든) 시스템에 파일 소유권이 무엇인지 묻는 경우 fakeroot이전에 기록된 소유권과 일치하도록 대답을 변경합니다.

따라서 실제로 루트로 실행하는 것과 동일한 결과를 얻으면서 루트 없이 패키지 빌드를 실행할 수 있습니다. 더 안전한 사용 fakeroot: 시스템은 사용자가 할 수 없는 작업을 수행할 수 없으므로 악의적인 설치 프로세스로 인해 시스템이 손상될 수 없습니다(파일을 건드리는 것 제외).

Debian에서는 빌드 도구가 개선되어 이 기능이 더 이상 필요하지 않습니다.빌드 패키지는 그렇지 않습니다.fakeroot. 이는 지시문을 dpkg통해 직접적으로 Rules-Requires-Root지원 됩니다(참조:rootless-builds.txt).

루트로 실행할지 여부의 목적 fakeroot과 보안 측면을 이해하려면 패키징의 목적을 고려하는 것이 도움이 될 수 있습니다. 시스템 전체에서 사용하기 위해 소스 코드에서 소프트웨어를 설치하는 경우 다음 단계를 따르세요.

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

소프트웨어를 패키지화할 때 두 번째 부분을 연기하지만 이를 성공적으로 수행하려면 소프트웨어를 시스템이 아닌 패키지에 "설치"해야 합니다. 따라서 소프트웨어를 패키징할 때 프로세스는 다음과 같습니다.

  1. 소프트웨어 빌드(특별 권한 없음)
  2. 소프트웨어를 설치하는 척(역시 권한 없이)
  3. 소프트웨어 설치를 패키지로 캡처(동일)
  4. 패키지를 사용 가능하게 만드세요(동일)

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

fakeroot이는 루트로 실행하지 않고도 소프트웨어 설치 프로세스를 실행하고 해당 동작을 캡처할 수 있도록 하여 위의 2단계와 3단계를 수행하는 데 도움이 됩니다.

답변2

아니요. 가짜 루트를 사용하면 권한 조작 및 보고 도구를 실행하여 일관되게 보고할 수 있습니다. 그러나 실제로 이러한 권한을 부여하지는 않습니다. (가짜) 가지고 있는 것 같습니다. 환경 외부에서는 아무것도 변경되지 않습니다.

이는 소유권과 권한이 있는 디렉터리 구조를 만들고 싶지만 사용자가 해당 디렉터리 구조를 설정할 수 없어 tar, zip 또는 다른 방식으로 패키지화할 수 있는 경우에 유용합니다.

그것확실히정말로 권한을 확대한다면 그것은 가짜입니다. 사용자가 할 수 없는 작업(삭제, 쓰기, 읽기)은 수행할 수 없습니다. (이론적으로) 그것 없이도 패키지를 생산할 수 있습니다. ls그렇지 않으면 잘못된 보고( )를 받을 수 있습니다.

이는 보안 결함이 아니기 때문에확실히액세스를 허용하거나, 그것 없이는 수행할 수 없는 모든 작업을 허용합니다. 실행하는 데 권한이 필요하지 않습니다. 그것이 하는 일은 , chown등에 대한 호출을 가로채는 것뿐입니다. chmod일어날 수 있는 일을 기록한다는 점을 제외하고는 작동하지 않습니다. 또한 stat다른 명령과 마찬가지로 자체 내부 데이터베이스에서 권한과 소유권을 보고하기 위해 피어에 대한 호출을 가로챕니다. 디렉토리를 압축하면 가짜 권한이 생기기 때문에 이는 유용합니다. 그런 다음 루트로 압축을 풀면 권한이 실제가 됩니다.

이전에 읽을 수 없거나 쓸 수 없었던 파일은 여전히 ​​읽거나 쓸 수 없습니다. 생성된 특수 파일(예: 장치)에는 특별한 권한이 없습니다. (다른 사용자에게) set-uid인 파일은 set-uid가 되지 않습니다. 다른 권한 상승은 효과가 없습니다.

이는 일종의 가상 머신입니다. 일반적으로 가상 머신은 모든 환경/운영 체제를 에뮬레이트할 수 있지만 호스트에서는 다른 애플리케이션이 수행할 수 없는 작업을 수행할 수 없습니다. 가상 머신에서는 무엇이든 할 수 있는 것처럼 보입니다. 보안 시스템을 동일하거나 다르게 재설계할 수 있지만 모두 가상 환경의 프로세스를 실행하는 사용자/그룹이 소유한 리소스로 호스트 시스템에 존재하게 됩니다.

답변3

여기에는 이미 두 가지 훌륭하고 매우 자세한 답변이 있지만 지적하고 싶습니다.원래 fakeroot 매뉴얼 페이지1실제로 매우 명확하고 간결하게 설명되었습니다.

가근성파일 작업에 대한 루트 권한이 있는 것으로 보이는 환경에서 명령을 실행하십시오. 이는 사용자가 루트 권한/소유권을 가진 파일이 포함된 아카이브(tar, ar, .deb 등)를 생성할 수 있도록 하는 데 유용합니다. 아니요가근성올바른 권한과 소유권을 사용하여 아카이브의 구성 파일을 생성한 다음 이를 패키징하려면 루트 액세스 권한이 필요하거나 아카이버를 사용하지 않고 직접 아카이브를 빌드해야 합니다.

Fakeroot를 사용하면 루트가 아닌 사용자가 루트 소유 파일이 포함된 아카이브를 생성할 수 있습니다. 이는 Linux에서 바이너리 패키지를 구축하고 배포하는 데 핵심적인 부분입니다. 그렇지 않은 경우 fakeroot실제 루트로 실행할 때 패키지 아카이브가 올바른 파일 소유권과 권한을 포함하도록 생성해야 합니다. 저것회의보안 위험이 있습니다. 루트 권한을 사용하여 잠재적으로 신뢰할 수 없는 소프트웨어를 빌드하고 패키징하는 경우 상당한 위험이 있습니다. 다행히도 fakeroot권한이 없는 파일이 있는 권한이 없는 사용자는 여전히 루트 소유권을 가진 파일이 포함된 아카이브를 생성할 수 있습니다.2

하지만 아카이브에는 아무것도 없기 때문에 보안 위험은 없습니다.실제로파일이 삭제될 때까지 루트가 소유합니다.발췌. 그럼에도 불구하고 권한이 있는 사용자가 수행한 경우 루트 권한이 손상되지 않은 경우에만 파일을 추출할 수 있습니다. fakeroot권한이 있는 사용자가 "루트" 파일을 포함하는 보조 아카이브를 추출하는 이 단계 에서 "가짜" 루트가 마침내 진짜가 됩니다. 그 시점까지는 실제 루트 권한을 얻거나 우회하지 않았습니다.

노트

  1. fakerootFakeroot는 다음을 포함하여 설치된 척하는 수많은 경쟁업체/모방 제품을 생성했습니다.fakeroot-ng그리고pseudo. 그러나 IMHO, 두 "모방범"의 매뉴얼 페이지에서는 문제의 요점을 명확하게 밝히지 않습니다. 독창성을 고집하는 독특한 fakerootOG

  2. 다른 유통/포장 시스템은 간단히 말해서 이 문제를 극복합니다.아니요패키지 아카이브에서 루트 소유권을 사용하십시오. 예 를 들어, Fedora에서는 권한이 없는 사용자 가 fakeroot. "fakechroot" 공간의 계층 구조(실제 사용 없음 ).$HOME/rpmbuild/make install--prefixDESTDIR$HOME/rpmbuild/BUILDROOT/fakechroot

    그러나 그 동안에도 make install모든 것은 권한이 없는 사용자로 실행되고 소유됩니다. 기본적으로 추출된 파일 소유권 및 권한은 패키지 정의() 파일에서 재정의되지 않는 한 root,rootand 0644(또는 0755실행 파일의 경우) 로 설정되며 .spec, 이 경우 최종 패키지에 메타데이터로 저장됩니다. rpm 패키지(권한) 설치 과정까지는 실제로 권한이나 소유권이 적용되지 않으므로 fakeroot패키징 과정에서는 루트나 루트가 필요하지 않습니다. 그러나 이는 fakeroot실제로 동일한 결과를 얻기 위한 다른 경로일 뿐입니다.

관련 정보