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

อ่านหน้านี้เพื่อทำความคุ้นเคยกับแนวคิด SELinux

การควบคุมการเข้าถึงแบบบังคับ

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

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

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

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

ดูตัวอย่างภัยคุกคามและวิธีจัดการภัยคุกคามด้วย SELinux ได้ที่Use Case

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

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

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

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

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

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