Диагностика на откази на Squid под SELinux
Разграничете правилата за достъп на Squid, разрешенията на файловата система, етикетите на портовете и отказите на политиката за сигурност на хоста, преди да промените прилагането.
Отказът за HTTP достъп, генериран от Squid, и “Permission denied” от операционната система възникват на различни граници. Определете дали Squid е отварял файл, свързвал сокет, свързвал се навън или е отхвърлял заявка на клиент.
Свържете одитното събитие
В системи със SELinux съпоставете грешката на услугата с нейния одитен запис. Изходният домейн, целевият тип, класът на обекта и отказаното разрешение показват коя операция е блокирана от политиката. Правилното собственичество в Unix не доказва, че етикетът за сигурност е подходящ.
Персонализиран порт за слушане може да изисква съответния етикет на порт. Преместена директория за журнали или кеш може да изисква етикетиране на файлове. При отказ на път за журнал на Squid проверете също обхождането на директории и правата за запис, преди да го припишете на етикет. Разрешението за необичайна изходяща услуга е отново друга операция; примерите на Red Hat за Squid и SELinux разграничават тези случаи.
Използвайте политиката на инсталираната дистрибуция и административното ръководство. Пътищата на пакетите, етикетите и ограничаването могат да се различават между изображенията. В системи с AppArmor инспектирайте неговия профил, вместо да прилагате команди на SELinux.
Коригирайте политиката или местоположението, посочени от доказателствата, като запазите прилагането на хоста. Собствената автентикация на клиенти и правилата за достъп на Squid продължават да важат след отстраняване на проблема с политиката на хоста.