อะไรทำให้ 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 แต่สำหรับสถานการณ์ที่คุณต้องการผู้ใช้เพียงคนเดียว (แทนที่จะเป็นหลายคน) ซึ่งอาจทำได้ยากหรือปลอดภัยน้อยกว่าสำหรับกระบวนการหลายอย่างในสถานการณ์จำลองคอนเทนเนอร์ ถ้าคุณต้องการที่จะรู้ว่าทำไมนักเทียบท่า, LXC และ systemd-nspawn เป็นอย่างโดยเนื้อแท้ไม่ได้เป็นกลไกการรักษาความปลอดภัยที่เป็นของแข็งอ่าน: https://opensource.com/business/14/7/docker-security-selinux โดยพื้นฐานแล้วคอนเทนเนอร์ยังคงมีการเข้าถึงเคอร์เนลและเคอร์เนลใด ๆ ที่ใช้ประโยชน์จากการควบคุมของเครื่องทั้งหมด บนเคอร์เนลเสาหินเช่น Linux การหาประโยชน์จากเคอร์เนลไม่ใช่เรื่องแปลก