chroot-ը ձախողվում է OpenVPN-ում. AppArmor-ի կանոն, թե՞ հնարավորություն

Դեմոնը գրանցում է chroot-ի ձախողում, և պրոֆիլն արդեն առատաձեռն է թվում, ուստի գրավիչ լուծումը ուղու կանոնը լայնացնելն ու վերսկսելն է։ Սովորաբար դա ոչինչ չի փոխում, քանի որ chroot-ը պաշտպանված է արտոնությամբ, որը պրոֆիլը երբեք չէր կարող փոխանցել։ Որոշելու համար, թե որ շերտին դիպչել, պետք է երեք ստուգում, և դրանք էժան են. ինչ թույլատրվում է պահել գործընթացին, ինչ է թույլատրում քաղաքականությունը, և ինչ է հեռացրել գործարկիչը նախքան այդ երկուսից որևէ մեկի նշանակությունը։

Երկու առանձին դարպաս, և միայն մեկն է պատկանում AppArmor-ին

chroot-ը պահանջում է CAP_SYS_CHROOT այն օգտատիրոջ անվանատարածքում, որտեղ աշխատում է գործընթացը։ Դա սովորական Linux արտոնություն է, և միջուկը ստուգում է այն նախքան կանչը որևէ բան կանի ուղիների հետ։ Առանձին, պարտադրող AppArmor-ի պրոֆիլը կարող է մերժել հնարավորությունը նույնիսկ այն դեպքում, երբ գործընթացն ունի այն, քանի որ պարտադիր քաղաքականությունը դիտարկվում է ի հավելումն հավատարմագրերի, ոչ դրանց փոխարեն։ Տարբերությունը գործնականում կարևոր է. երկու շերտերն ապրում են տարբեր ֆայլերում և սովորաբար սպասարկվում են տարբեր մարդկանց կողմից։

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

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

Կարդացեք արտոնության վիճակը նախքան քաղաքականությունը խմբագրելը

Սկսեք աշխատող գործընթացից, ոչ թե այն կազմաձևից, որը համարում եք ակտիվ։ Վիճակի ֆայլը ցույց է տալիս հինգ հնարավորությունների դիմակ և no-new-privileges դրոշը, և դրանք պատասխանում են տարբեր հարցերի.

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff-ը այն բազմությունն է, որը կարևոր է կանչի համար. CapBnd-ում առկա, բայց CapEff-ում բացակայող հնարավորությունը թույլատրված է վերին սահմանով և ներկայումս չի պահվում։ CapAmb-ը կարևոր է, երբ բինարը արտոնյալ չէ սովորական setuid իմաստով, քանի որ շրջակա հնարավորությունները այն միջոցն են, որով ծառայությունը պահում է արտոնությունը exec-ի ընթացքում առանց ֆայլային հնարավորությունների։ CapInh-ը պահում է բիթեր, որոնք կարող են ժառանգվել exec-ի ընթացքում, բայց միայն այն դեպքում, երբ գործարկվող ֆայլի ժառանգելի բազմությունը դա թույլատրում է, այնպես որ այնտեղ մեկ բիթ ինքնին ոչինչ չի տալիս։

Այնուհետև հաստատեք, թե որ պրոֆիլն է իրականում կցված։ Գործընթացը կարող է սահմանափակվել պրոֆիլի անունով, որը չէիք սպասում, հատկապես երբ տարածումը առաքում է իր unit ֆայլը և պրոֆիլը միասին, և /proc/PID/attr/current-ի ընթերցումը դա լուծում է մեկ տողով։ Ձեր խմբագրված ֆայլը միջուկի հաղորդած պրոֆիլի հետ համեմատելը տարբերությունն է պատճառը շտկելու և ոչ ոքի չբեռնվող ֆայլ խմբագրելու միջև։

Ավելացրեք հնարավորության կանոնը միայն այն դեպքում, երբ աուդիտի հետքը դա է ասում

Միջուկի և աուդիտի գրառումները նշում են մերժող շերտը։ Փնտրեք մերժում, որը կրում է capable գործողությունը և sys_chroot անունը՝ դրանք առաջացրած պրոֆիլի հետ միասին։ Եթե այդպիսի գրառում կա, գործընթացն արդեն պահում էր հնարավորությունը, և AppArmor-ը մերժել է այն, իսկ նպատակային փոփոխությունը իրական պրոֆիլի ներսում հնարավորության կանոնն է.

capability sys_chroot,

Պահեք այն որպես բեկոր այն պրոֆիլում, որն իսկապես կցված է, և ստուգեք բանալի բառը apparmor.d պրոֆիլների տեղեկատուի համաձայն՝ անհամապատասխան ձեռնարկից կանոն պատճենելու փոխարեն։ Ընդհանուր include-ի մեջ դնելը այն տալիս է յուրաքանչյուր սահմանափակված ծրագրի, որը ներգրավում է այդ ֆայլը, իսկ պրոֆիլները բողոքարկման ռեժիմի անցկացնելը թաքցնում է հաջորդ մերժումը՝ այս մեկը լուծելու փոխարեն։ Պրոֆիլի կանոնը հեռացնում է քաղաքականության մերժումը. այն արտոնություն չի ստեղծում, ուստի գործընթացը, որի արդյունավետ բազմությունում երբեք չի եղել CAP_SYS_CHROOT, կանոնի առկայությամբ էլ կձախողվի։

Եթե աուդիտի գրառումը ընդհանրապես AppArmor-ի մերժում չի ցույց տալիս, դադարեցրեք պրոֆիլի խմբագրումը։ Դուք բախվում եք հավատարմագրերի խնդրի հետ, և մնացած աշխատանքը unit ֆայլում կամ մայր գործընթացում է, ոչ քաղաքականության լեզվում։

Ծառայությունների կառավարիչը պահում է իր սեփական վերին սահմանը

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

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

Հերթականությունն այստեղ նույնպես կարևոր է։ Նախ փոխեք unit-ի վերին սահմանը, ստուգեք, որ CapEff-ն այժմ պարունակում է բիթը, և միայն դրանից հետո որոշեք՝ արդյոք AppArmor-ը դեռ մերժում է։ Երկու փոփոխությունները միաժամանակ անելը ձեզ նորից գուշակության մեջ է թողնում, եթե ձախողումը պահպանվի։

Երբ մերժումը վերանա, ստուգեք ինքը՝ բանտը

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

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

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