SELinux کے تحت Squid کی مستردگیوں کی تشخیص

Squid کی بنائی ہوئی HTTP رسائی مستردگی اور آپریٹنگ سسٹم کا “Permission denied” مختلف حدود پر واقع ہوتے ہیں۔ طے کریں کہ Squid فائل کھول رہا تھا، ساکٹ باندھ رہا تھا، باہر جڑ رہا تھا یا کلائنٹ کی درخواست مسترد کر رہا تھا۔

آڈٹ واقعے کو باہم مربوط کریں

SELinux نظاموں پر، سروس کی خرابی کو اس کے آڈٹ ریکارڈ سے ملا دیں۔ ماخذ ڈومین، ہدف کی قسم، آبجیکٹ کلاس اور مسترد شدہ اجازت دکھاتے ہیں کہ پالیسی نے کون سی کارروائی روکی۔ درست Unix ملکیت یہ ثابت نہیں کرتی کہ سکیورٹی لیبل مناسب ہے۔

حسبِ ضرورت سننے والا پورٹ متعلقہ پورٹ لیبل کا تقاضا کر سکتا ہے۔ منتقل شدہ لاگ یا کیشے ڈائریکٹری فائل لیبلنگ کا تقاضا کر سکتی ہے۔ Squid کے لاگ راستے کی ناکامی کے لیے، لیبل کو ذمہ دار ٹھہرانے سے پہلے ڈائریکٹری گزر اور لکھنے کی اجازتیں بھی جانچیں۔ غیر معمولی بیرونی سروس کی اجازت پھر ایک اور کارروائی ہے؛ Red Hat کی Squid SELinux مثالیں ان معاملات میں فرق کرتی ہیں۔

نصب شدہ ڈسٹری بیوشن کی پالیسی اور انتظامی رہنمائی استعمال کریں۔ پیکیج راستے، لیبل اور تحدید مختلف امیجز میں مختلف ہو سکتے ہیں۔ AppArmor استعمال کرنے والے نظاموں پر SELinux کمانڈز لاگو کرنے کے بجائے اس کی پروفائل کا معائنہ کریں۔

شواہد کی نشاندہی کردہ پالیسی یا مقام درست کریں، مگر میزبان پر نفاذ برقرار رکھیں۔ میزبان پالیسی کا مسئلہ حل ہونے کے بعد بھی Squid کی اپنی کلائنٹ توثیق اور رسائی قواعد نافذ رہتے ہیں۔