Diagnozowanie odmów Squida w systemie SELinux
Rozróżnij reguły dostępu Squida, uprawnienia systemu plików, etykiety portów i odmowy polityki bezpieczeństwa hosta, zanim zmienisz egzekwowanie.
Odmowa dostępu HTTP generowana przez Squida i komunikat “Permission denied” systemu operacyjnego występują na różnych granicach. Ustal, czy Squid otwierał plik, wiązał gniazdo, łączył się na zewnątrz czy odrzucał żądanie klienta.
Skoreluj zdarzenie audytu
W systemach SELinux dopasuj błąd usługi do jej rekordu audytu. Domena źródłowa, typ docelowy, klasa obiektu i odmówione uprawnienie pokazują, którą operację zablokowała polityka. Prawidłowa własność w Unixie nie dowodzi, że etykieta bezpieczeństwa jest odpowiednia.
Niestandardowy port nasłuchujący może wymagać odpowiedniej etykiety portu. Przeniesiony katalog dzienników lub pamięci podręcznej może wymagać etykietowania plików. W przypadku błędu ścieżki dziennika Squida sprawdź także przechodzenie katalogów i uprawnienia zapisu, zanim przypiszesz go etykiecie. Uprawnienie dla nietypowej usługi wychodzącej to znów inna operacja; przykłady Squid SELinux firmy Red Hat rozróżniają te przypadki.
Użyj polityki zainstalowanej dystrybucji i wskazówek administracyjnych. Ścieżki pakietów, etykiety i ograniczenia mogą się różnić między obrazami. W systemach z AppArmor sprawdź jego profil zamiast stosować polecenia SELinux.
Popraw politykę lub lokalizację wskazaną przez dowody, zachowując egzekwowanie na hoście. Uwierzytelnianie klientów i reguły dostępu samego Squida nadal obowiązują po naprawieniu problemu z polityką hosta.