Thay đổi trong cách Red Hat phân phối mã nguồn RHEL
- Vào tháng 6 năm 2023, Red Hat đã đưa ra một quyết định gây tranh cãi là thay đổi cách phân phối mã nguồn đứng sau Red Hat Enterprise Linux (RHEL)
- Quyết định này làm dấy lên nhiều câu hỏi về khả năng tồn tại trong tương lai của các bản dựng lại downstream của RHEL như Rocky Linux, AlmaLinux và Oracle Linux
- Sau đó, từng bản phân phối đã đưa ra thông báo để trấn an cộng đồng
- Nhiều cộng đồng mã nguồn mở đã diễn giải quyết định của Red Hat là ảnh hưởng từ lòng tham của doanh nghiệp
- Mọi người nói rằng họ đang chuyển sang Debian hoặc đã chuyển sang đó để tìm nơi trú ẩn
Tầm quan trọng và sự khó khăn của bảo mật
- Bảo mật là việc khó, tẻ nhạt, khó chịu và cần rất nhiều nỗ lực nếu muốn làm cho đúng
- Debian không nỗ lực đủ để bảo vệ người dùng
Việc Red Hat áp dụng SELinux và cung cấp chính sách mặc định
- Red Hat đã chấp nhận sử dụng SELinux từ rất lâu trước đây, và không chỉ dừng ở việc kích hoạt tính năng này trong kernel
- Họ đã làm phần việc khó là xây dựng các chính sách SELinux mặc định cho bản phân phối
- Các chính sách này được bật sẵn theo mặc định trên RHEL và giúp bảo vệ nhiều daemon và máy chủ thường dùng chạy mặc định trên RHEL
- Apache, nginx, MariaDB, PostgreSQL, OpenSSH cùng nhiều thành phần khác đều được bảo vệ bởi các chính sách SELinux đi kèm trong bản phân phối RHEL
Áp dụng chính sách SELinux cho container
- Sự bảo vệ này còn mở rộng tới cả container
- Container ngày càng trở thành phương thức được các nhà phát triển ưa chuộng để triển khai phần mềm
- Việc chạy thứ gì đó trong container không mặc nhiên có nghĩa là an toàn
- Bản thân container giải quyết bài toán triển khai phần mềm chứ không giải quyết vấn đề bảo mật
- Trên các bản phân phối dựa trên Red Hat, có thể dùng
podman, một lựa chọn thay thế Docker cho phép chạy container không cần daemon và hoàn toàn rootless
- Red Hat còn tiến thêm một bước khi áp dụng các chính sách SELinux mặc định mạnh mẽ để cô lập container khỏi hệ điều hành máy chủ và khỏi các container khác
- Việc áp dụng chính sách SELinux cho container cung cấp một lớp bảo vệ tăng cường nhằm giảm thiểu rủi ro từ các lỗ hổng chưa biết có thể xuất hiện trong tương lai
Nỗ lực của Red Hat trong việc cung cấp chính sách SELinux mặc định
- Red Hat hiểu rằng nếu không tự làm phần việc liên quan đến các chính sách mặc định này thì người dùng sẽ không chấp nhận công nghệ đó, và hàng triệu máy chủ sẽ vẫn ở trong trạng thái dễ bị tấn công
- SELinux rất khó; ngôn ngữ chính sách và công cụ của nó phức tạp, khó hiểu và chẳng hấp dẫn hơn việc khai thuế là bao
- Tuy nhiên, nhờ công sức của Red Hat, việc sử dụng SELinux trên RHEL phần lớn diễn ra một cách minh bạch và mang lại lợi ích bảo mật thực tế cho người dùng
Cách tiếp cận AppArmor của Debian
- Debian là một trụ cột của cộng đồng mã nguồn mở, nổi tiếng về tính ổn định và thư viện phần mềm phong phú
- Tuy nhiên, khung bảo mật mặc định của Debian còn rất nhiều chỗ cần cải thiện
- Quyết định bật AppArmor theo mặc định từ Debian 10 là một bước đi tích cực cho việc cải thiện bảo mật, nhưng cách triển khai nửa vời trên toàn hệ thống khiến nó chưa đủ tốt
- Việc Debian phụ thuộc vào AppArmor và cấu hình mặc định của nó cho thấy có những vấn đề mang tính hệ thống trong cách tiếp cận bảo mật
- AppArmor có thể cung cấp khả năng bảo mật mạnh nếu được cấu hình đúng, nhưng thiết lập mặc định của Debian không tận dụng được tiềm năng đó
Những vấn đề của AppArmor trên Debian
- Hồ sơ mặc định hạn chế: Debian đi kèm một bộ hồ sơ AppArmor tối thiểu, nên nhiều dịch vụ quan trọng không được bảo vệ
- Tư thế phản ứng thay vì chủ động: mô hình bảo mật của Debian thường dựa vào việc người dùng tự triển khai các chính sách nghiêm ngặt hơn thay vì cung cấp cấu hình an toàn ngay từ mặc định
- Áp dụng không nhất quán: không giống SELinux trên hệ thống Red Hat, AppArmor trên Debian chỉ được áp dụng một phần, tạo ra các khoảng trống bảo mật tiềm tàng
- Thiếu nguồn lực: là một dự án do cộng đồng dẫn dắt, Debian thiếu nguồn lực để phát triển và duy trì các chính sách bảo mật toàn diện tương tự như những gì Red Hat cung cấp
Chạy khối lượng công việc container bằng Docker trên Debian
- Việc chạy workload container thông qua Docker trên Debian là rất phổ biến
- Docker tự động tạo và nạp một hồ sơ AppArmor mặc định cho container có tên là
docker-default
- Không may là đây không phải một hồ sơ bảo mật quá mạnh và nó quá dễ dãi
- Hồ sơ này mang lại một mức độ bảo vệ nhất định, nhưng vẫn để lộ một bề mặt tấn công đáng kể
Khác biệt căn bản giữa AppArmor và SELinux
- Khác biệt căn bản giữa AppArmor và SELinux nằm ở cách tiếp cận đối với kiểm soát truy cập bắt buộc (MAC)
- AppArmor hoạt động theo mô hình dựa trên đường dẫn, trong khi SELinux dùng một hệ thống thực thi kiểu loại phức tạp hơn rất nhiều
- Sự khác biệt này đặc biệt nổi bật trong môi trường container
- SELinux gán kiểu cho mọi đối tượng trong hệ thống, như tệp, tiến trình, cổng và các đối tượng khác
- Khi khởi chạy container trên hệ thống RHEL có hỗ trợ SELinux, nó ngay lập tức được gán kiểu
container_t, một cơ chế kiểm soát truy cập nghiêm ngặt
- Kiểu
container_t chặn container một cách hiệu quả, ngăn nó tương tác với các đối tượng không được gắn nhãn rõ ràng để dùng cho container
- SELinux không dừng ở việc thực thi kiểu, mà còn tiến thêm một bước trong cô lập container bằng cách sử dụng nhãn bảo mật đa danh mục (MCS)
- Các nhãn này đóng vai trò như một lớp tách biệt bổ sung, duy trì sự cô lập ngay cả giữa các container cùng một kiểu (
container_t)
- Mỗi container nhận một nhãn MCS riêng, tạo ra một sandbox riêng tư bên trong môi trường
container_t rộng hơn
Cách tiếp cận của AppArmor
- AppArmor không quan tâm tới kiểu hay danh mục, mà tập trung vào việc giới hạn khả năng của các chương trình cụ thể dựa trên các hồ sơ được định nghĩa sẵn
- Các hồ sơ này chỉ định những tệp mà chương trình có thể truy cập và những thao tác mà nó có thể thực hiện
- Cách tiếp cận này đơn giản hơn để triển khai và hiểu, nhưng không chi tiết bằng, cũng không nhất quán trên toàn hệ thống như cơ chế thực thi kiểu của SELinux
- Các bản phân phối Linux phổ biến không mặc định triển khai các hồ sơ AppArmor toàn diện cho mọi daemon hướng mạng thông dụng
Tác động thực tế
- Trong môi trường SELinux, một container bị xâm nhập sẽ phải đối mặt với rào cản rất lớn nếu muốn truy cập hoặc tác động tới hệ thống máy chủ hay các container khác, nhờ hai lớp phòng thủ là thực thi kiểu và nhãn MCS
- SELinux cung cấp khả năng cô lập mạnh hơn, nhưng cái giá phải trả là độ phức tạp tăng lên và chi phí hiệu năng tiềm tàng
- AppArmor mang lại một mô hình bảo mật đơn giản hơn và dễ tiếp cận hơn, nhưng vẫn có thể rất hiệu quả nếu được cấu hình đúng
- Red Hat đã đầu tư công sức để làm cho SELinux và việc sử dụng container trở nên trơn tru và dễ dàng
- Cuối cùng, lựa chọn giữa Debian và Red Hat không đơn thuần chỉ là lựa chọn giữa ảnh hưởng doanh nghiệp và phát triển do cộng đồng dẫn dắt
- Đó cũng là lựa chọn giữa một hệ thống giả định điều tốt nhất và một hệ thống chuẩn bị cho tình huống xấu nhất
- Trong thế giới kết nối chặt chẽ ngày nay, đáng tiếc là sự bi quan lại là điều cần thiết
Ý kiến của GN⁺
- Việc Red Hat thay đổi chính sách phân phối mã nguồn RHEL gây tranh cãi, nhưng xét từ góc độ bảo mật thì có thể là một quyết định hợp lý
- Với các bản phân phối Linux dành cho doanh nghiệp, việc cung cấp các tính năng bảo mật mạnh như SELinux là điều thiết yếu
- Tuy nhiên, thay đổi chính sách của Red Hat có thể ảnh hưởng tiêu cực tới hệ sinh thái mã nguồn mở, và vai trò của các bản phân phối dựa vào cộng đồng như Debian sẽ càng trở nên quan trọng hơn
- Debian được biết đến là một bản phân phối thân thiện với người dùng và linh hoạt, nhưng cần tăng cường các tính năng bảo mật mặc định
- AppArmor không mạnh bằng SELinux, nhưng nếu được cấu hình phù hợp thì vẫn có thể là một giải pháp bảo mật hiệu quả
- Về lâu dài, có thể sẽ cần phát triển một khung bảo mật mới kết hợp ưu điểm của cả SELinux và AppArmor
- Bảo mật container là một vấn đề rất quan trọng trong thời đại cloud-native, vì vậy mọi bản phân phối đều cần đầu tư nhiều hơn vào phần này
2 bình luận
Đúng là AppArmor kém nghiêm ngặt hơn SELinux..
Nhưng khó mà nói vì thế mà bảo mật của nó yếu.
SELinux quá nghiêm ngặt nên khi thiết lập máy chủ, gần như ai cũng tắt SELinux đi.
Và trên desktop, bảo mật không phải là mối quan tâm chính của SELinux.
Cần có các giới hạn cần thiết trong UI hay trải nghiệm người dùng và quy trình yêu cầu xác thực phù hợp, và đây là câu chuyện khác với việc cô lập tài nguyên như SELinux.
Vì vậy, bảo mật desktop, dù là hệ Red Hat hay hệ Debian, đều vận hành dựa trên polkit (PolicyKit) được chuẩn hóa tại freedesktop.
Ý kiến trên Hacker News