แนวคิดเกี่ยวกับ SELinux

โปรดอ่านหน้านี้เพื่อให้คุ้นเคยกับแนวคิดของ SELinux

การควบคุมการเข้าถึงที่จำเป็น

Security Enhanced Linux (SELinux) เป็นระบบควบคุมการเข้าถึงที่จำเป็น (MAC) สำหรับระบบปฏิบัติการ Linux ในฐานะระบบ MAC ระบบนี้จึงแตกต่างจากระบบควบคุมการเข้าถึงแบบเลือกได้ (DAC) ที่คุ้นเคยของ Linux ในระบบ DAC จะมีแนวคิด การเป็นเจ้าของ ซึ่งเจ้าของทรัพยากรหนึ่งๆ จะควบคุมสิทธิ์การเข้าถึง ที่เชื่อมโยงกับทรัพยากรนั้น โดยทั่วไปแล้ว การควบคุมนี้จะมีความละเอียดต่ำและอาจทำให้มีการโจมตีเพื่อยกระดับสิทธิ์โดยไม่ตั้งใจ อย่างไรก็ตาม ระบบ MAC จะปรึกษาหน่วยงานกลาง เพื่อตัดสินใจเกี่ยวกับการพยายามเข้าถึงทั้งหมด

SELinux ได้รับการติดตั้งใช้งานเป็นส่วนหนึ่งของเฟรมเวิร์ก Linux Security Module (LSM) ซึ่งรู้จักออบเจ็กต์เคอร์เนลต่างๆ และการดำเนินการที่ละเอียดอ่อน ที่ดำเนินการกับออบเจ็กต์เหล่านั้น เมื่อมีการดำเนินการแต่ละอย่างเหล่านี้ ระบบจะเรียกใช้ฟังก์ชัน Hook ของ LSM เพื่อพิจารณาว่าควรอนุญาตการดำเนินการหรือไม่ โดยอิงตามข้อมูลที่จัดเก็บไว้ในออบเจ็กต์ความปลอดภัยแบบทึบแสง SELinux มีการติดตั้งใช้งานสำหรับ Hook เหล่านี้และการจัดการออบเจ็กต์ความปลอดภัยเหล่านี้ ซึ่งรวมกับนโยบายของตัวเองเพื่อกำหนดการตัดสินใจเกี่ยวกับการเข้าถึง

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

ใน Android 4.3 ขึ้นไป SELinux จะมีการควบคุมการเข้าถึงที่จำเป็น (MAC) ครอบคลุมสภาพแวดล้อมการควบคุมการเข้าถึงแบบไม่บังคับ (DAC) แบบเดิม เช่น โดยปกติแล้วซอฟต์แวร์ต้องทำงานในฐานะบัญชีผู้ใช้รากเพื่อเขียนไปยังอุปกรณ์บล็อกดิบ ในสภาพแวดล้อม Linux แบบ DAC แบบดั้งเดิม หากผู้ใช้รากถูกบุกรุก ผู้ใช้ดังกล่าวจะเขียนไปยังอุปกรณ์จัดเก็บบล็อกขัอมูลดิบทุกเครื่องได้ อย่างไรก็ตาม คุณสามารถใช้ SELinux เพื่อติดป้ายกำกับอุปกรณ์เหล่านี้เพื่อให้กระบวนการที่ได้รับสิทธิ์ระดับรูท เขียนได้เฉพาะอุปกรณ์ที่ระบุไว้ในนโยบายที่เกี่ยวข้องเท่านั้น ด้วยวิธีนี้ กระบวนการจึงเขียนทับข้อมูลและการตั้งค่าระบบภายนอก อุปกรณ์บล็อกดิบที่เฉพาะเจาะจงไม่ได้

ดูตัวอย่างเพิ่มเติมเกี่ยวกับภัยคุกคามและวิธีจัดการภัยคุกคามเหล่านั้นด้วย SELinux ได้ที่กรณีการใช้งาน

ระดับการบังคับใช้

SELinux สามารถใช้งานได้ในโหมดต่างๆ ดังนี้

• อนุญาต - ไม่มีการบังคับใช้นโยบายความปลอดภัยของ SELinux แต่จะมีการบันทึกเท่านั้น
• การบังคับใช้ - มีการบังคับใช้นโยบายความปลอดภัยและบันทึก ความล้มเหลว จะปรากฏเป็นข้อผิดพลาด EPERM

ตัวเลือกนี้เป็นแบบไบนารีและกำหนดว่านโยบายจะดำเนินการหรือไม่ หรือเพียง อนุญาตให้คุณรวบรวมข้อผิดพลาดที่อาจเกิดขึ้น โดยเฉพาะอย่างยิ่งในช่วงการติดตั้งใช้งาน

ประเภท แอตทริบิวต์ และกฎ

Android ใช้คอมโพเนนต์การบังคับใช้ประเภท (TE) ของ SELinux สำหรับนโยบาย ซึ่งหมายความว่าออบเจ็กต์ทั้งหมด (เช่น ไฟล์ กระบวนการ หรือซ็อกเก็ต) จะมีประเภทที่เชื่อมโยงอยู่ด้วย เช่น โดยค่าเริ่มต้น แอป จะมีประเภท untrusted_app สำหรับกระบวนการ ประเภทของกระบวนการยังเป็นที่รู้จักในชื่อโดเมนของกระบวนการด้วย คุณสามารถใส่คำอธิบายประกอบประเภทด้วยแอตทริบิวต์อย่างน้อย 1 รายการ แอตทริบิวต์มีประโยชน์ในการอ้างอิงถึงหลายประเภท พร้อมกัน

ออบเจ็กต์จะแมปกับคลาส (เช่น ไฟล์ ไดเรกทอรี ลิงก์สัญลักษณ์ ซ็อกเก็ต) และการเข้าถึงประเภทต่างๆ สำหรับแต่ละคลาสจะแสดงด้วยสิทธิ์ เช่น สิทธิ์ open มีอยู่สำหรับคลาส file แม้ว่าประเภทและแอตทริบิวต์จะได้รับการอัปเดตเป็นประจำซึ่งเป็นส่วนหนึ่งของ นโยบาย SELinux ของ Android แต่สิทธิ์และคลาสจะได้รับการกำหนดแบบคงที่และ ไม่ค่อยได้รับการอัปเดตซึ่งเป็นส่วนหนึ่งของการเปิดตัว Linux เวอร์ชันใหม่

กฎของนโยบายมีรูปแบบดังนี้ allow source target:class permissions; โดยที่

• แหล่งที่มา - ประเภท (หรือแอตทริบิวต์) ของเรื่องของกฎ ใครเป็นผู้ขอ สิทธิ์เข้าถึง
• เป้าหมาย - ประเภท (หรือแอตทริบิวต์) ของออบเจ็กต์ ขอสิทธิ์เข้าถึง อะไร
• คลาส - ประเภทของออบเจ็กต์ (เช่น ไฟล์ ซ็อกเก็ต) ที่กำลังเข้าถึง
• สิทธิ์ - การดำเนินการ (หรือชุดการดำเนินการ) (เช่น อ่าน เขียน) ที่กำลังดำเนินการ

ตัวอย่างกฎมีดังนี้

allow untrusted_app app_data_file:file { read write };

ซึ่งระบุว่าแอปได้รับอนุญาตให้อ่านและเขียนไฟล์ที่มีป้ายกำกับ app_data_file แอปมีประเภทอื่นๆ ด้วย เช่น isolated_app ใช้สำหรับบริการแอปที่มี isolatedProcess=true ในไฟล์ Manifest Android จะใช้แอตทริบิวต์ชื่อ appdomain สำหรับประเภททั้งหมดที่ครอบคลุมแอปแทนการทำซ้ำกฎสำหรับทั้ง 2 ประเภท

# Associate the attribute appdomain with the type untrusted_app.
typeattribute untrusted_app appdomain;

# Associate the attribute appdomain with the type isolated_app.
typeattribute isolated_app appdomain;

allow appdomain app_data_file:file { read write };

เมื่อเขียนกฎที่ระบุชื่อแอตทริบิวต์ ระบบจะขยายชื่อนั้นโดยอัตโนมัติไปยังรายการโดเมนหรือประเภทที่เชื่อมโยงกับแอตทริบิวต์ แอตทริบิวต์ที่โดดเด่นบางรายการมีดังนี้

• domain - แอตทริบิวต์ที่เชื่อมโยงกับกระบวนการทุกประเภท
• file_type - แอตทริบิวต์ที่เชื่อมโยงกับไฟล์ทุกประเภท

มาโคร

สำหรับสิทธิ์เข้าถึงไฟล์โดยเฉพาะ มีสิทธิ์หลายประเภทที่ ควรพิจารณา เช่น สิทธิ์ read ไม่เพียงพอที่จะเปิดไฟล์หรือเรียกใช้ stat ในไฟล์ Android มีชุดมาโครเพื่อจัดการกรณีที่พบบ่อยที่สุดเพื่อลดความซับซ้อนของคำจำกัดความของกฎ ตัวอย่างเช่น หากต้องการ รวมสิทธิ์ที่ขาดหายไป เช่น open คุณสามารถเขียนกฎข้างต้นใหม่ได้ดังนี้

allow appdomain app_data_file:file rw_file_perms;

ดูตัวอย่างมาโครที่มีประโยชน์เพิ่มเติมได้ที่ไฟล์ global_macros และ te_macros ควรใช้มาโครทุกครั้งที่ทำได้ เพื่อช่วยลดโอกาสที่จะเกิดข้อผิดพลาดเนื่องจากการปฏิเสธสิทธิ์ที่เกี่ยวข้อง

เมื่อกำหนดประเภทแล้ว คุณจะต้องเชื่อมโยงประเภทดังกล่าวกับไฟล์หรือกระบวนการ ที่แสดง ดูรายละเอียดเพิ่มเติมเกี่ยวกับวิธีเชื่อมโยงได้ที่การใช้งาน SELinux ดูข้อมูลเพิ่มเติมเกี่ยวกับ กฎได้ที่ สมุดบันทึก SELinux

บริบทและหมวดหมู่ด้านความปลอดภัย

เมื่อแก้ไขข้อบกพร่องของนโยบาย SELinux หรือติดป้ายกำกับไฟล์ (โดยใช้ file_contexts หรือ ls -Z) คุณอาจพบบริบทความปลอดภัย (หรือที่เรียกว่าป้ายกำกับ) เช่น u:r:untrusted_app:s0:c15,c256,c513,c768 บริบทด้านความปลอดภัยมีรูปแบบดังนี้ user:role:type:sensitivity[:categories] โดยปกติแล้ว คุณไม่จำเป็นต้องสนใจฟิลด์ user, role และ sensitivity ของบริบท (ดูความเฉพาะเจาะจง) เราได้อธิบายtype ฟิลด์ในส่วนก่อนหน้าแล้ว categories เป็นส่วนหนึ่งของ การรองรับการรักษาความปลอดภัยหลายระดับ (MLS) ใน SELinux ใน Android 12 ขึ้นไป ระบบจะใช้หมวดหมู่เพื่อทำสิ่งต่อไปนี้

• แยกข้อมูลแอปจากการเข้าถึงของแอปอื่น
• แยกข้อมูลแอปจากผู้ใช้จริงรายหนึ่งไปยังอีกรายหนึ่ง

ความเฉพาะเจาะจง

Android ไม่ได้ใช้ฟีเจอร์ทั้งหมดที่ SELinux มีให้ โปรดคำนึงถึงประเด็นต่อไปนี้เมื่ออ่านเอกสารภายนอก

• นโยบายส่วนใหญ่ใน AOSP กำหนดโดยใช้ Kernel Policy Language มีข้อยกเว้นบางประการสำหรับการใช้ Common Intermediate Language (CIL)
• ระบบจะไม่ใช้ผู้ใช้ SELinux ผู้ใช้ที่กำหนดมีเพียง u เมื่อจำเป็น ระบบจะแสดงผู้ใช้จริงโดยใช้ช่องหมวดหมู่ของบริบทความปลอดภัย
• ไม่ได้ใช้บทบาท SELinux และการควบคุมการเข้าถึงตามบทบาท (RBAC) มีการกำหนดและใช้บทบาทเริ่มต้น 2 บทบาท ดังนี้ r สำหรับ Subject และ object_r สำหรับ Object
• ระบบจะไม่ใช้ความละเอียดอ่อนของ SELinux ระบบจะตั้งค่าความไวของ s0 เริ่มต้นเสมอ
• ไม่ได้ใช้บูลีน SELinux เมื่อสร้างนโยบายสำหรับอุปกรณ์ นโยบายจะไม่ขึ้นอยู่กับสถานะของอุปกรณ์ ซึ่งจะช่วยลดความซับซ้อนในการ ตรวจสอบและแก้ไขข้อบกพร่องของนโยบาย