Ինչու VPN վկայագրի տեղափոխումը կոտրում է նրա SELinux պիտակը

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

Ինչ է իրականում անում վերանվանումը պիտակի հետ

Ֆայլը կրում է իր SELinux համատեքստը որպես inode-ին կցված ատրիբուտային տվյալներ։ Մեկ ֆայլային համակարգի ներսում վերանվանումը փոխում է գրացուցակի գրառումը և ուրիշ ոչինչ, ինչը արագ և ատոմային է, և դա է պատճառը, որ համատեքստը վերապրում է տեղափոխումը։ Ոչ մի քաղաքականություն չի հարցվում, ոչ մի լռելյայն չի կիրառվում, և ոչ մի նախազգուշացում չի տպվում։

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

Ֆայլային համակարգերի միջև տեղափոխումները վերադառնում են պատճենման իմաստաբանությանը, ուստի նույն հրամանը կարող է տարբեր կերպ վարվել երկու մեքենաներում՝ կախված նրանից, թե արդյոք /etc գտնվում է իր առանձին ծավալի վրա։ Ստուգեք դա նախքան եզրակացնելը, որ գործիքը անվստահելի է։ Մեկ հայացքը mount աղյուսակին ձեզ կասի, թե ինչ տեսակի տեղափոխում եք կատարել։

Կարդացեք ընթացիկ պիտակը սպասվողի դիմաց

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

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

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

Վերականգնեք քարտեզագրումը՝ բացառություն հորինելու փոխարեն

Ստանդարտ տեղակայման համար քաղաքականությունն արդեն քարտեզագրում է ուղին, ուստի restorecon կիրառում է այն, և գործն ավարտված է։ Շրջանակը պահեք ձեր վերանորոգվող գրացուցակում. ամբողջ ֆայլային համակարգի վերապիտակավորումը դանդաղ է, խափանող, և այն թաղում է սկզբնական սխալը շատ մեծ փոփոխության տակ։

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

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

Ինչու chcon-ը լուծում չէ

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

Ավելի վատ, այն սովորեցնում է սխալ դաս. հիմքում ընկած քարտեզագրումը դեռ բացակայում է, ուստի խափանումը վերադառնում է շաբաթներ անց՝ առանց ակնհայտ խթանի և առանց այդ շրջանցման հիշողության։ Օգտագործեք chcon-ը միայն որպես ժամանակավոր փորձ՝ վարկածը հաստատելու համար, ապա փոխարինեք այն քարտեզագրմամբ, որը վերապրում է հաջորդ վերապիտակավորումը, և ստուգեք, որ փոխարինումն իսկապես տեղում է։

Երբ պիտակը ճիշտ է, և հասանելիությունը դեռ ձախողվում է

Սկսեք ծնող գրացուցակներից։ Անցման թույլտվությունը ստուգվում է ուղու յուրաքանչյուր բաղադրիչի վրա, ուստի ճիշտ պիտակավորված վկայագիրը գրացուցակում, որտեղ ծառայությունը չի կարող մտնել, մնում է անընթեռնելի։ Թե՛ SELinux-ը, թե՛ սովորական թույլտվությունը պետք է թույլատրեն յուրաքանչյուր քայլ, և մեկը շտկելը չի շտկում մյուսը։

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

Հիշեք, որ dontaudit կանոնները կարող են ճնշել մերժման հաղորդագրությունները, ուստի դատարկ աուդիտի մատյանը թույլ ապացույց է, ոչ թե ապացույց։ Եթե քաղաքականությունը ճիշտ է թվում, և հասանելիությունը դեռ ձախողվում է, ուսումնասիրեք նախքան լայն թույլտվության մոդուլ ստեղծելը, և մի անջատեք SELinux-ը՝ ախտանիշը վերացնելու համար։ Երկու կարճ ուղիներն էլ տալիս են համակարգ, որը թվում է, թե աշխատում է, և անվտանգության դիրքորոշում, որը ոչ ոք չի կարող նկարագրել։ Կարճ ուսումնասիրությունը լավ է երկուսից էլ։