DAC (สิทธิ์ของไฟล์), ACL และ MAC (SELinux) มีบทบาทอะไรในการรักษาความปลอดภัยของไฟล์ Linux?

ฉันต้องการชี้แจง / ยืนยัน / ทำอย่างละเอียดเกี่ยวกับบทบาทที่แตกต่างกันของ DAC, ACL และ MAC ในการรักษาความปลอดภัยไฟล์ Linux

หลังจากการวิจัยจากเอกสารประกอบนี่เป็นความเข้าใจของฉันเกี่ยวกับสแต็ก:

1. SELinux ต้องอนุญาตให้คุณเข้าถึงวัตถุไฟล์
2. หาก ACL ของไฟล์ (เช่นsetfacl, getfaclการติด ACL) ชัดเจนให้ / ปฏิเสธการเข้าถึงวัตถุแล้วการประมวลผลต่อไปไม่จำเป็นต้องมี
3. มิฉะนั้นจะขึ้นอยู่กับการอนุญาตของไฟล์ (โมเดล rwxrwxrwx DAC)

ฉันพลาดอะไรไปรึเปล่า? มีสถานการณ์ที่นี่ไม่ใช่กรณีหรือไม่

เมื่อกระบวนการดำเนินการกับไฟล์เคอร์เนล Linux จะทำการตรวจสอบตามลำดับต่อไปนี้:

1. Discretionary Access Control (DAC)หรือการควบคุมการเข้าถึงที่กำหนดโดยผู้ใช้ นี้รวมทั้งคลาสสิก UNIX ตรวจสอบได้รับอนุญาตรูปแบบและรายการ POSIX Access Control (ACL) การตรวจสอบ UNIX แบบคลาสสิกจะเปรียบเทียบกระบวนการปัจจุบัน UID และ GID เทียบกับ UID และ GID ของไฟล์ที่ถูกเข้าถึงโดยคำนึงถึงโหมดที่ตั้งค่าไว้ (อ่าน / เขียน / eXecute) รายการควบคุมการเข้าถึงขยายการตรวจสอบ UNIX แบบคลาสสิกเพื่อให้ตัวเลือกเพิ่มเติมเกี่ยวกับการควบคุมสิทธิ์

2. การควบคุมการเข้าถึงบังคับ (MAC)หรือการควบคุมการเข้าถึงตามนโยบาย สิ่งนี้ถูกนำไปใช้โดยใช้Linux Security Modules (LSM)ซึ่งไม่ใช่โมดูลจริงอีกต่อไป (เคยเป็น แต่มันถูกทิ้ง) พวกเขาเปิดใช้งานการตรวจสอบเพิ่มเติมตามรุ่นอื่น ๆ กว่าการตรวจสอบความปลอดภัยสไตล์ UNIX แบบดั้งเดิม โมเดลเหล่านั้นทั้งหมดมีพื้นฐานมาจากนโยบายที่อธิบายว่า opeartions ประเภทใดที่ได้รับอนุญาตสำหรับกระบวนการที่บริบทใด

นี่คือตัวอย่างสำหรับการเข้าถึง inodes (ซึ่งรวมถึงการเข้าถึงไฟล์) ที่จะกลับคำตอบของฉันมีการเชื่อมโยงไปยังออนไลน์ลินุกซ์อ้างอิงข้าม " function_name(ชื่อไฟล์: บรรทัด)" ที่ให้ไว้สำหรับเคอร์เนล Linux รุ่น 3.14

ฟังก์ชั่นinode_permission( fs / namei.c: 449 ) ตรวจสอบการอนุญาตการอ่านบนระบบไฟล์ก่อน ( sb_permissionในfs / namei.c: 425 ) จากนั้นเรียก__inode_permission( fs / namei.c: 394 ) เพื่อตรวจสอบการอ่าน / เขียน / ดำเนินการ การอนุญาตและ POSIX ACL บน inode ในdo_inode_permission( fs / namei.c: 368 ) (DAC) และสิทธิ์ที่เกี่ยวข้องกับ LSM (MAC) ในsecurity_inode_permission( security / security.c: 550 )

มีข้อยกเว้นเพียงข้อเดียวสำหรับคำสั่งนี้ (DAC และ MAC): สำหรับการตรวจสอบ mmap แต่สิ่งนี้ได้รับการแก้ไขในเคอร์เนล Linux รุ่น 3.15 (การคอมมิทที่เกี่ยวข้อง )

DAC== Discretionary Access Control, http://en.wikipedia.org/wiki/Discretionary_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

ACLระบุการควบคุมที่จะนำมาใช้โดยวิธีการในการควบคุมหรือ DAC มีความชัดเจนควบคุมจากส่วนกลางและไม่อนุญาตให้ผู้ใช้ให้สิทธิ์แก่วัตถุยกเว้นกรณีที่พวกเขามีสิทธิ์อย่างชัดเจนในการทำเช่นนั้นในขณะที่ผู้ใช้สามารถอนุญาตให้ผู้ใช้อื่นเข้าถึงวัตถุที่พวกเขาสามารถเข้าถึงได้MACMACDAC

MAC ACLs จะถูกนำไปใช้กับคำขอก่อนเสมอและหากการเข้าถึงถูกปฏิเสธการประมวลผลจะหยุด หากได้รับอนุญาตการเข้าถึงจะมีการใช้DAC ACLs และอีกครั้งหากการเข้าถึงถูกปฏิเสธการประมวลผลหยุด เฉพาะเมื่อได้รับอนุญาตจากทั้งสองMACและDAC ACLs ผู้ใช้สามารถเข้าถึงวัตถุที่พวกเขาร้องขอ

SELinuxคือMACการดำเนินงานสำหรับลินุกซ์ (มีคนอื่น ๆ ) ในขณะที่แบบดั้งเดิมสิทธิ์ของแฟ้มรวมกับรูปแบบที่ผู้ใช้และกลุ่มที่เป็นเจ้าของที่สมบูรณ์rwx 'นโยบาย' เป็นหลักDAC ACLSELinuxMAC ACL

ขออภัยที่เล่นลิ้น แต่ฉันคิดว่าบางคำตอบที่นี่อาจไม่ถูกต้อง โดยตรงจากhttp://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Selinux_Contexts_Labeling_Files.htmlของ Fedora โดยตรง:

มีการตรวจสอบกฎนโยบาย SELinux หลังจากกฎ DAC กฎนโยบาย SELinux จะไม่ถูกใช้หากกฎ DAC ปฏิเสธการเข้าถึงก่อน