root ในเทอร์มินัล ถูกปฏิเสธภายใต้ SELinux: ทำไม hook จึงล้มเหลว

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

คำสั่งเดียวกัน สองโดเมนความปลอดภัยที่ต่างกัน

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

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

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

อ่านบันทึก AVC ข้างข้อผิดพลาดของ hook

การปฏิเสธ AVC ระบุฟิลด์ที่ตัดสินคดี ได้แก่ บริบทต้นทางของโปรเซส บริบทปลายทางของออบเจกต์ คลาสของออบเจกต์ และสิทธิ์เฉพาะที่ถูกปฏิเสธ อ่านทั้งสี่ก่อนสร้างทฤษฎี เพราะการปฏิเสธการเรียกใช้และการปฏิเสธการเขียนมีการซ่อมแซมที่ต่างกันโดยสิ้นเชิง

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

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

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

ป้ายกำกับ การกำหนดค่าหรือนโยบาย: การซ่อมแซมสามแบบ

การซ่อมแซมแบบแรกคือป้ายกำกับที่ไม่ตรงกับตำแหน่งที่ติดตั้งของไฟล์ สคริปต์ที่คัดลอกไปยังที่ของมันด้วย cp หรือเขียนด้วยโปรแกรมแก้ไขอาจมีป้ายกำกับเริ่มต้นที่โดเมนของบริการใช้ไม่ได้ และการคืนบริบทที่คาดหวังก็แก้ไขได้โดยไม่ต้องแตะนโยบายเลย

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

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

ทำไมมอดูล allow เก่าไม่ใช่คำตอบ

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

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

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