อ่านหน้านี้เพื่อทำความคุ้นเคยกับแนวคิด SELinux
การควบคุมการเข้าถึงที่จำเป็น
Security Enhanced Linux (SELinux) เป็นระบบควบคุมการเข้าถึง (MAC) ที่บังคับ สำหรับระบบปฏิบัติการ Linux สำหรับระบบ MAC จะแตกต่างจาก ระบบควบคุมการเข้าถึง (DAC) ที่คุ้นเคย ในระบบ DAC แนวคิด การเป็นเจ้าของอยู่ โดยเจ้าของทรัพยากรหนึ่งๆ ควบคุมการเข้าถึง ที่เกี่ยวข้อง ซึ่งมักจะเป็นเนื้อหาแบบหยาบๆ และหัวข้อ ไปจนถึงการโจมตีเพื่อยกระดับสิทธิ์โดยไม่ตั้งใจ แต่ระบบ MAC จะปรึกษาหารือกับผู้ดูแลระบบ มีอำนาจตัดสินเกี่ยวกับการพยายามเข้าถึงทั้งหมด
SELinux ถูกนำมาใช้เป็นส่วนหนึ่งของโมดูลความปลอดภัย Linux (LSM) ที่จดจำออบเจ็กต์เคอร์เนลต่างๆ และการกระทำที่มีความละเอียดอ่อน เขาทำกับสิ่งนั้น เมื่อถึงจุดที่การกระทำแต่ละอย่างจะเกิดขึ้น จะมีการเรียกใช้ฟังก์ชันฮุก LSM เพื่อพิจารณาว่า ควรอนุญาตการทำงานตามข้อมูลที่เก็บไว้ในส่วนทึบแสง ออบเจ็กต์ความปลอดภัย SELinux นำเสนอการติดตั้งสำหรับฮุกเหล่านี้และ ของออบเจ็กต์ความปลอดภัยเหล่านี้ รวมกับนโยบายของตัวเอง ในการตัดสินใจเรื่องการเข้าถึง
นอกเหนือจากมาตรการรักษาความปลอดภัยอื่นๆ ของ Android การควบคุมการเข้าถึงของ Android นโยบายจะจำกัดความเสียหาย ที่อาจเกิดขึ้นจากเครื่องคอมพิวเตอร์ที่ถูกบุกรุกได้อย่างมาก บัญชี การใช้เครื่องมือ เช่น การเข้าถึงที่จำเป็นและการพิจารณาตามที่เห็นสมควรของ Android การควบคุมช่วยให้คุณมีโครงสร้างที่มั่นใจได้ว่าซอฟต์แวร์ของคุณจะทำงานได้อย่างน้อยที่สุด ระดับสิทธิ์ ซึ่งจะช่วยลดผลกระทบจากการโจมตีและลด แนวโน้มที่จะมีกระบวนการที่ผิดพลาดในการเขียนทับหรือส่งข้อมูล
ใน Android 4.3 ขึ้นไป SELinux มีการควบคุมการเข้าถึง (MAC) ที่บังคับ ครอบคลุมสภาพแวดล้อมการควบคุมการเข้าถึง (DAC) ตามปกติแบบดั้งเดิม สำหรับ ตัวอย่างเช่น ซอฟต์แวร์มักจะทำงานเป็นบัญชีผู้ใช้ระดับรูทเพื่อเขียนลงในไฟล์ข้อมูล RAW บล็อกอุปกรณ์ ในระบบ Linux แบบเดิมที่ใช้ DAC หากผู้ใช้ระดับรูท ถูกบุกรุกโดยที่ผู้ใช้สามารถเขียนไปยังอุปกรณ์ที่บล็อกข้อมูลดิบได้ทั้งหมด อย่างไรก็ตาม สามารถใช้ SELinux เพื่อติดป้ายกำกับอุปกรณ์เหล่านี้เพื่อให้กระบวนการกำหนดราก สิทธิ์สามารถเขียนถึงเฉพาะผู้ที่ระบุในนโยบายที่เกี่ยวข้อง ด้วยวิธีนี้ กระบวนการจะไม่สามารถเขียนทับข้อมูลและการตั้งค่าระบบภายนอก อุปกรณ์บล็อกข้อมูลดิบที่เฉพาะเจาะจง
ดูกรณีการใช้งาน เพื่อดูตัวอย่างภัยคุกคามเพิ่มเติมและวิธีจัดการกับ SELinux
ระดับการบังคับใช้
SELinux สามารถนำมาใช้ได้ในโหมดต่างๆ ดังนี้
- อนุญาต - ไม่ได้บังคับใช้นโยบายความปลอดภัยของ SELinux จะได้รับการบันทึกเท่านั้น
- การบังคับใช้ - ระบบจะบังคับใช้และบันทึกนโยบายความปลอดภัย ความล้มเหลว ปรากฏเป็นข้อผิดพลาด EPERM
ตัวเลือกนี้เป็นแบบไบนารีและกำหนดว่านโยบายของคุณจะดำเนินการหรือ จะช่วยคุณรวบรวมข้อผิดพลาดที่อาจเกิดขึ้น การอนุญาตจะมีประโยชน์อย่างยิ่งในระหว่าง การใช้งานของคุณ
ประเภท แอตทริบิวต์ และกฎ
Android ใช้คอมโพเนนต์ Type Enforcement (TE) ของ SELinux สำหรับ
ซึ่งหมายความว่าออบเจ็กต์ทั้งหมด (เช่น ไฟล์ กระบวนการ หรือซ็อกเก็ต) มี
type ที่เกี่ยวข้องกัน เช่น โดยค่าเริ่มต้น แอป
จะเป็นประเภท untrusted_app สำหรับกระบวนการ ประเภทกระบวนการคือ
ซึ่งเรียกว่าโดเมน คุณสามารถใส่คำอธิบายประกอบประเภทด้วย 1 หรือ
attributes จำนวนมาก แอตทริบิวต์มีประโยชน์ในการอ้างอิงถึงหลายประเภท
ไปพร้อมๆ กัน
จับคู่ออบเจ็กต์กับ classes แล้ว
(เช่น ไฟล์ ไดเรกทอรี ลิงก์สัญลักษณ์ ซ็อกเก็ต) และการเข้าถึงประเภทต่างๆ
สำหรับแต่ละชั้นเรียนจะแทนด้วยสิทธิ์
เช่น สิทธิ์ 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 แทนที่จะแสดงองค์ประกอบ
กฎสำหรับทั้ง 2 ประเภท Android จะใช้แอตทริบิวต์ชื่อ appdomain
สำหรับเนื้อหาทุกประเภทที่ครอบคลุมแอป
# 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 Notebook
บริบทและหมวดหมู่ด้านความปลอดภัย
เมื่อแก้ไขข้อบกพร่องนโยบาย SELinux หรือไฟล์ติดป้ายกำกับ (ผ่าน
file_contexts หรือเมื่อป้อน ls -Z) คุณอาจเข้าร่วม
ในบริบทด้านความปลอดภัย (หรือเรียกอีกอย่างว่าป้ายกำกับ) สำหรับ
ตัวอย่าง:
u:r:untrusted_app:s0:c15,c256,c513,c768 บริบทด้านความปลอดภัยจะมีรูปแบบดังนี้
user:role:type:sensitivity[:categories] โดยปกติแล้วคุณสามารถข้าม
user, role และ sensitivity ของ
บริบท (ดูความจำเพาะ) type
มีการอธิบายไว้ในส่วนก่อนหน้านี้ categories เป็นส่วนหนึ่งของ
การรักษาความปลอดภัยแบบหลายระดับ (Multi-Level Security หรือ MLS)
สนับสนุนใน SELinux เนื่องจาก Android S จะมีการใช้หมวดหมู่เพื่อทำสิ่งต่อไปนี้
- แยกข้อมูลแอปออกจากการเข้าถึงโดยแอปอื่น
- แยกข้อมูลแอปจากผู้ใช้จริงรายหนึ่งไปยังผู้ใช้อีกราย
ลักษณะเฉพาะ
Android ไม่ได้ใช้ฟีเจอร์ทั้งหมดจาก SELinux เมื่ออ่าน ในเอกสารภายนอก โปรดจดจำประเด็นต่อไปนี้
- นโยบายส่วนใหญ่ใน AOSP กำหนดโดยใช้ภาษาของนโยบายเคอร์เนล การใช้ Common Intermediate Language (CIL) มีข้อยกเว้นบางประการ
- ไม่ได้ใช้ผู้ใช้ SELinux ผู้ใช้ที่กำหนดไว้เพียง 1 รายคือ
uหากจำเป็น ระบบจะแสดงผู้ใช้จริงโดยใช้ช่องหมวดหมู่ของบริบทด้านความปลอดภัย - ไม่ได้ใช้บทบาทของ SELinux และการควบคุมการเข้าถึงตามบทบาท (RBAC) มีการกำหนดและใช้บทบาทเริ่มต้น 2 บทบาท ดังนี้
rสำหรับวัตถุและobject_rสำหรับวัตถุ - ไม่ได้ใช้ความไวของ SELinux ตั้งค่าความไวต่อ
s0เริ่มต้นไว้เสมอ - ไม่ได้ใช้บูลีน SELinux เมื่อสร้างนโยบาย นโยบายสำหรับอุปกรณ์ ไม่ได้ขึ้นอยู่กับสถานะของอุปกรณ์ ซึ่งช่วยลดความซับซ้อนของ การตรวจสอบและการแก้ไขข้อบกพร่องของนโยบาย