systemd-nspawn이 여전히 "보안 컨테이너 설정에 적합하지 않은"이유는 무엇입니까?

이것은 systemd-nspawn 의 맨 페이지에 명시되어 있습니다

이러한 보안 예방 조치를 취하더라도 systemd-nspawn은 안전한 컨테이너 설정에 적합하지 않습니다. 많은 보안 기능이 우회 될 수 있으므로 컨테이너에서 호스트 시스템이 실수로 변경되는 것을 방지하는 데 주로 유용합니다. 이 프로그램의 목적은 부팅 및 시스템 관리와 ​​관련된 패키지, 배포판 및 소프트웨어의 구축은 물론 디버깅 및 테스트입니다.

이 질문은 이후 2011 년 메일 링리스트에서 요청 되었지만 답변이 구식 인 것 같습니다.

systemd-nspawn에는 지금 옵션을 CLONE_NEWNET사용하여 실행할 코드가 포함되어 있습니다 --private-network. 이것은 개인 AF_UNIX네임 스페이스 문제 를 다루는 것으로 보이며 언급 한 CAP_NET_RAW및 CAP_NET_BIND문제를 추측합니다 .

현재 어떤 문제가 남아 있으며 LXC와 같이 systemd-nspawn현재 수행 할 수있는 작업 외에도 어떤 문제 가 있습니까?

LXC는 권한이없는 사용자로 컨테이너 를 실행할 수 있기 때문에 조금 더 좋습니다 . 이는 systemd-nspawn에서 가능하지만 여러 사용자 대신 한 명의 사용자 만 필요한 경우에만 가능하며 컨테이너 시나리오의 다중 프로세스에서는 어렵거나 덜 안전 할 수 있습니다. docker, lxc 및 systemd-nspawn이 본질적으로 견고한 보안 메커니즘이 아닌 이유를 알고 싶다면 https://opensource.com/business/14/7/docker-security-selinux를 읽으십시오 . 기본적으로 컨테이너는 여전히 커널에 액세스 할 수 있으며 모든 커널 악용은 전체 시스템을 제어합니다. Linux와 같은 모 놀리 식 커널에서 커널 악용은 드물지 않습니다.