OpenVPN-ന്റെ user ഡ്രോപ്പിൽ systemd ഹാർഡനിംഗ് അടുക്കരുത്

ഒരുമിച്ച് ഒട്ടിച്ച രണ്ട് കുറഞ്ഞ പ്രിവിലേജ് പാചകക്കുറിപ്പുകൾ കൂടുതൽ കർശനമായ വിന്യാസം നൽകുന്നില്ല. ഒരു മോഡൽ ഡീമണിനെ പ്രിവിലേജുകളോടെ തുടങ്ങാനും ഇനീഷ്യലൈസേഷന് ശേഷം പ്രിവിലേജില്ലാത്ത അക്കൗണ്ടിലേക്ക് ഇറങ്ങാനും അനുവദിക്കുന്നു; മറ്റൊന്ന് സേവന മാനേജറെ ആദ്യ നിർദ്ദേശം മുതൽ പരിമിതമായ ഐഡന്റിറ്റിയിൽ അത് പ്രവർത്തിപ്പിക്കാൻ അനുവദിക്കുന്നു. ഓരോന്നും സ്വതന്ത്രമായി പ്രവർത്തിക്കുന്നു, രണ്ടിന്റെയും കൂട്ടിച്ചേർക്കൽ പലപ്പോഴും രണ്ട് ജോലികളിൽ ഒന്നും വൃത്തിയായി ചെയ്യാൻ കഴിയാത്ത സേവനം സൃഷ്ടിക്കുന്നു. ബാക്കിയുള്ളത് തീരുമാനം ക്രമത്തിൽ പരിശോധിക്കുന്നു.

രണ്ട് മോഡലുകൾ, മാറ്റത്തിന്റെ ഒരു ഉടമ

ആദ്യ മോഡൽ ഡീമണിന്റേതാണ്. കമ്മ്യൂണിറ്റി OpenVPN ന്റെ user ഉം group ഉം ഓപ്ഷനുകൾ ടണലും കീകളും ക്രമീകരിച്ചതിന് ശേഷം ഐഡന്റിറ്റി മാറ്റുന്നു, persist-key ഉം persist-tun ഉം ആ വിഭവങ്ങൾ പിന്നീടും ഉപയോഗയോഗ്യമായി നിലനിർത്തുന്നു.

രണ്ടാം മോഡൽ സേവന മാനേജറിന്റേതാണ്. systemd ന്റെ User= അല്ലെങ്കിൽ Group= ക്രമീകരണം പ്രക്രിയ ഏത് ഐഡന്റിറ്റിയിൽ തുടങ്ങണമെന്ന് തീരുമാനിക്കുന്നു, കഴിവ് നിർദ്ദേശങ്ങൾ അതിന് എന്ത് സൂക്ഷിക്കാമെന്ന് തീരുമാനിക്കുന്നു. മോഡലുകൾക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പ് സുരക്ഷാ ചോദ്യമാകുന്നതിന് മുമ്പ് പാക്കേജിംഗ് ചോദ്യമാണ്, പാക്കേജ് പരിപാലകൻ ഇതിന് ഇതിനകം ഉത്തരം നൽകിയിട്ടുണ്ട്. നിങ്ങളുടെ ജോലി മൂന്നാമതൊരു ഓപ്ഷൻ കണ്ടുപിടിക്കലല്ല, ആ ഉത്തരം കണ്ടെത്തലാണ്.

രണ്ടും സാധുവാണ്. തെറ്റ് അവയെ ഒരേ രൂപകൽപ്പനയുടെ പാളികളായി കാണുന്നതാണ്, കാരണം രണ്ടാം മോഡലിന് ആദ്യത്തേതിന്റെ ഐഡന്റിറ്റി മാറ്റം പ്രക്രിയയ്ക്ക് ഇനി അനുവദനീയമല്ലാത്ത ഒരു പ്രവർത്തനമാക്കി മാറ്റാനാകും.

ഐഡന്റിറ്റി എവിടെ മാറുന്നുവെന്ന് തീരുമാനിക്കുക

യൂണിറ്റ് ഇതിനകം സമർപ്പിത അക്കൗണ്ടായി തുടങ്ങുന്നുവെങ്കിൽ, ഡീമണിനോട് മറ്റൊരു അക്കൗണ്ടാകാൻ നൽകുന്ന നിർദ്ദേശം കഠിനീകരിച്ച സേവനം ഒരിക്കലും ചെയ്യരുതാത്ത ഒരു setuid പരിവർത്തനം ആവശ്യപ്പെടുന്നു. പരാജയം തുടക്കത്തിൽ അനുമതി പിശകായി പ്രത്യക്ഷപ്പെടുന്നു, വ്യക്തമായ നയ സന്ദേശമായി അല്ല. ഇത് കാണാതായ ഒരു കഴിവായി വായിക്കപ്പെടുന്നു, അത് ആളുകളെ ഐഡന്റിറ്റി ചോദ്യത്തിലേക്കല്ല, കൂടുതൽ വിശാലമായ പരിധി സമുച്ചയത്തിലേക്ക് തള്ളുന്നു.

എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജ് യഥാർത്ഥത്തിൽ എന്താണ് നൽകുന്നതെന്ന് വായിക്കുക, അതിന്റെ drop-in ഡയറക്ടറി ഉൾപ്പെടെ. ചില യൂണിറ്റുകൾ ഡീമണിന്റെ സ്വന്തം ഇറക്കം ബോധപൂർവ്വം ഒഴിവാക്കുന്നു, കാരണം മാനേജർ ഇതിനകം അത് കൈകാര്യം ചെയ്യുന്നു, ചിലത് ഇനീഷ്യലൈസേഷന് ശേഷമുള്ള മാറ്റത്തിന് ആ ഓപ്ഷനുകളെ ആശ്രയിക്കുന്നു. ഏത് മോഡൽ പാരമ്പര്യമായി ലഭിച്ചുവെന്ന് അറിയാതെ ഒന്ന് നീക്കം ചെയ്യുന്നതാണ് പ്രവർത്തിക്കുന്ന സേവനം തുടങ്ങാതാകുന്ന വഴി.

തിരഞ്ഞെടുത്ത മോഡൽ ഒരു വരിയിൽ എഴുതുക: മാനേജർ-ഉടമസ്ഥതയോ ഡീമൺ-ഉടമസ്ഥതയോ. തുടർന്നുള്ള ഓരോ നിർദ്ദേശവും ആ വാക്യവുമായി പൊരുത്തപ്പെടണം, കൂടാതെ കലർന്ന യൂണിറ്റിനെ വിട്ടുവീഴ്ചയല്ല, കുറ്റമായി കണക്കാക്കണം.

കഴിവുകൾ പരിധികളാണ്, അനുദാനങ്ങളല്ല

ഒരു കഴിവ് പരിധി സമുച്ചയം പ്രക്രിയയ്ക്ക് പരമാവധി എന്ത് സൂക്ഷിക്കാമെന്ന് പറയുന്നു. അതൊരു മേൽക്കൂരയാണ്, അവിടെ ഒരു കഴിവ് പട്ടികപ്പെടുത്തുന്നത് സ്വയം ഒന്നും നൽകുന്നില്ല, അതിനാൽ ഉദാരമായ പരിധി സമുച്ചയമുള്ള യൂണിറ്റിനും ടണൽ സൃഷ്ടിക്കാൻ കഴിയാതെ വന്നേക്കാം.

ഒരു കഴിവിനെ സേവനത്തിന്റെ ചുറ്റുമുള്ള സമുച്ചയത്തിൽ യഥാർത്ഥത്തിൽ ഇടുന്നത് AmbientCapabilities= ആണ്. systemd എക്സിക്യൂഷൻ റഫറൻസ് രണ്ട് നിർദ്ദേശങ്ങളും വെവ്വേറെ രേഖപ്പെടുത്തുന്നു, ഈ വ്യത്യാസമാണ് ഓൺലൈനിലെ ആശയക്കുഴപ്പമുള്ള കഴിവ് ഉപദേശങ്ങളിൽ ഭൂരിഭാഗവും വിശദീകരിക്കുന്നത്.

പരാജയപ്പെടുന്ന പ്രവർത്തനം അത് തിരിച്ചറിഞ്ഞതിന് ശേഷം മാത്രം ഒരു കഴിവ് ചേർക്കുക. വിശാലമായ പരിധി സമുച്ചയം യഥാർത്ഥ കാരണം മറയ്ക്കുകയും സേവനത്തെ രൂപകൽപ്പന ഉദ്ദേശിച്ചതിലും കൂടുതൽ പ്രിവിലേജിൽ നിർത്തുകയും ചെയ്യുന്നു. മേൽക്കൂര ഇനി ജോലിയെ വിവരിക്കാത്തതിനാൽ യൂണിറ്റ് അവലോകനം ചെയ്യാനും ഇത് ബുദ്ധിമുട്ടാക്കുന്നു. യഥാർത്ഥ കുറ്റം പരിഹരിച്ചാൽ അധിക കഴിവ് നീക്കം ചെയ്യുക.

ജീവിതചക്രത്തിലുടനീളം അധികാരം മാപ്പ് ചെയ്യുക

ഓരോ ഘട്ടത്തിലും പ്രക്രിയ എന്ത് ചെയ്യണമെന്ന് പട്ടികപ്പെടുത്തുക: തുടക്കം, സ്ഥിരാവസ്ഥ, വീണ്ടും പ്രാമാണീകരണം, പൊളിച്ചുമാറ്റൽ. ഇന്റർഫേസ് സൃഷ്ടിക്കൽ, റൂട്ട് മാറ്റങ്ങൾ, സംരക്ഷിത കീ വായിക്കൽ, സഹായിയെ വിളിക്കൽ എന്നിവയെല്ലാം ഒരേ നിമിഷത്തിലോ ഒരേ ആവശ്യകതകളിലോ സംഭവിക്കുന്നില്ല. കഴിവ് പ്രകാരം ക്രമീകരിക്കുന്നതിന് മുമ്പ് പട്ടിക ഘട്ടം പ്രകാരം ക്രമീകരിക്കുക.

സ്ഥിരതാ ഓപ്ഷനുകൾ വീണ്ടും ചർച്ചകൾക്കിടയിൽ വിഭവങ്ങൾ സംരക്ഷിക്കുന്നു, ഒരിക്കലും ഉണ്ടായിരുന്നിട്ടില്ലാത്ത അനുമതികൾ നൽകുന്നില്ല. തുടക്കത്തിൽ പ്രക്രിയയ്ക്ക് വായിക്കാൻ കഴിയാത്ത ഒരു കീ പിന്നീടും വായിക്കാനാകാത്തതായി തുടരും, സ്ഥിരതാ ഫ്ലാഗുകൾ എന്ത് പറഞ്ഞാലും. ഫ്ലാഗുകൾ ഇതിനകം പ്രവർത്തിച്ചത് സംരക്ഷിക്കുന്നു.

പങ്കിട്ടതല്ല, സമർപ്പിത അക്കൗണ്ട് ഉപയോഗിക്കുക. OpenVPN ഡെവലപ്പർമാർ nobody ഒരു പൊതു ഉദാഹരണമായി ഉപയോഗിക്കുന്ന ശീലത്തിനെതിരെ മുന്നറിയിപ്പ് നൽകുന്നു, കാരണം ഹോസ്റ്റിലെ മറ്റ് സേവനങ്ങൾ ഇതിനകം ആ അക്കൗണ്ടിൽ പ്രവർത്തിക്കുന്നുണ്ടാകാം, നിങ്ങൾ കരുതുന്ന ഒറ്റപ്പെടുത്തൽ അവിടെയില്ല.

പ്രാദേശിക ഭാരം മാറ്റുന്ന സവിശേഷതകൾ, ഉദാഹരണത്തിന് ഡാറ്റാ-ചാനൽ ഓഫ്ലോഡ് അല്ലെങ്കിൽ വ്യത്യസ്തമായി ലിങ്ക് ചെയ്യുന്ന ബിൽഡ്, ഏത് പ്രവർത്തനങ്ങൾ വേണമെന്ന് മാറ്റിയേക്കാം. പാക്കേജ് മാറുമ്പോൾ മാപ്പ് അവലോകനം ചെയ്യുക, എന്തെങ്കിലും തകരുമ്പോൾ മാത്രമല്ല.

പദ്ധതി എഴുതിവയ്ക്കുക, വീണ്ടെടുപ്പ് പ്രവേശനം നിലനിർത്തുക

വിന്യാസ രേഖയിൽ മാനേജർ, തുടക്ക ഐഡന്റിറ്റി, ഉദ്ദേശിച്ച സ്ഥിര ഐഡന്റിറ്റി, ഓരോ അനുവാദവും അത് ആവശ്യപ്പെടുന്ന പ്രവർത്തനത്തോടൊപ്പം പേരിടണം. ആ രേഖയാണ് അടുത്ത മാറ്റത്തെ പരീക്ഷണമല്ലാതെ അവലോകനയോഗ്യമാക്കുന്നത്.

തിരുത്തുമ്പോൾ കൺസോൾ പ്രവേശനം ലഭ്യമായി സൂക്ഷിക്കുക, കാരണം തുടക്കത്തിൽ പരാജയപ്പെടുന്ന യൂണിറ്റ് വിദൂരത്തുനിന്ന് നന്നാക്കാൻ ബുദ്ധിമുട്ടാണ്. മാറ്റം പൂർത്തിയായി പ്രഖ്യാപിക്കുന്നതിന് മുമ്പ് റീസ്റ്റാർട്ടും പൂർണ്ണ റീബൂട്ടും പരിശോധിക്കുക. റീസ്റ്റാർട്ട് അതിജീവിക്കുന്ന യൂണിറ്റും നെറ്റ്വർക്ക് ഉയരുന്നതിന് മുമ്പ് പരാജയപ്പെടാം.

വിജയം എന്നത് മനസ്സിലാക്കിയ കുറഞ്ഞ-അധികാര ജീവിതചക്രമാണ്, root അല്ലാത്ത പേരിൽ യാദൃച്ഛികമായി പ്രവർത്തിക്കുന്ന പ്രക്രിയയല്ല.