Squid-ի մերժումների ախտորոշումը SELinux-ում

Squid-ի կողմից ստեղծված HTTP մուտքի մերժումը և օպերացիոն համակարգի “Permission denied”-ը տեղի են ունենում տարբեր սահմաններում։ Որոշեք՝ Squid-ը բացում էր ֆայլ, կապում էր սոքեթ, միանում էր դուրս, թե մերժում էր հաճախորդի հարցումը։

Կապակցեք աուդիտի իրադարձությունը

SELinux համակարգերում համապատասխանեցրեք ծառայության սխալը նրա աուդիտի գրառմանը։ Աղբյուրի դոմենը, թիրախի տեսակը, օբյեկտի դասը և մերժված թույլտվությունը ցույց են տալիս, թե որ գործողությունն արգելափակեց քաղաքականությունը։ Unix-ի ճիշտ սեփականությունը չի ապացուցում, որ անվտանգության պիտակը համապատասխան է։

Հատուկ լսող պորտը կարող է պահանջել համապատասխան պորտի պիտակ։ Տեղափոխված մատյանների կամ քեշի պանակը կարող է պահանջել ֆայլերի պիտակավորում։ Squid-ի մատյանի ուղու ձախողման դեպքում ստուգեք նաև պանակներով անցումը և գրողի թույլտվությունները՝ նախքան այն պիտակին վերագրելը։ Անսովոր արտահոսող ծառայության թույլտվությունը կրկին այլ գործողություն է. Red Hat-ի Squid SELinux օրինակները տարբերում են այս դեպքերը։

Օգտագործեք տեղադրված տարածման քաղաքականությունը և կառավարման ուղեցույցը։ Փաթեթների ուղիները, պիտակները և սահմանափակումը կարող են տարբերվել պատկերների միջև։ AppArmor օգտագործող համակարգերում ուսումնասիրեք դրա պրոֆիլը՝ SELinux հրամաններ կիրառելու փոխարեն։

Ուղղեք ապացույցների մատնանշած քաղաքականությունը կամ տեղը՝ պահպանելով հոսթի կատարումը։ Squid-ի սեփական հաճախորդի նույնականացումը և մուտքի կանոնները գործում են նաև հոսթի քաղաքականության խնդիրը շտկելուց հետո։