PAM նույնականացումը ձեռքով աշխատում է, բայց որպես OpenVPN ծառայություն ձախողվում է

PAM-ի միջոցով նույնականացումը կարող է հաջողվել, երբ հաճախորդը ձեռքով եք գործարկում, և ձախողվել AUTH_FAILED-ով, հենց որ systemd-ը գործարկում է նույն պրոֆիլը։ Այդ գործարկումների միջև գաղտնաբառը չի փոխվում. փոխվում է PAM-ին հարցը տվող գործընթացի շուրջ սահմանափակումների բազմությունը։ PAM-ը պատասխանում է օգնականի միջոցով, որի՝ սեփական հավատարմագրերը փոխելու ունակությունը հենց այն է, ինչ հեռացնում է կարծրացված unit-ը։ Գտե՛ք այդ օգնականին և նրան անհրաժեշտ սահմանը, նախքան հնարավորությունների ցանկին դիպչելը։

unix_chkpwd-ը բինարն է, որը պատասխանում է PAM-ի հարցին

Տեղական գաղտնաբառային նույնականացմամբ pam_unix հազվադեպ է ինքը կարդում hash ֆայլը։ Այն գործարկում է unix_chkpwd-ը, որը տարածումները տեղադրում են setuid root կամ setgid shadow-ի տեսքով, որպեսզի մեկ գաղտնաբառ ստուգվի այնպիսի գործընթացի անունից, որին ոչ մի կապ չունի /etc/shadow-ը կարդալու հետ։ Հեռացրե՛ք այդ ինքնությունը ձեռք բերելու ունակությունը, և օգնականը չի կարող ավարտին հասցնել ստուգումը, ուստի մոդուլը վերադարձնում է սովորական նույնականացման ձախողում։

Այնուհետև ձախողումը հաճախորդին տեսանելի յուրաքանչյուր լոգում երևում է որպես հավատարմագրերի խնդիր։ Դա է թակարդը. հաճախորդը հայտնում է այն, ինչ PAM-ը ասել է իրեն, իսկ PAM-ը հայտնում է միայն, որ կույտը ասել է ոչ։ Օգնականը root-ով ձեռքով գործարկելը նույնպես ոչինչ չի ապացուցում, քանի որ այն փորձարկում է արտոնությունների ուղի, որը ծառայությունը երբեք չի օգտագործում։ Կարդացե՛ք այն unit-ը, որը systemd-ը իրականում բեռնել է, ապա համակարգի լոգը՝ կատարված փորձի համար։ Այս երկու տեսակետները առանձնացնում են sandbox-ի խնդիրը սխալ գաղտնաբառի խնդրից։

Կարդացե՛ք unit-ը, նախքան գաղտնաբառի լոգը կարդալը

Փաթեթավորված unit-ը կարող է կրել ձեր չգրած drop-in, և արդյունավետ կոնֆիգուրացիան միաձուլված արդյունքն է։ Տպե՛ք unit-ը այնպես, ինչպես տեսնում է systemd-ը, միասին այն sandbox կարգավորումների հետ, որոնք որոշում են՝ օգնականը կարո՞ղ է ինքն իրեն բարձրացնել։ Այս փուլում միայն-կարդալու ստուգումը բավարար է։

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

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

Համեմատե՛ք տեսածը նույն տարածման և տարբերակի աշխատող հոսթի հետ։ User-ում, CapabilityBoundingSet-ում կամ NoNewPrivileges-ում տարբերությունը կոնկրետ հետք է. արձակ նկարագրության մեկնաբանությունների տարբերությունը՝ ոչ։ Գրի՛ք արժեքները նախքան որևէ բան փոխելը, որովհետև շարժվող թիրախի հետ ավելի ուշ համեմատությունը ոչինչ չի ապացուցում։ Եթե ծառայությունը աշխատում է անարտոնյալ հաշվով և դատարկ bounding բազմությամբ, օգնականը գրեթե ոչինչ չունի աշխատելու։

Հավատարմագրերի ձևափոխումը, ֆայլերի հասանելիությունը և քաղաքականությունը երեք սահմաններ են

Սկսե՛ք նրանից, ինչ տեղի է ունենում exec-ի ընթացքում։ setuid բինարը կամ ֆայլային հնարավորություններ կրող ֆայլը հրահրում է հավատարմագրերի ձևափոխում, ուստի ստացված ինքնությունը կանչողի շարունակությունը չէ։ Bounding բազմությունը սահմանափակում է, թե ինչ կարող է ձեռք բերել նման ֆայլը, և NoNewPrivileges-ը լիովին արգելափակում է setuid, setgid և ֆայլային հնարավորությունների ձեռքբերումը։ Այդ երեքից ցանկացածը կարող է կանգնեցնել օգնականին՝ թողնելով ծառայության մյուս բոլոր գործառույթները անվնաս։

Այնուհետև առանձնացրե՛ք լայն հայեցողական շրջանցումը նեղ ընթերցման հասանելիությունից։ CAP_DAC_OVERRIDE-ը գրեթե ամենուր բաց է թողնում հայեցողական ստուգումները, մինչդեռ CAP_DAC_READ_SEARCH-ը ծածկում է ընթերցումն ու գրացուցակներով անցումը՝ իր իսկ լրացուցիչ լիազորություններով։ Դրանք տարբեր գործիքներ են տարբեր ազդեցության շառավղով, և ոչ մեկը «թող PAM-ը կարդա shadow ֆայլը» արտահայտության ուղղագրությունը չէ։

Վերջում հարցրե՛ք՝ արդյոք պարտադիր քաղաքականությունը ընդհանրապես թույլատրում է գործողությունը։ Linux հնարավորությունը չի վերացնում SELinux-ը, և մեկն ունենալը ոչինչ չի ապացուցում type enforcement կանոնի մասին։ Ֆայլի հասանելիության մերժումը և հնարավորության մերժումը դիտե՛ք որպես տարբեր ապացույցներ, քանի որ դրանք անվանում են տարբեր ուղղումներ և հաճախ տարբեր սեփականատերեր։ Կարդացե՛ք գրառման յուրաքանչյուր դաշտը, ոչ միայն denied բառը։ Որ կատարվող ֆայլն է կատարել գործողությունը, որ դոմենում է աշխատել, ինչ տիպի թիրախի է դիպել, որ օբյեկտի դասն է ներգրավվել և որ թույլտվությունն է մերժել քաղաքականությունը. յուրաքանչյուրը պատասխանը նեղացնում է յուրովի։

Հանե՛ք մերժումը աուդիտի լոգից

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

ausearch -m AVC,USER_AVC -ts recent

Դատարկ արդյունքը անմեղության ապացույց չէ։ Այն նշանակում է կա՛մ աուդիտը չի հավաքում, կա՛մ ձեր պատուհանը բաց է թողել փորձը, և երկու հնարավորություններն էլ պետք է բացառել նախքան քաղաքականությունը բացառելը։

Red Hat-ի SELinux-ի խնդիրների լուծման ուղեցույցը պիտակների և կոնֆիգուրացիայի ստուգումները դնում է allow կանոնների ստեղծումից առաջ, ինչը ճիշտ հերթականությունն է նաև այս խնդրի համար։ Սխալ պիտակավորված օգնական բինարը և քաղաքականության բացը նման մերժումներ են առաջացնում, սակայն տարբեր վերանորոգումներ են պահանջում։ Պիտակավորման սխալի համար allow կանոն ստեղծելը թաքցնում է թերությունը և թողնում, որ հաջորդ փաթեթի թարմացումը նորից ներմուծի այն։ Հաստատե՛ք տեղադրված օգնականի պիտակը նախքան որևէ քաղաքականություն գրելը։

Ապացուցե՛ք փոփոխությունը մեկ ընդունված և մեկ մերժված մուտքով

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

Կատարե՛ք իրական միացման փորձ և անմիջապես հետո կարդացե՛ք մատյանը։ Վերանորոգումն ապացուցող տողը այդ փորձի pam_unix(openvpn:auth) գրառումն է. այն պետք է ցույց տա հաջող նույնականացում, և ոչ մի AVC գրառում չպետք է կրի նույն վայրկյանը։

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

Աշխատող թունելին նաև վերամիացում է պետք, որովհետև sandbox փոփոխությունները երկրորդ միացումը ավելի հաճախ են կոտրում, քան առաջինը։ Ստուգե՛ք հաստատված socket-ը վերամիացումից հետո և հաստատե՛ք, որ նույն unit-ը դեռ սպասարկում է այն։