nosuid ഒരു VPN സഹായിയെ root ആകുന്നതിൽ നിന്ന് എന്തിന് തടയുന്നു

ഡിസ്ക് എൻക്രിപ്ഷനും nosuid മൗണ്ടും ഒരേ ആശയത്തിന്റെ വകഭേദങ്ങളായി തോന്നുന്നു, എന്നാൽ അവ തമ്മിൽ യാതൊരു ബന്ധവുമില്ല. ഒന്ന് വിശ്രമത്തിലുള്ള ഡാറ്റ സംരക്ഷിക്കുന്നു, മറ്റൊന്ന് പ്രോഗ്രാം ആരംഭിക്കുന്ന നിമിഷത്തിൽ കേർണൽ പ്രിവിലേജ് ബിറ്റിനെ മാനിക്കുമോ എന്ന് തീരുമാനിക്കുന്നു. താൻ പ്രതീക്ഷിക്കുന്ന ഐഡന്റിറ്റിയിൽ എത്താത്ത സഹായി രണ്ടാമത്തേതിനെക്കുറിച്ചാണ് പരാതിപ്പെടുന്നത്. ആദ്യത്തേതാണ് കാരണമെന്ന ധാരണ ആളുകളെ ഒരിക്കലും കേടുപാടുകൾ സംഭവിക്കാത്ത ക്ലയന്റുകൾ വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യാൻ അയയ്ക്കുന്നു.

രണ്ട് ബന്ധമില്ലാത്ത സവിശേഷതകൾ

മെഷീൻ ഓഫ് ആയിരിക്കുമ്പോൾ ബ്ലോക്കുകൾ ആർക്ക് വായിക്കാം എന്നതിന് ഡിസ്ക് എൻക്രിപ്ഷൻ ഉത്തരം നൽകുന്നു. ആരെങ്കിലും ഫയൽ പ്രവർത്തിപ്പിച്ചാൽ കേർണൽ അതിന്റെ മോഡ് ബിറ്റുകളുമായി എന്ത് ചെയ്യുമെന്നതിന് മൗണ്ട് ഓപ്ഷൻ ഉത്തരം നൽകുന്നു. ആദ്യത്തേതിൽ ഒന്നും രണ്ടാമത്തേതിനെ നിയന്ത്രിക്കുന്നില്ല, കൂടാതെ പൂർണ്ണമായി എൻക്രിപ്റ്റ് ചെയ്ത ലാപ്ടോപ്പിന് എല്ലാ നിയന്ത്രണങ്ങളോടും കൂടി ഒരു ഫയൽ സിസ്റ്റം മൗണ്ട് ചെയ്യാൻ കഴിയും.

രണ്ടിനെയും ഒരേ സവിശേഷതയായി വായിക്കുന്നതാണ് എൻക്രിപ്റ്റ് ചെയ്ത ഹോം root പ്രവേശനം തടയുന്നു എന്ന സിദ്ധാന്തം സൃഷ്ടിക്കുന്നത്. ആ സിദ്ധാന്തം നിലനിൽക്കുന്നത് രണ്ട് ലക്ഷണങ്ങളും ഒരേ മെഷീനിൽ പ്രത്യക്ഷപ്പെടുന്നതുകൊണ്ടാണ്, അവയ്ക്ക് ഒരേ കാരണമുള്ളതുകൊണ്ടല്ല.

പരിവർത്തനത്തെ യഥാർത്ഥത്തിൽ അടിച്ചമർത്തുന്നത്

set-user-ID ഉള്ള ഒരു എക്സിക്യൂട്ടബിൾ പുതിയ പ്രോസസ്സിന്റെ ഫലപ്രദമായ ഐഡന്റിറ്റിയെ ഫയലിന്റെ ഉടമയുടേതാക്കി മാറ്റുന്നതെങ്ങനെയെന്ന് execve റഫറൻസ് വിവരിക്കുന്നു. അതേ പേജ് ആ പരിവർത്തനത്തെ അടിച്ചമർത്തുന്ന വ്യവസ്ഥകളും ഗ്രൂപ്പ് ഐഡന്റിഫയറുകൾക്കുള്ള തത്തുല്യമായവയും ലിസ്റ്റ് ചെയ്യുന്നു: no_new_privs ക്രമീകരണം, nosuid ഉപയോഗിച്ച് മൗണ്ട് ചെയ്ത ഫയൽ സിസ്റ്റം, ട്രേസ് ചെയ്യപ്പെടുന്ന പ്രോസസ്സ്. അതേ വ്യവസ്ഥകളിൽ ഫയൽ കഴിവുകൾ അവഗണിക്കപ്പെടുന്നു. ആ നാല് നിയമങ്ങൾ ഇത്തരത്തിലുള്ള മിക്കവാറും എല്ലാ റിപ്പോർട്ടുകളും ഉൾക്കൊള്ളുന്നു.

ls പ്രിന്റ് ചെയ്യുന്ന മോഡ് എന്നും മുഴുവൻ അധികാര കഥയല്ല എന്ന് ആ പട്ടിക വിശദീകരിക്കുന്നു. ഏത് വ്യവസ്ഥയാണ് ഒരു പ്രത്യേക പരാജയ സന്ദേശം ഉണ്ടാക്കിയതെന്ന് അത് പറയുന്നില്ല, കൂടാതെ അപ്ലിക്കേഷൻ അതേ വാക്കുകളിൽ ബന്ധമില്ലാത്ത ഒരു ക്രെഡൻഷ്യൽ പ്രവർത്തനം റിപ്പോർട്ട് ചെയ്തേക്കാം. നിഗമനത്തിൽ എത്തുന്നതിന് മുമ്പ് കൃത്യമായ പ്രോഗ്രാം, ലോഞ്ചർ, പിശകുകളുടെ ക്രമം എന്നിവ രേഖപ്പെടുത്തുക.

പിന്തുണയ്ക്കുന്ന പാക്കേജ് ഇൻസ്റ്റാൾ ചെയ്ത എക്സിക്യൂട്ടബിൾ, അതിന്റെ ഉടമ, അതിന്റെ യഥാർത്ഥ പാത, അത് ഉൾക്കൊള്ളുന്ന ഫയൽ സിസ്റ്റത്തിന്റെ നയം എന്നിവ തിരിച്ചറിയുക. ഡൗൺലോഡ് ഫോൾഡറിലിരിക്കുന്ന ഒരു പകർപ്പ് ഇൻസ്റ്റാൾ ചെയ്ത സഹായിയല്ല, അതിന്റെ മോഡ് എന്ത് പറഞ്ഞാലും.

ഇതിനെക്കുറിച്ച് എന്ത് ചെയ്യരുത്

പരിശോധിക്കാത്ത ഒരു ബൈനറിയിൽ set-user-ID ബിറ്റുകൾ ഇട്ട് നിയന്ത്രണം അപ്രത്യക്ഷമാകുന്നതുവരെ അത് ഇങ്ങോട്ടും അങ്ങോട്ടും നീക്കുന്നത് അറ്റകുറ്റപ്പണിയല്ല. അത് നിങ്ങൾ മനസ്സിലാക്കാത്ത ഒരു നയത്തെ നിങ്ങൾക്ക് ഓഡിറ്റ് ചെയ്യാൻ കഴിയാത്ത പ്രിവിലേജ് കൊണ്ട് മാറ്റിസ്ഥാപിക്കുന്നു, സഹായിയിൽ അതേ സാങ്കേതികത പ്രയോഗിക്കുന്നത് അറിയപ്പെടുന്ന എസ്കലേഷൻ പാതയാണ്. മൗണ്ടിൽ നിന്ന് nosuid നീക്കം ചെയ്യുന്നത് അതിലും മോശമാണ്, കാരണം അത് ആ ഫയൽ സിസ്റ്റത്തിലെ ഓരോ പ്രോഗ്രാമിനെയും ബാധിക്കുന്നു, ഒന്നിനെ മാത്രമല്ല.

പിന്തുണയ്ക്കുന്ന വഴി ഒരു അഡ്മിനിസ്ട്രേറ്റർ നിർവഹിക്കുന്ന ക്ലയന്റിന്റെ ഡോക്യുമെന്റ് ചെയ്ത സഹായി അല്ലെങ്കിൽ സേവന ഇൻസ്റ്റലേഷനാണ്, അത് ബൈനറിയെ നയം പ്രതീക്ഷിക്കുന്നിടത്ത് നിർത്തുന്നു. ഇത് രണ്ടിനു പകരം ഒരു പ്രിവിലേജ് സംവിധാനം നിലനിർത്തുന്നു.

യഥാർത്ഥ ലോഞ്ച് സന്ദർഭം സ്ഥിരീകരിക്കുക

അനുമതി ലഭിച്ച തിരുത്തലിന് ശേഷം, root ഷെല്ലിൽ നിന്നല്ല, ഉൽപ്പന്നം അതിനെ ഓടിക്കുന്ന രീതിയിൽ തന്നെ സഹായിയെ ഓടിക്കുക. root എന്ന നിലയിലുള്ള വിജയം സാധാരണ ഉപയോക്താവ് സഞ്ചരിക്കുന്ന പാതയെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, കൂടാതെ ഈ രണ്ട് സന്ദർഭങ്ങൾ തമ്മിലുള്ള വ്യത്യാസമാണ് പരാജയത്തിന്റെ യഥാർത്ഥ വിഷയം.

തുടർന്ന് സഹായി നിലനിൽക്കുന്ന കാരണമായ നെറ്റ്വർക്ക് പ്രവർത്തനം സ്ഥിരീകരിക്കുക. ആരംഭിക്കുന്നുവെങ്കിലും ഇന്റർഫേസ് കോൺഫിഗർ ചെയ്യാൻ കഴിയാത്ത സഹായി പ്രശ്നത്തെ ഒരു ഘട്ടം കൂടി മുമ്പോട്ട് നീക്കിയിരിക്കുന്നു, പരിഹരിച്ചിട്ടില്ല.

findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helper

മൗണ്ട് ഓപ്ഷനുകളും സഹായിയുടെ ഉടമസ്ഥതയും ഒരേ കുറിപ്പിൽ രേഖപ്പെടുത്തുക. അല്ലെങ്കിൽ ഇത് ഡീബഗ് ചെയ്യുന്ന അടുത്ത വ്യക്തി എൻക്രിപ്ഷൻ സിദ്ധാന്തം വീണ്ടും തുടക്കം മുതൽ ആവർത്തിക്കും.