OpenVPN ના user ડ્રોપ પર systemd હાર્ડનિંગ ઢગલો ન કરો

બે લઘુતમ-વિશેષાધિકાર રેસિપી ભેગી ચોંટાડવાથી વધુ કડક તૈનાતી બનતી નથી. એક મોડેલ ડિમનને વિશેષાધિકાર સાથે શરૂ થવા દે છે અને ઇનિશિયલાઇઝેશન પછી બિન-વિશેષાધિકૃત ખાતામાં ઉતરે છે; બીજું સેવા મેનેજરને પહેલી સૂચનાથી જ મર્યાદિત ઓળખ હેઠળ તેને ચલાવવા દે છે. દરેક જાતે કામ કરે છે, અને બંનેનું જોડાણ ઘણી વાર એવી સેવા બનાવે છે જે બેમાંથી કોઈ પણ કામ સ્વચ્છ રીતે કરી શકતી નથી. બાકીનું આ લખાણ નિર્ણયને ક્રમમાં લે છે.

બે મોડેલ, બદલીનો એક માલિક

પહેલું મોડેલ ડિમનનું છે. સમુદાય OpenVPN ના user અને group વિકલ્પો ટનલ અને કી ગોઠવાયા પછી ઓળખ બદલે છે, અને persist-key સાથે persist-tun એ સંસાધનોને પછી પણ વાપરી શકાય તેમ રાખે છે.

બીજું મોડેલ સેવા મેનેજરનું છે. systemd નું User= અથવા Group= સેટિંગ નક્કી કરે છે કે પ્રક્રિયા કઈ ઓળખ હેઠળ શરૂ થાય, અને ક્ષમતા-નિર્દેશો નક્કી કરે છે કે તે શું રાખી શકે. મોડેલો વચ્ચે પસંદગી સુરક્ષા પ્રશ્ન બનતા પહેલાં પેકેજિંગનો પ્રશ્ન છે, અને પેકેજ સંભાળનારે તેનો જવાબ પહેલેથી આપ્યો છે. તમારું કામ ત્રીજો વિકલ્પ શોધવાને બદલે એ જવાબ શોધવાનું છે.

બંને વૈધ છે. ભૂલ એ છે કે તેમને એક જ ડિઝાઇનના સ્તર તરીકે ગણવા, કારણ કે બીજું મોડેલ પહેલાની ઓળખ-બદલીને એવી ક્રિયા બનાવી શકે છે જે કરવાની પ્રક્રિયાને હવે પરવાનગી નથી.

નક્કી કરો કે ઓળખ ક્યાં બદલાય છે

જો યુનિટ પહેલેથી સમર્પિત ખાતા તરીકે શરૂ થાય છે, તો ડિમનને બીજું ખાતું બનવાની સૂચના એવું setuid સંક્રમણ માગે છે જે કઠોર કરેલી સેવાએ કદી કરવાનું ન હતું. નિષ્ફળતા શરૂઆતમાં પરવાનગી-ભૂલ તરીકે દેખાય છે, સ્પષ્ટ નીતિ-સંદેશ તરીકે નહીં. તે ખૂટતી ક્ષમતા જેવું વંચાય છે, જે લોકોને ઓળખના પ્રશ્ન તરફને બદલે વધુ પહોળા મર્યાદા-સેટ તરફ ધકેલે છે.

કંઈપણ સંપાદિત કરતા પહેલાં વાંચો કે સ્થાપિત પેકેજ ખરેખર શું આપે છે, તેની drop-in ડિરેક્ટરી સહિત. કેટલાક યુનિટ જાણી જોઈને ડિમનનું પોતાનું ઉતરાણ છોડી દે છે કારણ કે મેનેજર પહેલેથી તે સંભાળે છે, અને કેટલાક ઇનિશિયલાઇઝેશન પછીની બદલી માટે એ વિકલ્પો પર આધાર રાખે છે. કયું મોડેલ વારસામાં મળ્યું તે જાણ્યા વિના બેમાંથી કોઈ એક કાઢી નાખવું એ જ રીતે કામ કરતી સેવા શરૂ થવાનું બંધ કરે છે.

પસંદ કરેલું મોડેલ એક લીટીમાં લખો: મેનેજર-માલિકીનું કે ડિમન-માલિકીનું. પછીના દરેક નિર્દેશે એ વાક્ય સાથે સુસંગત હોવું જોઈએ, અને મિશ્ર યુનિટને સમાધાન નહીં, પણ ખામી તરીકે ગણવું જોઈએ.

ક્ષમતાઓ મર્યાદા છે, બક્ષિસ નહીં

ક્ષમતા મર્યાદા-સેટ કહે છે કે પ્રક્રિયા વધુમાં વધુ શું રાખી શકે. તે એક ટોચમર્યાદા છે, અને ત્યાં ક્ષમતા સૂચિબદ્ધ કરવાથી પોતાની રીતે કંઈ મળતું નથી, એટલે ઉદાર મર્યાદા-સેટ ધરાવતું યુનિટ પણ ટનલ બનાવવામાં નિષ્ફળ જઈ શકે.

ક્ષમતાને સેવાના આસપાસના સેટમાં ખરેખર મૂકે છે AmbientCapabilities=. systemd અમલીકરણ સંદર્ભ બે નિર્દેશોને અલગ રીતે દસ્તાવેજ કરે છે, અને એ જ ભેદ ઓનલાઇન ક્ષમતા અંગેની મોટાભાગની ગૂંચવણભરી સલાહ સમજાવે છે.

ક્ષમતા ત્યારે જ ઉમેરો જ્યારે નિષ્ફળ થતી ક્રિયા તેને ઓળખે. પહોળો મર્યાદા-સેટ સાચું કારણ છુપાવે છે અને સેવાને ડિઝાઇનના ઇરાદા કરતાં વધુ વિશેષાધિકાર સાથે છોડે છે. તે યુનિટની સમીક્ષા પણ મુશ્કેલ બનાવે છે, કારણ કે ટોચમર્યાદા હવે કામનું વર્ણન કરતી નથી. સાચી ખામી સુધરે પછી વધારાની ક્ષમતા દૂર કરો.

જીવનચક્રમાં સત્તાનું મેપિંગ કરો

દરેક તબક્કે પ્રક્રિયાએ શું કરવું તે સૂચિબદ્ધ કરો: શરૂઆત, સ્થિર સ્થિતિ, પુનઃપ્રમાણીકરણ અને સમાપ્તિ. ઇન્ટરફેસ બનાવવું, રૂટમાં ફેરફાર, સુરક્ષિત કી વાંચવી અને સહાયકને બોલાવવો એ બધું એક જ ક્ષણે કે એક જ જરૂરિયાત હેઠળ થતું નથી. યાદીને ક્ષમતા પ્રમાણે ગોઠવતા પહેલાં તબક્કા પ્રમાણે ગોઠવો.

ચીકાશના વિકલ્પો પુનઃવાટાઘાટ દરમિયાન સંસાધનો જાળવે છે, અને કદી ન રાખેલી પરવાનગીઓ આપતા નથી. જે કી પ્રક્રિયા શરૂઆતમાં વાંચી શકતી નથી તે પછીથી પણ અવાંચ્ય રહેશે, ચીકાશના ફ્લેગ શું કહે તે પછી પણ. ફ્લેગ પહેલેથી ચાલતું હતું તે જાળવે છે.

વહેંચાયેલા નહીં, સમર્પિત ખાતાનો ઉપયોગ કરો. OpenVPN ના વિકાસકર્તાઓ nobody ને સામાન્ય ઉદાહરણ તરીકે વાપરવાની ટેવ સામે ચેતવે છે, કારણ કે યજમાન પરની બીજી સેવાઓ પહેલેથી એ ખાતા હેઠળ ચાલતી હોઈ શકે છે અને તમે ધારો છો તે અલગાવ ત્યાં નથી.

સ્થાનિક ભાર બદલતી વિશેષતાઓ, જેમ કે ડેટા-ચેનલ ઓફલોડ અથવા અલગ રીતે લિંક થતું બિલ્ડ, કઈ ક્રિયાઓની જરૂર છે તે બદલી શકે છે. પેકેજ બદલાય ત્યારે નકશો ફરી જુઓ, ફક્ત કંઈ તૂટે ત્યારે નહીં.

યોજના લખી રાખો અને પુનઃપ્રાપ્તિનો પ્રવેશ રાખો

તૈનાતીના રેકોર્ડમાં મેનેજર, શરૂઆતની ઓળખ, ઇચ્છિત સ્થિર ઓળખ અને દરેક મંજૂરી તેની જરૂર પડતી ક્રિયા સાથે નામ આપવું જોઈએ. એ રેકોર્ડ જ આગલા ફેરફારને પ્રયોગ નહીં, સમીક્ષાયોગ્ય બનાવે છે.

સંપાદન કરતી વખતે કન્સોલ પ્રવેશ ખુલ્લો રાખો, કારણ કે શરૂઆતમાં નિષ્ફળ થતું યુનિટ દૂરથી સમારવું મુશ્કેલ છે. ફેરફારને પૂર્ણ કહેતા પહેલાં પુનઃશરૂઆત અને સંપૂર્ણ રીબૂટ ચકાસો. પુનઃશરૂઆત ટકી જતું યુનિટ નેટવર્ક ચાલુ થવા પહેલાં પણ નિષ્ફળ જઈ શકે છે.

સફળતા એ સમજાયેલું લઘુતમ-સત્તાનું જીવનચક્ર છે, એવી પ્રક્રિયા નહીં જે સંજોગવશાત્ બિન-root નામ હેઠળ ચાલતી હોય.