ทำไมการย้ายไฟล์ใบรับรอง VPN จึงทำให้ป้าย SELinux เสียหาย

ใบรับรองสามารถอยู่ในไดเรกทอรีที่ถูกต้องโดยมีโหมดที่อ่านได้และเจ้าของเป็น root และ บริการก็ยังอาจรายงานว่าไม่สามารถเปิดไฟล์ได้ บนระบบ SELinux การรวมกันนั้นชี้ไปที่กลไกหนึ่งโดยเฉพาะ ไม่ใช่ที่สิทธิ์ ป้ายเดินทางไปพร้อมไฟล์ เพราะการเปลี่ยนชื่อไม่ได้สร้างออบเจ็กต์ใหม่ inode ยังคงเก็บบริบทความปลอดภัยที่มีอยู่บนพาธเดิมไว้ และนโยบายสำหรับพาธใหม่ก็ไม่เคยมีโอกาสกำหนดบริบทของตัวเอง

การเปลี่ยนชื่อทำอะไรกับป้ายจริง ๆ

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

การคัดลอกทำงานต่างออกไป สำเนาจะสร้าง inode ใหม่ในไดเรกทอรีปลายทาง และนโยบายกำหนดบริบทตามชนิดของไดเรกทอรีนั้น ใบรับรองที่คัดลอกจึงมักได้ป้ายที่ถูกต้อง ขณะที่ใบรับรองที่ย้ายยังคงผิดอยู่ ความแตกต่างเพียงข้อเดียวนี้อธิบายความสับสนส่วนใหญ่ในตั๋วประเภทนี้

การย้ายข้ามระบบไฟล์จะกลับไปใช้ความหมายของการคัดลอก คำสั่งเดียวกันจึงทำงานต่างกันบนสองเครื่องได้ ขึ้นอยู่กับว่า /etc อยู่บนวอลุ่มของตัวเองหรือไม่ ตรวจสอบเรื่องนี้ก่อนสรุปว่าเครื่องมือไม่น่าเชื่อถือ การดูตาราง mount ครั้งเดียวจะบอกคุณว่าคุณทำการย้ายชนิดใด

อ่านป้ายปัจจุบันเทียบกับป้ายที่คาดไว้

คำสั่งอ่านอย่างเดียวสามคำสั่งตอบคำถามได้โดยไม่เปลี่ยนอะไร คำสั่งแรกแสดงสิ่งที่ไฟล์มีอยู่ตอนนี้ คำสั่งที่สองรายงานว่านโยบายคาดหวังอะไรสำหรับพาธนั้นโดยตรง และคำสั่งที่สามแสดงรายการทุกไฟล์ใต้ไดเรกทอรีที่มีป้ายต่างออกไป

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

จากนั้นเชื่อมโยงความแตกต่างกับการปฏิเสธจริง ความไม่ตรงกันเป็นหลักฐานของป้ายที่ผิด ไม่ใช่หลักฐานว่าบริการล้มเหลวเพราะสิ่งนั้น และการแก้ไขที่ใช้โดยไม่มีการปฏิเสธที่สอดคล้องในบันทึกคือการเดาที่มีขั้นตอนเพิ่ม

คืนค่าการแมปแทนการสร้างข้อยกเว้นขึ้นมา

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

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

ทำไม chcon ไม่ใช่ทางแก้

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

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

เมื่อป้ายถูกต้องแต่การเข้าถึงยังล้มเหลว

เริ่มจากไดเรกทอรีแม่ สิทธิ์ในการผ่านจะถูกตรวจสอบในทุกองค์ประกอบของพาธ ใบรับรองที่ติดป้ายถูกต้องภายในไดเรกทอรีที่บริการเข้าไม่ได้จึงยังอ่านไม่ได้ SELinux และสิทธิ์ปกติต้องอนุญาตทุกขั้นตอน และการแก้ไขอย่างหนึ่งไม่แก้ไขอีกอย่าง

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

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