일부 사용자가 Java 애플리케이션을 실행/테스트하기 위해 일부 chroot Jail을 설정할 계획입니다(각 애플리케이션을 신뢰할 수 없다고 가정). 각 감옥에 /dev 및 /proc를 마운트하는 데 위험이 있습니까? 만약 존재한다면, 이 위험을 제거하기 위해 어떤 조치를 취할 수 있습니까?
답변1
더 많은 정보를 공개 /proc하고 /dev노출할수록 교도소 내 사용자에게 더 많은 권리가 부여됩니다.
UID와 GID는 교도소 내부와 외부에서 다를 수 있습니다. 예를 들어 감옥 내에서 사용자 "x"는 감옥의 "사용자"와 시스템의 "디스크"를 나타내는 그룹 123의 구성원일 수 있습니다. 바인드 마운트를 사용하면 /dev원시 디스크 장치에 대한 액세스 권한을 부여하여 가상 루트 액세스를 허용하고 이를 피할 수 있습니다.
나는 mount /dev를 바인딩하지 않습니다. Java 애플리케이션에 필요할 수 있는 적절한 소유권과 권한을 가진 몇 개의 장치( null, tty, ...) 만 생성하십시오.zero
chroot Jail 대신 Linux 컨테이너를 사용하는 것을 고려해 보셨나요? 이 컨테이너는 더 격리되어 있습니다(lxcs는 chroot Jail보다 한 단계 더 발전했습니다).
답변2
이것은 꽤 큰 주제이고 온라인에서 이에 대해 많은 글이 올라왔으므로 한 번 읽어 보시기 바랍니다.
기본 요약은 chroot가 결코 보안 기능으로 설계되지 않았다는 것입니다. 루트 사용자는 여러 가지 방법으로 chroot 감옥을 "탈출"할 수 있으며 일반 사용자도 여러 가지 방법으로 탈출할 수 있습니다. 예를 들어 chroot에는 별도의 프로세스 공간이 없으므로 chroot 내의 프로세스는 일반적인 디버깅 메커니즘을 사용하여 외부 프로세스에 "연결"될 수 있습니다. 일부 최신 배포판에는 특정 공격을 차단하는 보호 기능이 활성화되어 있지만 전부는 아닙니다. 그럼에도 불구하고 루트 사용자는 사실상 이러한 모든 보호 장치에 면역이며 선택한 파일 시스템을 마운트하는 것을 막을 수 있는 방법이 없습니다.
LXC가 더 좋고 많은 최신 배포판에도 내장되어 있지만(내 생각에는) 동일한 문제가 있습니다(특히 /sys 파일 시스템은 남용되기 쉽습니다).
OpenVZ는 더 안전하다고 알려져 있지만 설정하기가 훨씬 더 어렵고 직접 시도해 보지 않았습니다.