Điều gì làm cho systemd-nspawn vẫn không phù hợp với các thiết lập vùng chứa an toàn trên mạng?

Điều này được nêu trong trang man cho systemd-nspawn

Lưu ý rằng mặc dù các biện pháp phòng ngừa bảo mật này được thực hiện systemd-nspawn không phù hợp cho các thiết lập vùng chứa an toàn. Nhiều tính năng bảo mật có thể bị phá hỏng và do đó chủ yếu hữu ích để tránh những thay đổi ngẫu nhiên cho hệ thống máy chủ từ container. Mục đích sử dụng của chương trình này là gỡ lỗi và thử nghiệm cũng như xây dựng các gói, bản phân phối và phần mềm liên quan đến khởi động và quản lý hệ thống.

Câu hỏi này sau đó đã được hỏi trong danh sách gửi thư vào năm 2011 , nhưng câu trả lời dường như đã lỗi thời.

systemd-nspawn chứa mã để thực thi CLONE_NEWNETbằng cách sử dụng --private-networktùy chọn ngay bây giờ. Điều này dường như bao gồm AF_UNIXvấn đề không gian tên riêng tư , và tôi đoán CAP_NET_RAWvà CAP_NET_BINDcác vấn đề được đề cập.

Những vấn đề còn tồn tại ở thời điểm này và ví dụ LXC làm gì ngoài những gì systemd-nspawnhiện có thể làm?

LXC tốt hơn một chút vì nó có thể chạy các container như những người dùng chưa được cấp phép . Điều này có thể xảy ra với systemd-nspawn, nhưng chỉ đối với các tình huống mà bạn chỉ cần một người dùng (thay vì nhiều người dùng), điều này có thể khó khăn hoặc kém an toàn cho nhiều quá trình trong các kịch bản vùng chứa. Nếu bạn muốn biết lý do tại sao docker, lxc và systemd-nspawn vốn không phải là một cơ chế bảo mật vững chắc, hãy đọc điều này: https://opensource.com/business/14/7/docker-security-selinux . Về cơ bản, các container vẫn có quyền truy cập vào kernel và mọi khai thác kernel đều giành quyền kiểm soát toàn bộ máy. Trên một hạt nhân nguyên khối như Linux, việc khai thác kernel không phải là hiếm.