عیب‌یابی ردهای Squid در SELinux
پیش از تغییر اجرا، قواعد دسترسی Squid، مجوزهای فایل‌سیستم، برچسب‌های پورت و ردهای سیاست امنیتی میزبان را از هم تفکیک کنید.
رد دسترسی HTTP که Squid تولید می‌کند و “Permission denied” سیستم‌عامل در مرزهای متفاوتی رخ می‌دهند. مشخص کنید که Squid فایلی را باز می‌کرد، سوکتی را مقید می‌کرد، به بیرون متصل می‌شد یا درخواست کارخواه را رد می‌کرد.
رویداد حسابرسی را هم‌بسته کنید
در سامانه‌های SELinux، خطای سرویس را با رکورد حسابرسی آن تطبیق دهید. دامنه مبدأ، نوع هدف، کلاس شیء و مجوز ردشده نشان می‌دهند کدام عملیات توسط سیاست مسدود شده است. مالکیت درست یونیکس ثابت نمی‌کند که برچسب امنیتی مناسب است.
یک پورت شنود سفارشی ممکن است به برچسب پورت متناظر نیاز داشته باشد. پوشه گزارش یا حافظه نهان جابه‌جاشده ممکن است به برچسب‌گذاری فایل نیاز داشته باشد. برای خطای مسیر گزارش Squid، پیش از نسبت دادن آن به یک برچسب، پیمایش پوشه و مجوزهای نویسنده را نیز بررسی کنید. مجوز برای یک سرویس خروجی نامعمول عملیاتی دیگر است؛ نمونه‌های Squid SELinux شرکت Red Hat این موارد را از هم جدا می‌کنند.
از سیاست توزیع نصب‌شده و راهنمای مدیریت آن استفاده کنید. مسیرهای بسته، برچسب‌ها و محدودسازی می‌توانند میان تصاویر متفاوت باشند. در سامانه‌هایی که AppArmor دارند، به‌جای اجرای فرمان‌های SELinux پروفایل آن را بررسی کنید.
سیاست یا مکانی را که شواهد نشان می‌دهد اصلاح کنید و در همان حال اجرای سیاست میزبان را حفظ کنید. احراز هویت کارخواه و قواعد دسترسی خود Squid پس از رفع مشکل سیاست میزبان نیز پابرجا می‌مانند.