Tại sao chroot được coi là không an toàn?

Tôi đã chơi xung quanh với hộp CentOS được vài năm rồi. Vì vậy, tôi khá thoải mái với thiết bị đầu cuối. Tuy nhiên, tôi đã đọc rất nhiều bài đăng trên blog cho rằng chroot không an toàn và số lượng bài đăng đó đáng sợ. Có thực sự như vậy? Tại sao?

Tôi sử dụng chroot để khóa người dùng chỉ SFTP trong ngữ cảnh cụ thể, không có bất kỳ shell hay lệnh nào cả. Vì vậy, thực sự, vấn đề bảo mật với điều đó là gì?

Câu hỏi được lưu đày từ StackOverflow .

— Alexanderr Makov
nguồn

Đầu tiên: Câu hỏi chưa được đóng / di chuyển trên Stack Overflow , nhưng nó rõ ràng là OT ở đó. Hành động thích hợp sẽ là đợi cho đến khi nó được di chuyển hoặc gắn cờ và yêu cầu một mod thực hiện nó, không đăng chéo nó trên một trang web khác. Nhưng thứ hai: Nếu bạn "chơi xung quanh với CentOS", bạn cũng đã sai ở đây. Trang web này dành cho người quản trị hệ thống chuyên nghiệp, không phải người có sở thích - vui lòng xem Câu hỏi thường gặp của chúng tôi .

— Sven

@SvenW cảm ơn, tôi sẽ ghi nhớ mẹo của bạn cho tương lai. Và về 'giây', tốt, xin lỗi, nhưng tôi không thấy câu hỏi của mình vi phạm Câu hỏi thường gặp như thế nào. Sau khi đọc nó hai lần bây giờ, tôi có thể nói nó không. Đối với cụm từ "chơi xung quanh với CentOS", tôi nghĩ khá rõ ràng rằng người dùng chỉ sử dụng SFTP và được xem xét về bảo mật là một chủ đề rất nghiêm trọng mà các chuyên gia có thể hưởng lợi từ công ty của họ hoặc trong bất kỳ công ty nào khác " môi trường chuyên nghiệp.

— Alexanderr Makov

@sven trong trường hợp bạn không biết, SF đã bị xóa khỏi danh sách di chuyển của SO vì có bao nhiêu câu hỏi xấu họ gửi cho chúng tôi.

— MDMarra

Câu trả lời:

Bởi vì, trong hầu hết các trường hợp, một quá trình root có thể dễ dàng thoát khỏi chroot. Đây là do thiết kế, vì chroot không bao giờ được dự định là một thiết bị bảo mật.

Alan Cox đã mắng mỏ một nhà phát triển đã gửi một bản vá kernel để "sửa chữa" hành vi này, cho rằng chroot đã bị lạm dụng như một thiết bị bảo mật, nhưng không bao giờ có ý định trở thành một.

— MDMarra
nguồn

Hoàn hảo! Cảm ơn rât nhiều. Vì vậy, đây là vấn đề của các quá trình root có trong root hoặc có thể truy cập được từ nó. Cảm ơn.

— Alexanderr Makov

Tôi vừa xác minh rằng bằng cách chạy chương trình C được hiển thị trên unixwiz.net/techtips/mirror/chroot-break.html với quyền root trên Linux 4.18, có thể thoát khỏi chroot.

— pts

Vì vậy, đừng đưa ra các đặc quyền gốc. Ngay cả các hệ thống "an toàn" thông thường cũng có tài khoản root.

— Cees Timmerman

Tôi biết ít nhất một ví dụ về lý do tại sao nó được coi là không an toàn. Một môi trường chroot /prockhông bị cô lập, do đó khá dễ dàng để truy cập các tài nguyên không thuộc sở hữu của các quy trình bắt đầu trong chroot của bạn.

Sử dụng một môi trường chroot cho SFTP là tốt và cải thiện mức độ bảo mật đáng kể. Đừng lạm dụng nó như ảo hóa dựa trên container, cung cấp nhiều mức độ bảo mật hơn. Trong phần này, tôi nhấn mạnh những gì trong câu trả lời của @ MDMarra.

— gertvdijk
nguồn

Cảm ơn bạn. Vì vậy, bây giờ nó trở nên rõ ràng hơn, bản thân chroot không kém về bảo mật mà là bảo mật phụ thuộc vào môi trường nơi nó được thiết lập.

— Alexanderr Makov

Trên thực tế, chroot không kém về bảo mật, bởi vì nó không bao giờ được dự định là một thiết bị bảo mật. Nó có nghĩa là một công cụ phát triển để chạy nhiều phiên bản của cùng một nhị phân song song với các phụ thuộc khác nhau. Nó không thay thế cho việc bảo mật đúng cách các dịch vụ - mặc dù nó có thể hữu ích trong một số trường hợp miễn là bạn hiểu nó là gì và không phải là gì.

— MDMarra

MDMarra, về cơ bản, chroot không có nghĩa là được sử dụng để chụp các kết nối SSH. Sau đó, theo ý kiến của bạn, việc "chroot các kết nối SSH đến" nghe có vẻ không chuyên nghiệp đối với bạn và có nên tránh nó không?

— Alexanderr Makov

Không, không nhất thiết, chỉ cần nhận ra rằng bất kỳ khai thác nào có thể dẫn đến độ cao đặc quyền hoặc bất kỳ quá trình nào chạy như root trong chroot sẽ là tầm thường để thoát ra. Nó chắc chắn có thể là một mảnh trong câu đố, nhưng nó không nên là toàn bộ.

— MDMarra