☰

CAP_CHROOT가 루트와 동일한 이유는 무엇입니까?

tag-icon • tag-icon debian security chroot capabilities
CAP_CHROOT가 루트와 동일한 이유는 무엇입니까?

CAP_CHROOT다음 템플릿의 루트 동등성을 이해할 수 없습니다 .

1)은 모든 종속성(예: 공유 객체)을 포함하는 디렉터리 구조를 생성하는 것을 의미하며 그 루트는 chroot(2).

내 질문에는 템플릿의 이후 단계가 포함됩니다.

  • ld.so백도어 또는 2)가 필요한 이유는 무엇입니까 libc?

  • 3)의 chroot 환경에서 setuid-root 바이너리로 하드 링크를 생성해야 하는 이유는 무엇입니까?

  • chroot(2)4)에서 시작 setuid-root 바이너리가 호출되는 이유는 무엇입니까 ?

여기에 이미지 설명을 입력하세요.

답변1

그렇지 않다필요한, 이것이 방법입니다.

루트 디렉터리를 변경하면 시스템 구성 요소의 가정이 무효화됩니다.

/bin/su사용자 데이터베이스가 /etc/passwd/ /etc/shadow( libc또는 연결된 라이브러리)에 /lib일반 사용자가 수정할 수 없는 고정된 위치에 있다고 가정합니다.

/bin/su동일한 명령을 실행할 수 있지만 자유롭게 다른 명령을 수정할 수 있는 다른 파일 시스템 레이아웃을 생성할 수 있다면 /etc/passwduse 또는 use(아마도 간접적으로)를 사용하여 사용자를 인증하고 코드를 실행할 수 있습니다.libcsu/etc/passwd

이제 이 접근 방식을 사용하면 CAP_CHROOT소유만이 필요한 것이 아닙니다. 또한 파일 시스템의 디렉터리에 대한 쓰기 권한도 있어야 합니다(하드 링크는 다음을 통해서만 수행할 수 있으므로).이내에특정 파일 시스템의 경우) 동적으로 연결된 setuid-root 실행 파일이 하나 이상 있습니다.

시스템에 사용자 쓰기 가능 영역(또는 읽기 전용 영역)이 없는 시스템 파티션이 있는 것은 드문 일이 아닙니다. 파일 시스템의 사용자 쓰기 가능 영역이 플래그를 사용하여 마운트되는 것도 일반적입니다 nosuid. 또한 많은 시스템에서는 소유하지 않은 파일에 대한 하드 링크를 비활성화합니다( fs.protected_hardlinks예: Linux 3.6+의 sysctl 참조).

그러나 chroot 감옥 내부에서 setuid 실행 파일을 하드링크할 필요는 없습니다. 다음과 같이 할 수도 있습니다.

chdir("/");
chroot("/tmp/myjail");
execl("bin/su", "su", 0);

프로세스의 루트 디렉터리가 변경되더라도 해당 디렉터리와 거기에서 확인된 디렉터리를 사용할 수 없더라도 chroot나중에 현재 작업 디렉터리를 계속 사용할 수 있기 때문입니다./bin/su~에감옥. 절대 경로를 통해 액세스되므로 여전히 감옥이나 libc 에서 /bin/su찾을 것입니다 .ld.so/etc/passwd루트 변경목차. 현재 작업 디렉터리나 감옥 외부의 파일에 열려 있는 파일 설명자를 그대로 두면 감옥에서 나갈 수 있는 문이 제공됩니다.

관련 정보