Дыягностыка адмоваў Squid у SELinux
Адрознівайце правілы доступу Squid, правы файлавай сістэмы, меткі партоў і адмовы палітыкі бяспекі хоста перад змяненнем прымянення.
Адмова ў HTTP-доступе, створаная Squid, і “Permission denied” ад аперацыйнай сістэмы ўзнікаюць на розных межах. Вызначце, ці Squid адкрываў файл, прывязваў сокет, злучаўся вонкі або адхіляў запыт кліента.
Супярэчыце падзею аўдыту
У сістэмах SELinux супастаўце памылку службы з яе запісам аўдыту. Зыходны дамен, тып мэты, клас аб'екта і забаронены дазвол паказваюць, якую аперацыю заблакавала палітыка. Правільнае ўладанне Unix не даказвае, што метка бяспекі слушная.
Карыстальніцкі порт праслухоўвання можа патрабаваць адпаведнай меткі порта. Перамешчаны каталог журналаў або кэша можа патрабаваць маркіроўкі файлаў. Для збою шляху журнала Squid таксама праверце праход па каталогах і правы запісу, перш чым адносіць яго да меткі. Дазвол для незвычайнай знешняй службы — гэта яшчэ адна аперацыя; прыклады Squid SELinux ад Red Hat адрозніваюць гэтыя выпадкі.
Выкарыстоўвайце палітыку ўсталяванага дыстрыбутыва і кіраўніцтва па адміністраванні. Шляхі пакетаў, меткі і абмежаванне могуць адрознівацца паміж вобразамі. У сістэмах з AppArmor правярайце яго профіль замест прымянення каманд SELinux.
Выпраўце палітыку або месца, на якое паказваюць доказы, захоўваючы прымяненне на хосце. Уласная аўтэнтыфікацыя кліентаў і правілы доступу Squid працягваюць дзейнічаць пасля выпраўлення праблемы палітыкі хоста.