![커널의 어떤 부분이 네임스페이스를 지원하지 않습니까? [폐쇄]](https://linux55.com/image/161411/%EC%BB%A4%EB%84%90%EC%9D%98%20%EC%96%B4%EB%96%A4%20%EB%B6%80%EB%B6%84%EC%9D%B4%20%EB%84%A4%EC%9E%84%EC%8A%A4%ED%8E%98%EC%9D%B4%EC%8A%A4%EB%A5%BC%20%EC%A7%80%EC%9B%90%ED%95%98%EC%A7%80%20%EC%95%8A%EC%8A%B5%EB%8B%88%EA%B9%8C%3F%20%5B%ED%8F%90%EC%87%84%5D.png)
chroot저는 Docker 보안에 대해 배우기 시작하면서 최신 컨테이너 기술의 기초를 형성하는 cgroup, 네임스페이스 및 기능을 소개받았습니다 .
/proc역사적으로, 읽기/쓰기 등 을 통해 사용자 공간에서 네임스페이스를 인식하지 못하는 커널 부분을 남용하여 많은 컨테이너 취약점이 악용되었습니다 modprobe.
네임스페이스 개념은 잘 알고 있지만, 사용자 네임스페이스 대신 루트 네임스페이스에서 코드를 실행할 수 있도록 네임스페이스 경계가 언제 적용을 중지하는지 잘 모르겠습니다.
답변1
취약점이지만 언급한 유형은 아닙니다.
임의의 Docker 컨테이너를 생성하고 실행할 수 있는 사용자는 호스트 파일 시스템의 매핑된 부분을 사용하여 컨테이너를 생성할 수 있습니다. 그런 다음 컨테이너에서 루트로 실행하여 디스크에 setuid 루트 프로그램을 생성할 수 있습니다. 그런 다음 호스트에서 이 명령을 실행하여 루트 권한을 얻을 수 있습니다.
답변2
이것은 매우 개방적이기 때문에 훌륭하지만 대답하기 어려운 질문입니다.
"코드"의 의미에 따라 "코드가 루트 네임스페이스에서 실행될 수 있음" 부분에 중점을 둡니다.
- 네임스페이스가 없더라도 사용자 공간 부분은 격리되어야 합니다. 즉, 작성하는 모든 코드는 네임스페이스에 관계없이 다른 모든 코드와 별도로 실행됩니다.
- 시스템 호출을 통해 호출되면 커널 자체에서 항상 모든 것에 액세스할 수 있습니다(가상 머신 자체가 아닌 이상). 이는 커널 부분이 어떤 방식으로든 분리되지 않음을 의미합니다. [1]
위 #2의 의미는 프로세스별 추상화를 통해 네임스페이스를 인식한다는 것입니다. 즉, 프로세스 테이블의 해당 항목은 네임스페이스의 일부(예: 루트 파일 시스템)를 직접 또는 간접적으로 가리킵니다. 그 시점부터 커널 측의 무언가가 제대로 작동하는 한 항상 올바른 데이터 세트에 액세스한다는 점에서 "격리"되어야 합니다.
그러나 이는 버그가 다른 컨테이너를 포함하여 실행 중인 시스템의 모든 측면에 영향을 미칠 수 없다는 의미는 아닙니다.
격리된 시스템에서 무언가를 실행하려면 전체 가상 머신이나 Linux 사용자 공간이 필요합니다. 컨테이너는 프로세스와 이들이 보고 액세스할 수 있는 대상을 격리하도록 설계되었습니다. 오류가 발생하면 일반 프로세스가 결국 루트로 코드를 실행할 수 있는 것처럼 제한을 초과할 수 있습니다.
[1] 시스템과 관련된 거의 모든 작업은 시스템 호출을 사용하여 수행됩니다. 예를 들어 파일 열기, 소켓에 쓰기, 신호 보내기 등이 있습니다.