☰

chroot 시스템의 한계는 무엇입니까? [폐쇄]

tag-icon • tag-icon devices chroot root-filesystem
chroot 시스템의 한계는 무엇입니까? [폐쇄]

Chroot를 사용하면 루트 디렉터리 또는 특정 프로세스의 루트 디렉터리를 변경할 수 있습니다. 이제 분명히 이는 프로세스를 지정된 트리로 제한합니다(권한을 포기하지 않는 한).

하지만 이 경우 또 어떤 한계가 생길지 궁금합니다. 특히 장치 및 기타 리소스에 대한 액세스와 관련하여. 분명히 이는 프로세스가 원래 트리로 다시 루트되지 않는다고 가정합니다.

내 생각에는 그러한 급격한 변화는 시스템 기능에 더 많은 영향을 미칠 것입니다. 하지만 구체적인 내용은 찾을 수 없습니다.

아닐 수도 있지만 그럴 가능성은 낮아 보이고 확실히 알고 싶습니다.

답변1

기능적으로는 아무것도 아닙니다. 말 그대로 이 chroot()호출이 하는 일은 커널이 프로세스의 앵커 경로를 확인하는 위치를 업데이트하는 것뿐입니다. 특히, 루트 권한도 포기하지 않는 한, 이 경우 여전히 액세스 권한이 있고 /proc( /sys적절한 시스템 호출을 할 수 있으므로 mount()외부 바이너리가 필요하지 않음) 여전히 장치 노드에 액세스할 수 있습니다( mknod()시스템을 사용하여 다시 생성 할 수 있음). 호출) 외부 바이너리가 필요하지 않으며 문자 그대로 상상할 수 있는 모든 작업을 수행합니다.

chrooting 직후 루트 권한을 포기하는 경우(대부분의 잘 작동하는 응용 프로그램이 그렇듯이) 외부 프로그램이나 라이브러리가 필요하지 않다면 전환한 사용자 컨텍스트에서 할 수 있는 모든 작업을 계속 수행할 수 있습니다. chroot 환경에는 없습니다.

하지만 그렇다고 하더라도 chroot 자체의 실제 보안 가치는 거의 0에 가깝다는 점을 참고하시기 바랍니다. 실제로진짜다양한 메커니즘을 통해 chroot를 탈출하는 것은 쉽습니다(진지하게, 즐겨 사용하는 검색 엔진에서 "chroot에서 탈출"을 검색하면 최소한 6가지 방법이 나열된 결과를 찾을 수 있습니다). 임의의 애플리케이션에서 이 취약점을 악용하는 데 필요한 것은 ACE 취약점뿐입니다. 실제로 chroot()원래 보안을 위해 설계된 것은 아니며 격리된 환경에서 새 소프트웨어를 테스트할 수 있도록 설계된 개발자 도구였으며 지금도 그렇습니다(무엇보다도 이제는 자동화된 빌드 및 CI에서 더 일반적으로 사용됨). 체계).

답변2

장치에 대한 액세스: chroot 환경에 필요한 장치 노드의 자체 복사본이 포함되어 있지 않으면 액세스가 불가능합니다. 예를 들어 /dev/nullchroot 환경에 장치 노드가 없으면 chroot된 대화형 쉘이 이상하게 동작할 수 있습니다.

/dev/logchroot 환경에서 추가 프로세스를 생성 하도록 syslog 데몬을 구성하지 않는 한 chroot 환경의 프로세스는 syslog 메시지를 보낼 수 없습니다 .

/proc및 /sys파일 시스템이 번들로 마운트되지 않았거나 chroot 환경에서 사용할 수 없는 경우 이를 사용하는 시스템 상태 쿼리 도구는 작동하지 않습니다 .

관련 정보