โปรดอ่านหน้านี้เพื่อให้คุ้นเคยกับแนวคิดของ 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 เมื่อสร้างนโยบายสำหรับอุปกรณ์ นโยบายจะไม่ขึ้นอยู่กับสถานะของอุปกรณ์ ซึ่งจะช่วยให้การตรวจสอบและการแก้ไขข้อบกพร่องของนโยบายง่ายขึ้น