Արտոնությունների իջեցումից հետո՝ OpenVPN-ի որ ֆայլերն են դեռ աշխատում?
Մինչ իջեցումը բացված դեսկրիպտորները շարունակում են աշխատել, ավելի ուշ նորից բացվող ուղիները՝ ոչ։ Որոշեք, թե երեք գործարկման ֆայլերից որն է ձեր կարգավորումը պետք է նորից բացի։
Երկար աշխատաժամանակը միայն ապացուցում է, որ մեկնարկը հաջողվել է այն արտոնություններով, որոնք դեմոնն ուներ այդ պահին։ Այստեղ կարևոր խափանումները գալիս են ավելի ուշ՝ նոր հաճախորդ է միանում, չեղարկման ցուցակը փոխարինվում է, օժանդակ սկրիպտը պետք է ֆայլ գրի։ Դրանցից յուրաքանչյուրը նոր բացում է, որը կատարում է առանց արտոնությունների հաշիվը՝ իր սեփական թույլտվության հարցով և իր սեփական սխալի հաղորդագրությամբ։ Երեք որոշում բաժանում են շարունակ աշխատող կարգավորումը հաջորդ իրադարձության ժամանակ ձախողվողից։
Առանձնացրեք վաղ բեռնվածը ավելի ուշ բացվողից
Դեսկրիպտորը բացված ֆայլի նկարագրության բռնակ է, և մուտքի ռեժիմը սահմանվել է այդ նկարագրության ստեղծման պահին։ Գործընթացի օգտատիրոջ ավելի ուշ փոփոխությունը բռնակը չի փակում, դրա համար էլ root-ով կարդացված բանալու ֆայլը շարունակում է աշխատել իջեցումից հետո։ Ռեժիմը նույնպես չի փոխվում. ընթերցման համար բացված բռնակը գրելի չի դառնում, իսկ գրելի բռնակը չի չեղարկվում միայն այն պատճառով, որ հաշիվը կորցրել է իր իրավունքները ուղու վրա։ Այս երկու փաստերը բացատրում են այս հաշվետվությունների անսպասելի վարքի մեծ մասը։
Մյուս կեսը հիշողությունն է։ Դեմոնը կարող է վերլուծել վկայականը, պահել վերլուծված նյութը և փակել ֆայլը. օգտագործման մեջ մնում են տվյալները, ոչ բաց ֆայլը։ Ուստի շարունակական երթևեկությունը չի ապացուցում ոչ այն, որ դեսկրիպտորը բաց է, ոչ էլ այն, որ ուղու անունը հասանելի է։ Այն ապացուցում է միայն, որ ընթացիկ նստաշրջանի համար անհրաժեշտ նյութը ձեռք է բերվել ավելի վաղ։
Ավելի ուշ բացումը այլ գործարք է։ Այն ընթանում է ընթացիկ հավատարմագրերով, ընթացիկ անվտանգության համատեքստով և ընթացիկ ամրակցման տեսքով, ուստի մեկնարկի պահին ընթեռնելի ուղին կարող է մերժվել հաջորդ միացման ժամանակ։ Պտույտը թակարդ է ավելացնում. նույն ուղու անվան վրա նոր ֆայլ գրելը թողնում է գոյություն ունեցող դեսկրիպտորը կապված հին օբյեկտին, ուստի վերբեռնումը կարող է հաջող թվալ, մինչ դեմոնը դեռ օգտագործում է նախորդ բովանդակությունը։ Համեմատեք գործընթացի մոտ եղած inode-ը սկավառակի վրա եղածի հետ նախքան պտույտի ուժի մեջ մտնելը հավատալը։
Անվանեք երեք գործարկման ընթերցումները և երբ է տեղի ունենում յուրաքանչյուրը
Երեք ռեսուրս սովորաբար բացվում են նախաձեռնումից շատ ավելի ուշ և ձախողվում են տարբեր պահերի։ Կոնկրետ հաճախորդի կարգավորման ֆայլը կարդացվում է, երբ այդ հաճախորդը միանում է, ուստի այն կարող է կոտրվել մեկ օգտատիրոջ մոտ, մինչ մյուսները շարունակում են։ Չեղարկման տվյալները ստուգվում են գործընկերոջ նույնականացման ժամանակ և նորից, երբ ֆայլը փոխարինվում է։ Ժամանակավոր թղթապանակին դիպչում են միայն այն ժամանակ, երբ սկրիպտը կամ հավելումը ինչ-որ բան գրում է։
Երեքից ոչ մեկը չի պատկանում մեկնարկի ուղուն, ուստի շաբաթներ առողջ մնացած սերվերը կարող է ձախողվել հաջորդ միացման ժամանակ։ Կատեգորիան նաև անվանում է ուղղման տիրոջը. առաջին երկուսը դեմոնի հաշվի ներքո կարգավորման ընթերցման իրավունքներն են, իսկ երրորդը նեղ նպատակի գրելի տեղ է։
| Path reopened later | What triggers the open | First sign when it fails |
|---|---|---|
| Client configuration file | A connection for that client identity | One client rejected while others connect |
| Revocation data | Peer authentication, including after replacement | Revoked and valid peers both refused |
| Script or plugin temporary directory | A helper needs to create a file | The helper exits with a path error |
persist-key պատասխանում է ավելի նեղ հարցի, քան շատերն են ենթադրում։ Այն բաց է պահում բանալու ֆայլը փաստաթղթավորված SIGUSR1 և ping-restart վերակայումների ընթացքում, և ոչինչ չի անում CCD ֆայլերի, չեղարկման տվյալների, օժանդակ կատարվող ֆայլերի կամ գործընթացի լրիվ վերսկսման համար։ Դրանք դեռ հետևում են իրենց բացման ուղիներին՝ այդ պահին աշխատող ցանկացած հաշվի ներքո։
Հաստատեք հաշիվը և այն տեսքը, որն այն իրականում ունի
Հարցրեք աշխատող դեմոնին, թե որ հաշիվն է օգտագործում, փոխարենը unit ֆայլին վստահելու, ապա համեմատեք պատասխանը այն բանի հետ, ինչ unit-ը սահմանում է։ Անհամապատասխանությունն առաջին լուծելիք բանն է, քանի որ յուրաքանչյուր հետագա թույլտվության ստուգում ընթանում է որպես այն, ով գործընթացն իրականում կա։ Ապա անցեք ուղին բաղադրիչ առ բաղադրիչ. անցումը գնահատվում է յուրաքանչյուր մակարդակում, ուստի անանցանելի թղթապանակի մեջ ընթեռնելի ֆայլը մնում է անընթեռնելի։ Վերջնական ֆայլի ռեժիմը վերջին հարցն է, ոչ առաջինը։
Անվանատարածքները և ծառայության ավազարկղերը ավելացնում են սահմաններ, որոնք սեփականությունը և ռեժիմի բիթերը չեն նկարագրում։ Ձեր shell-ում տեսանելի ուղին կարող է բացակայել կամ միայն ընթերցման լինել chroot-ի, ամրակցման անվանատարածքի կամ տնային թղթապանակները թաքցնող unit-ի ներսում։ Անվտանգության մոդուլները ևս մեկ շերտ են ավելացնում, ուստի ընթեռնելի թվացող ֆայլը բացելիս դեռ կարող է մերժվել։
ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/aliceԱդմինիստրատորի shell-ում հաջող ընթերցումը չի ստուգում այդ համակցված պայմաններից ոչ մեկը։ Գործարկեք ստուգումը դեմոնի հաշվով, նույն անվանատարածքով և ավազարկղով, կամ ընդունեք, որ արդյունքը նկարագրում է ձեր shell-ը, ոչ սերվերը։ Երրորդ հրամանը այդ փորձարկման էժան տարբերակն է. այն տպում է յուրաքանչյուր բաղադրիչի ռեժիմը և ձախողվում է առաջինի վրա, որով դեմոնի հաշիվը չի կարող անցնել։
Գործարկման գրառմանը տվեք իր առանձին թղթապանակը
Ընթերցումը ցանկի միայն կեսն է։ Օժանդակ սկրիպտին կարող է պետք լինել վիճակի ֆայլ ստեղծել, հավելմանը՝ վիճակ գրել իր կարգավորման կողքին, և այդ գրառումները չեն ծածկվում կարգավորման ծառը գրելի դարձնելով։ Տվեք կոնկրետ թղթապանակին այն գրելու թույլտվությունը, որ պահանջում է նրա գործառույթը, այնպիսի տիրոջ և ռեժիմի հետ, որը կարող եք բացատրել։ Նախապատվություն տվեք միայն ընթերցման հասանելիությանը այն ամենի համար, ինչ միայն կարդացվում է։
Առանձին պահեք մասնավոր բանալու թույլտվությունները քաղաքականության ֆայլերից։ Վերակայումից հետո նորից ընթերցվող բանալին այլ պահանջ ունի, քան յուրաքանչյուր միացման ժամանակ ընթերցվող հաճախորդի ֆայլը, և մեկ զիջող ռեժիմը երկուսի համար տալիս է ավելի շատ հասանելիություն, քան խնդիրը խնդրում է։ Նեղ սեփականությամբ առանձնացված դեմոնի հաշիվն ավելի հեշտ է ստուգել, քան լայն խումբը։ Երբ բանալին պետք է դիմանա վերակայումներին, persist-key հեռացնում է նորից ընթերցումը՝ թղթապանակը լայնացնելու փոխարեն։
Որոշեք այն իրադարձությունից, որը կարող եք վերարտադրել
Կենդանի թունելը ապացուցում է կոդի միջով մեկ ուղի։ Այն իրադարձությունը, որին պետք է ֆայլը, միակ փորձարկումն է, որը ծածկում է ձեզ հետաքրքրող բացումը՝ լինի դա նոր հաճախորդի միացում, փոխարինված չեղարկման ֆայլ, թույլատրված մեղմ վերակայում թե պլանավորված վերսկսում։ Ընտրեք իրադարձությունը, գործարկեք այն և պահեք առաջին սխալը, ոչ վերջինը։
Մեղմ վերակայման համար մեկ ազդանշանը և unit-ի մատյանը ցույց են տալիս՝ արդյոք բանալին նորից ընթերցվել է։ Ուղարկեք ազդանշանը, ապա կարդացեք unit-ի գրած վերջին տողերը.
systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pagerՄի եզրակացրեք, որ վտանգված դեմոնը այլևս չի կարող փոխել ֆայլերը միայն այն պատճառով, որ արտոնությունները իջեցվել են։ Թե ինչ դեռ կարող է, կախված է մնացած հավատարմագրերից, նրա կարողություններից, այն թղթապանակներից, որտեղ կարող է գրել, և ցանկացած գրելի դեսկրիպտորից, որ դեռ պահում է։ Արտոնությունների նվազեցումը նեղացնում է իշխանությունը, և գործարկման բացումների ցանկն է, որ ցույց է տալիս, թե որքան։ Գրեք այդ սահմանը կարգավորման կողքին, որպեսզի հաջորդ մարդը ստիպված չլինի նորից հայտնաբերել այն։