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