แนวคิดของ SELinux

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

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

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

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

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

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

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

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

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

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

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

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

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