การวินิจฉัยการปฏิเสธของ Squid ภายใต้ SELinux

การปฏิเสธการเข้าถึง HTTP ที่สร้างโดย Squid และ “Permission denied” ของระบบปฏิบัติการเกิดขึ้นที่ขอบเขตที่ต่างกัน ระบุว่า Squid กำลังเปิดไฟล์ ผูกซ็อกเก็ต เชื่อมต่อออกภายนอก หรือปฏิเสธคำขอของไคลเอนต์

เชื่อมโยงเหตุการณ์การตรวจสอบ

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

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

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

แก้ไขนโยบายหรือตำแหน่งที่หลักฐานชี้ให้เห็นโดยยังคงการบังคับใช้บนโฮสต์ การยืนยันตัวตนไคลเอนต์และกฎการเข้าถึงของ Squid เองยังคงมีผลหลังแก้ไขปัญหานโยบายของโฮสต์แล้ว