Дијагностика на одбивањата на Squid под SELinux
Разликувајте ги правилата за пристап на Squid, дозволите на датотечниот систем, ознаките на портите и одбивањата на безбедносната политика на домаќинот пред да го промените спроведувањето.
Одбивањето на HTTP пристап што го создава Squid и “Permission denied” на оперативниот систем се јавуваат на различни граници. Утврдете дали Squid отворал датотека, врзувал сокет, се поврзувал нанадвор или одбивал барање на клиент.
Поврзете го настанот од ревизијата
На SELinux системи, усогласете ја грешката на услугата со нејзиниот запис од ревизија. Изворниот домен, типот на целта, класата на објектот и одбиената дозвола покажуваат која операција политиката ја блокирала. Правилното Unix сопственост не докажува дека безбедносната ознака е соодветна.
Прилагодената порта за слушање може да бара соодветна ознака на порта. Преместен директориум за дневник или кеш може да бара означување на датотеки. За неуспех на патеката за дневник на Squid, проверете и премин низ директориуми и дозволи за пишување пред да го припишете на ознака. Дозволата за невообичаена излезна услуга е повторно друга операција; примерите Squid SELinux на Red Hat ги разликуваат овие случаи.
Користете ја политиката на инсталираната дистрибуција и административните упатства. Патеките на пакетите, ознаките и ограничувањето може да се разликуваат меѓу сликите. На системи со AppArmor, прегледајте го неговиот профил наместо да применувате SELinux команди.
Поправете ја политиката или локацијата што ја посочуваат доказите, задржувајќи го спроведувањето на домаќинот. Сопствената автентикација на клиенти и правилата за пристап на Squid сè уште важат откако проблемот со политиката на домаќинот е решен.