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