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

สองคุณสมบัติที่ไม่เกี่ยวข้องกัน

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

การอ่านทั้งสองเป็นคุณสมบัติเดียวคือสิ่งที่สร้างทฤษฎีที่ว่าโฮมที่เข้ารหัสขัดขวางการเข้าถึงระดับ root ทฤษฎีนั้นยังคงอยู่เพราะอาการทั้งสองปรากฏบนเครื่องเดียวกัน ไม่ใช่เพราะทั้งสองมีสาเหตุร่วมกัน

สิ่งที่กดการเปลี่ยนผ่านไว้จริง ๆ

เอกสารอ้างอิง execve อธิบายว่าไฟล์ที่เรียกใช้ได้ซึ่งมี set-user-ID เปลี่ยนตัวตนที่มีผลของโปรเซสใหม่เป็นของเจ้าของไฟล์อย่างไร หน้าเดียวกันยังระบุเงื่อนไขที่กดการเปลี่ยนผ่านนั้นและเงื่อนไขที่เทียบเท่าสำหรับตัวระบุกลุ่ม ได้แก่ การตั้งค่า no_new_privs ระบบไฟล์ที่เมานต์ด้วย nosuid และโปรเซสที่ถูกติดตาม ความสามารถของไฟล์จะถูกละเลยภายใต้เงื่อนไขเดียวกัน กฎทั้งสี่ข้อนี้ครอบคลุมรายงานเกือบทุกกรณีในลักษณะนี้

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

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

สิ่งที่ไม่ควรทำ

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

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

ยืนยันบริบทการเรียกใช้จริง

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

จากนั้นยืนยันการทำงานของเครือข่ายที่ตัวช่วยมีไว้เพื่อทำ ตัวช่วยที่เริ่มทำงานได้แต่ กำหนดค่าอินเทอร์เฟซไม่ได้ ได้เลื่อนปัญหาไปอีกขั้นหนึ่ง ไม่ได้แก้ไข

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

บันทึกตัวเลือกการเมานต์และความเป็นเจ้าของของตัวช่วยไว้ในบันทึกเดียวกัน มิฉะนั้นคนถัดไปที่ต้องดีบักเรื่องนี้จะเริ่มทฤษฎีการเข้ารหัสใหม่ตั้งแต่ต้น

บทความที่เกี่ยวข้อง