แนวคิด SELinux

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

บังคับควบคุมการเข้าออก

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

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

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

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

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

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

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

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

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

ประเภท คุณลักษณะ และกฎเกณฑ์

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

อ็อบเจ็กต์ถูกแมปกับ คลาส (เช่น ไฟล์ ไดเร็กทอรี ลิงก์สัญลักษณ์ ซ็อกเก็ต) และการเข้าถึงประเภทต่างๆ สำหรับแต่ละคลาสจะแสดงด้วย สิทธิ์ ตัวอย่างเช่น สิทธิ์ที่ open อยู่สำหรับ file คลาส แม้ว่าประเภทและแอตทริบิวต์จะได้รับการอัปเดตเป็นประจำโดยเป็นส่วนหนึ่งของนโยบาย Android SELinux แต่การอนุญาตและคลาสจะได้รับการกำหนดแบบคงที่และไม่ค่อยได้รับการอัปเดตเนื่องจากเป็นส่วนหนึ่งของการเปิดตัว 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 สำหรับทุกประเภทที่ครอบคลุมแอป:

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