Root-ը տերմինալում, մերժված SELinux-ի ներքո. ինչու է hook-ը ձախողվում

Դուք գործարկում եք up սկրիպտը որպես root, այն ավարտվում է, և նույն սկրիպտը ձախողվում է, երբ ծառայությունը կանչում է այն։ Ֆայլի թույլտվություններից ոչինչ չի փոխվել, ուստի բնական հաջորդ քայլը դրանք նորից թուլացնելն է, ինչը ոչինչ չի ուղղում։ SELinux հոսթում որոշիչ գործոնը հաճախ ոչ թե այն է, թե ով է գործընթացը, այլ այն, թե որ դոմեյնում է այն աշխատում, և root-ը սահմանափակ դոմեյնի ներսում մնում է սահմանափակ։

Նույն հրամանը, երկու տարբեր անվտանգության դոմեյն

Տիպերի պարտադրումը գնահատում է աղբյուրի դոմեյնը, նպատակային պիտակը և պահանջվող գործողությունը միասին։ Ձեր տերմինալի սեսիան աշխատում է չսահմանափակված կամ վարչական դոմեյնում, իսկ դեմոնը աշխատում է այն դոմեյնում, որը վերագրված է իր միավորին։ Այսպիսով նույնական հրամանները տալիս են տարբեր որոշումներ, և տարբերությունը դիտավորյալ է, ոչ թե քաղաքականության սխալ։

Այդ պատճառով երկու գործարկումների համեմատությունը օգտակար է միայն այն դեպքում, երբ համեմատում եք դրանց համատեքստերը։ Գործարկեք նույն հրամանը shell-ից և hook-ից, և shell-ի տարբերակը ապացուցում է, որ բինարը գոյություն ունի և արգումենտները ճիշտ են. այն ոչինչ չի ապացուցում այն մասին, թե արդյոք ծառայությունը իրավունք ունի գործարկել այն։ Գործարկեք երկու եղանակով և համեմատեք դոմեյնները, ոչ միայն ելքի կոդերը։ Հենց այդ համեմատությունն է անորոշ թույլտվության բողոքը դարձնում մեկ դոմեյնի և մեկ պիտակի մասին կոնկրետ հարց։

Այս խափանման դասական ձևը օգնականն է, որը կանչում է արտաքին գործիք։ Ինքը hook-ը կարող է թույլատրված լինել, մինչդեռ այն գործիքը, որը նա կանչում է, կրում է պիտակ, որը ծառայության դոմեյնը չի կարող գործարկել, կամ գրում է գրացուցակում, որի պիտակն արգելում է դա։

Կարդացեք AVC գրառումը hook-ի սխալի կողքին

AVC մերժումը նշում է այն դաշտերը, որոնք որոշում են գործը. գործընթացի աղբյուրի համատեքստը, օբյեկտի նպատակային համատեքստը, օբյեկտի դասը և այն կոնկրետ թույլտվությունը, որը մերժվել է։ Կարդացեք բոլոր չորսը նախքան տեսություն կազմելը, որովհետև կատարման վրա մերժումը և գրառման վրա մերժումը բոլորովին տարբեր ուղղումներ ունեն։

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Աղբյուրի համատեքստը պետք է համապատասխանի այն դոմեյնին, որտեղ ծառայությունն իրականում աշխատում է, իսկ նպատակային համատեքստը՝ այն ֆայլի կամ գրացուցակի պիտակին, որին դիպել է գործողությունը։ Եթե դրանցից որևէ մեկը չի համապատասխանում ձեր հետապնդած սխալին, դուք այլ իրադարձություն եք կարդում։

Գրառման կողքին նշեք քաղաքականության տարբերակը և գործարկվող ֆայլի ճշգրիտ ուղին։ Մեկ դիստրիբուտիվի քաղաքականության մեջ հայտնված դոմեյնի անունը ապացույց է այդ տեղադրման մասին, ոչ թե երաշխիք, որ մեկ այլ կառուցում նույն կանոններն է մատակարարում։ Հենց այդ համատեքստն է թույլ տալիս մեկ ուրիշին վերարտադրել ձեր եզրակացությունը սեփական հոսթում։ Առանց դրա գրառումը կարդացվում է որպես անեկդոտ, ոչ թե ապացույց։

Պիտակ, կոնֆիգուրացիա թե քաղաքականություն. երեք ուղղում

Առաջին ուղղումը պիտակն է, որը չի համապատասխանում ֆայլի տեղադրված վայրին։ cp-ով տեղում պատճենված կամ խմբագրիչով գրված սկրիպտը կարող է կրել լռելյայն պիտակ, որը ծառայության դոմեյնը չի կարող օգտագործել, և սպասվող համատեքստի վերականգնումը դա ուղղում է՝ ընդհանրապես չդիպչելով քաղաքականությանը։

Երկրորդը կոնֆիգուրացիան է։ Դիստրիբուտիվը կարող է տրամադրել գործողությունը գործարկելու աջակցվող եղանակ, փաստաթղթավորված գրացուցակ օգնականի համար կամ թարմացված քաղաքականության փաթեթ, որն արդեն թույլատրում է այն։ Ձեր դասավորությունը աջակցվողին փոխելն ավելի էժան է, քան քաղաքականություն գրելը, և դիմանում է թարմացումներին։

Երրորդն իսկապես բացակայող կանոնն է, և այն պետք է լինի վերջին միջոցը։ Ստեղծեք թեկնածու աուդիտի գործիքներով, կարդացեք, թե ինչ է այն իրականում թույլատրում, նեղացրեք այն ձեր դիտարկած գործողությանը և դոմեյնին, և թող մեկ ուրիշը վերանայի այն նախքան արտադրությանը մոտենալը։

Ինչու հին allow մոդուլը պատասխան չէ

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

Այն նաև թաքցնում է հաջորդ ձախողումը։ Լայն գործողությունների դաս թույլատրող մոդուլը կվերացնի այս սխալը և հաջորդը կդարձնի շատ ավելի դժվար վերագրելի։ Մոդուլը հետագայում հեռացնելը նույնպես փոփոխություն է, որը ոչ ոք չի ուզում պլանավորել, ուստի կարճ ուղին հակված է դառնալ մշտական։

Կարգապահ համեմատությունը ձեր կարդացած մերժման և ձեր առաջարկած փոփոխության միջև է։ Red Hat-ի SELinux-ի խնդիրների լուծման ուղեցույցը պիտակավորման և կոնֆիգուրացիայի ստուգումները դնում է գեներացված քաղաքականությունից առաջ հենց այս պատճառով։ Եթե գրառման մեջ համապատասխան մերժում չկա, ամենայն հավանականությամբ SELinux-ը ձեր խնդիրը չէ, և ուղու, sandbox-ի կամ թույլտվությունների հարցերը դեռ բաց են։