SELinux के अंतर्गत Squid अस्वीकृतियों का निदान

Squid द्वारा उत्पन्न HTTP पहुँच अस्वीकृति और ऑपरेटिंग सिस्टम का “Permission denied” भिन्न सीमाओं पर होते हैं। निर्धारित करें कि Squid फ़ाइल खोल रहा था, सॉकेट बाँध रहा था, बाहर जुड़ रहा था या क्लाइंट अनुरोध अस्वीकार कर रहा था।

ऑडिट घटना को सहसंबंधित करें

SELinux सिस्टम पर, सेवा त्रुटि को उसके ऑडिट रिकॉर्ड से मिलाएँ। स्रोत डोमेन, लक्ष्य प्रकार, ऑब्जेक्ट वर्ग और अस्वीकृत अनुमति दिखाते हैं कि नीति ने कौन-सा संचालन अवरुद्ध किया। सही Unix स्वामित्व यह सिद्ध नहीं करता कि सुरक्षा लेबल उपयुक्त है।

कस्टम सुनने वाले पोर्ट को संबंधित पोर्ट लेबल की आवश्यकता हो सकती है। स्थानांतरित लॉग या कैश निर्देशिका को फ़ाइल लेबलिंग की आवश्यकता हो सकती है। Squid लॉग-पथ विफलता के लिए, लेबल को दोष देने से पहले निर्देशिका ट्रैवर्सल और लेखक अनुमतियाँ भी जाँचें। असामान्य बाहरी सेवा की अनुमति फिर से एक और संचालन है; Red Hat के Squid SELinux उदाहरण इन मामलों में अंतर करते हैं।

स्थापित वितरण की नीति और प्रशासन मार्गदर्शन का उपयोग करें। पैकेज पथ, लेबल और निरोध इमेजों के बीच भिन्न हो सकते हैं। AppArmor वाले सिस्टम पर SELinux कमांड लागू करने के बजाय उसकी प्रोफ़ाइल जाँचें।

साक्ष्य द्वारा इंगित नीति या स्थान को सुधारें, जबकि होस्ट प्रवर्तन बनाए रखें। होस्ट-नीति समस्या ठीक होने के बाद भी Squid का अपना क्लाइंट प्रमाणीकरण और पहुँच नियम लागू रहते हैं।