PAM પ્રમાણીકરણ હાથથી ચલાવો ત્યારે કામ કરે છે પણ OpenVPN સેવા તરીકે નિષ્ફળ જાય છે

PAM દ્વારા પ્રમાણીકરણ ત્યારે સફળ થઈ શકે છે જ્યારે તમે ક્લાયન્ટ હાથથી ચલાવો છો, અને systemd એ જ પ્રોફાઇલ શરૂ કરે ત્યારે AUTH_FAILED સાથે નિષ્ફળ જાય છે. એ ચલાવવાની વચ્ચે પાસવર્ડ બદલાતો નથી; જે બદલાય છે તે PAM ને પ્રશ્ન પૂછતી પ્રક્રિયાની આસપાસની મર્યાદાઓનો સમૂહ છે. PAM એક હેલ્પર દ્વારા જવાબ આપે છે જેની પોતાના ઓળખપત્રો બદલવાની ક્ષમતા જ કઠોર unit દૂર કરે છે. ક્ષમતા-યાદીને અડકતાં પહેલાં એ હેલ્પર અને તેને જરૂરી સીમા શોધો.

unix_chkpwd એ બાઇનરી છે જે PAM ના પ્રશ્નનો જવાબ આપે છે

સ્થાનિક પાસવર્ડ પ્રમાણીકરણ સાથે, pam_unix ભાગ્યે જ પોતે હૅશ ફાઇલ વાંચે છે. તે unix_chkpwd ચલાવે છે, જેને ડિસ્ટ્રિબ્યુશન setuid root અથવા setgid shadow તરીકે સ્થાપિત કરે છે જેથી એક પાસવર્ડ એવી પ્રક્રિયા વતી ચકાસી શકાય જેને /etc/shadow વાંચવાનું કોઈ કામ નથી. એ ઓળખ મેળવવાની ક્ષમતા દૂર કરો અને હેલ્પર ચકાસણી પૂરી કરી શકશે નહીં, તેથી મોડ્યુલ સાદું પ્રમાણીકરણ નિષ્ફળતા પરત કરે છે.

પછી નિષ્ફળતા ક્લાયન્ટ જોઈ શકે તેવા દરેક લોગમાં ઓળખપત્ર સમસ્યા જેવી દેખાય છે. એ જ જાળ છે: ક્લાયન્ટ PAM એ તેને શું કહ્યું તે જણાવે છે, અને PAM ફક્ત એ જણાવે છે કે સ્ટેકે ના કહ્યું. root તરીકે હેલ્પર હાથથી ચલાવવું પણ કંઈ સાબિત કરતું નથી, કારણ કે તે એવો વિશેષાધિકાર માર્ગ અજમાવે છે જે સેવા કદી વાપરતી નથી. systemd એ ખરેખર જે unit લોડ કર્યું તે વાંચો, પછી તેણે કરેલા પ્રયાસ માટે સિસ્ટમ લોગ વાંચો. એ બે દૃષ્ટિકોણ સેન્ડબોક્સ સમસ્યાને ખોટા પાસવર્ડની સમસ્યાથી અલગ પાડે છે.

પાસવર્ડ લોગ વાંચતાં પહેલાં unit વાંચો

પેકેજ કરેલું unit તમે ન લખ્યું હોય તેવું drop-in ધરાવી શકે છે, અને અસરકારક રૂપરેખાંકન એ જોડાયેલું પરિણામ છે. systemd જેમ જુએ તેમ unit છાપો, સાથે એ સેન્ડબોક્સ સેટિંગ્સ જે નક્કી કરે છે કે હેલ્પર પોતાને ઉન્નત કરી શકે છે કે નહીં. આ તબક્કે ફક્ત-વાંચન નિરીક્ષણ પૂરતું છે.

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 ક્યાંથી આવે છે, જે મહત્વપૂર્ણ છે કારણ કે મહિનાઓ પહેલાં ઉમેરાયેલો ઓવરરાઇડ કેમ અસ્તિત્વમાં છે તે યાદ કરતાં વધુ જીવે છે. બીજો એ સેન્ડબોક્સ મૂલ્યો છાપે છે જેના પર આગલા બે વિભાગો આધાર રાખે છે.

તમે જે જુઓ છો તેની સરખામણી એ જ ડિસ્ટ્રિબ્યુશન અને આવૃત્તિના કાર્યકારી હોસ્ટ સાથે કરો. 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

કાર્યકારી ટનલને ફરી જોડાણની પણ જરૂર છે, કારણ કે સેન્ડબોક્સ ફેરફારો પ્રથમ કરતાં બીજા કનેક્શનને વધુ વાર તોડે છે. ફરી જોડાણ પછી સ્થાપિત સોકેટ તપાસો અને ખાતરી કરો કે એ જ unit હજી તેની સેવા કરે છે.