Vai trò nào của DAC (quyền truy cập tệp), ACL và MAC (SELinux) đóng trong bảo mật tệp Linux?

Tôi cần một số giải thích / xác nhận / xây dựng về các vai trò khác nhau của DAC, ACL và MAC trong bảo mật tệp Linux.

Sau một số nghiên cứu từ tài liệu, đây là sự hiểu biết của tôi về ngăn xếp:

1. SELinux phải cho phép bạn truy cập vào đối tượng tệp.
2. Nếu ACL của tập tin (ví dụ setfacl, getfaclđối với một núi ACL) cho phép một cách rõ ràng / từ chối truy cập đến đối tượng, sau đó xử lý không xa hơn là bắt buộc.
3. Mặt khác, tùy thuộc vào quyền của tệp (mô hình DAC rwxrwxrwx).

Tui bỏ lỡ điều gì vậy? Có những tình huống mà đây không phải là trường hợp?

Khi một quá trình thực hiện một thao tác với một tệp, nhân Linux sẽ thực hiện kiểm tra theo thứ tự sau:

1. Kiểm soát truy cập tùy ý (DAC) hoặc kiểm soát truy cập chính tả của người dùng. Điều này bao gồm cả kiểm tra quyền theo kiểu UNIX cổ điển và Danh sách điều khiển truy cập POSIX (ACL) . Các kiểm tra UNIX cổ điển so sánh quy trình hiện tại UID và GID so với UID và GID của tệp đang được truy cập liên quan đến chế độ nào đã được đặt (Đọc / Ghi / eXecute). Danh sách điều khiển truy cập mở rộng kiểm tra UNIX cổ điển để cho phép nhiều tùy chọn hơn về kiểm soát quyền.

2. Kiểm soát truy cập bắt buộc (MAC) hoặc kiểm soát truy cập dựa trên chính sách. Điều này được triển khai bằng Mô-đun bảo mật Linux (LSM) không còn là mô-đun thực nữa (trước đây chúng đã bị loại bỏ). Chúng cho phép kiểm tra bổ sung dựa trên các mô hình khác ngoài kiểm tra bảo mật kiểu UNIX cổ điển. Tất cả các mô hình đó đều dựa trên một chính sách mô tả loại hình đối lập nào được phép cho quá trình nào trong bối cảnh nào.

Dưới đây là một ví dụ cho truy cập inodes (bao gồm quyền truy cập tệp) để trả lời câu trả lời của tôi với các liên kết đến Tham chiếu chéo Linux trực tuyến . Các "function_name (Tên tệp: dòng)" được cung cấp dành cho phiên bản 3.14 của nhân Linux.

Hàm inode_permission( fs / namei.c: 449 ) trước tiên kiểm tra quyền đọc trên chính hệ thống tệp ( sb_permissiontrong fs / namei.c: 425 ), sau đó gọi __inode_permission( fs / namei.c: 394 ) để kiểm tra đọc / ghi / thực thi quyền và POSIX ACL trên một nút inode do_inode_permission( fs / namei.c: 368 ) (DAC) và sau đó là các quyền liên quan đến LSM (MAC) trong security_inode_permission( security / security.c: 550 ).

Chỉ có một ngoại lệ cho đơn đặt hàng này (DAC rồi MAC): đó là kiểm tra mmap. Nhưng điều này đã được sửa trong phiên bản 3.15 của nhân Linux ( cam kết liên quan ).

DAC== Discretionary Access Control, http://en.wikipedia.org/wiki/Discemonyary_access_control
MAC == Mandatory Access Control, http://en.wikipedia.org/wiki/Mandatory_access_control
ACL == Access Control List, http://en.wikipedia.org/wiki/Access_control_list

Chỉ ACLđịnh các điều khiển được áp dụng theo phương pháp điều khiển, DAChoặc MAC. MACrõ ràng, được kiểm soát tập trung và không cho phép người dùng cấp quyền cho đối tượng trừ khi họ có quyền rõ ràng để làm như vậy, trong khi DACcho phép người dùng cấp cho người dùng khác quyền truy cập vào đối tượng họ có thể truy cập.

MAC ACLs sẽ luôn được áp dụng cho yêu cầu trước và nếu quyền truy cập bị từ chối thì việc xử lý sẽ dừng lại. Nếu quyền truy cập được cho phép thì DAC ACLs được áp dụng và một lần nữa nếu quyền truy cập bị từ chối dừng xử lý. Chỉ khi quyền truy cập được cấp bởi cả hai MACvà DAC ACLngười dùng mới có thể truy cập đối tượng họ yêu cầu.

SELinuxlà một MACtriển khai cho Linux (có những thứ khác), trong khi các rwxquyền của tệp truyền thống , kết hợp với người dùng sở hữu và nhóm tạo thành hoàn chỉnh DAC ACL. Các SELinuxchính sách 'là cơ bản MAC ACL.

Xin lỗi để ngụy biện, nhưng tôi nghĩ rằng một số câu trả lời ở đây có thể không chính xác. Trực tiếp từ Fedora của http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html :

Các quy tắc chính sách của Selinux được kiểm tra sau các quy tắc của DAC. Các quy tắc chính sách của Selinux không được sử dụng nếu quy tắc DAC từ chối truy cập trước tiên.