OpenVPN-ൽ chroot പരാജയപ്പെടുന്നു: AppArmor നിയമമോ അനുമതിയോ?

ഡീമൺ chroot പരാജയം രേഖപ്പെടുത്തുന്നു, പ്രൊഫൈൽ ഇതിനകം ഉദാരമായി കാണപ്പെടുന്നു, അതിനാൽ പ്രലോഭനീയമായ പരിഹാരം ഒരു പാത നിയമം വിശാലമാക്കി പുനരാരംഭിക്കുകയാണ്. ഇത് സാധാരണയായി ഒന്നും മാറ്റുന്നില്ല, കാരണം chroot നിയന്ത്രിക്കുന്നത് പ്രൊഫൈലിന് ഒരിക്കലും നൽകാൻ കഴിയാത്ത ഒരു പ്രിവിലേജ് ആണ്. ഏത് പാളിയിൽ സ്പർശിക്കണമെന്ന് തീരുമാനിക്കാൻ മൂന്ന് വിലകുറഞ്ഞ പരിശോധനകൾ വേണം: പ്രോസസിന് എന്ത് സൂക്ഷിക്കാൻ അനുവാദമുണ്ട്, നയം എന്ത് അനുവദിക്കുന്നു, ആ രണ്ടും പ്രസക്തമാകുന്നതിന് മുമ്പ് ലോഞ്ചർ എന്ത് നീക്കി.

രണ്ട് വേറിട്ട കവാടങ്ങൾ, ഒന്ന് മാത്രം AppArmor-ന്റേത്

chroot പ്രോസസ് പ്രവർത്തിക്കുന്ന ഉപയോക്തൃ നാമസ്ഥലത്ത് CAP_SYS_CHROOT ആവശ്യപ്പെടുന്നു. ഇത് സാധാരണ Linux പ്രിവിലേജ് ആണ്, കോൾ പാതകളുമായി എന്തെങ്കിലും ചെയ്യുന്നതിന് മുമ്പ് കർണൽ ഇത് പരിശോധിക്കുന്നു. വേറിട്ട്, നിർബന്ധിത AppArmor പ്രൊഫൈൽ പ്രോസസിൽ കഴിവ് ഉണ്ടായിരുന്നാലും അത് നിഷേധിക്കാം, കാരണം നിർബന്ധിത നയം ക്രെഡൻഷ്യലുകൾക്ക് പകരമല്ല, അവയ്ക്കൊപ്പം പരിഗണിക്കുന്നു. ഈ വ്യത്യാസം പ്രായോഗികമായി പ്രധാനമാണ്: രണ്ട് പാളികളും വെവ്വേറെ ഫയലുകളിലാണ്, സാധാരണയായി വെവ്വേറെ ആളുകൾ അവ പരിപാലിക്കുന്നു.

ആ രണ്ട് കവാടങ്ങളും ഒരേ errno-യിൽ പരാജയപ്പെടുന്നു. രണ്ടും EPERM ഉത്പാദിപ്പിക്കുന്നു, രണ്ടും ഡീമൺ ലോഗിൽ പൊതുവായ അനുമതി പരാതിയായി പ്രത്യക്ഷപ്പെടുന്നു, അതിനാൽ പ്രൊഫൈലിന്റെ ഉള്ളടക്കം ഊഹിക്കുന്നത് ഇത്രയധികം സമയം പാഴാക്കുന്നു. നിങ്ങൾ ചേർക്കാൻ പോയ പാത നിയമം chroot വിജയിച്ചതിന് ശേഷമുള്ള ഫയൽ പ്രവേശനം നിയന്ത്രിക്കുന്നു; പ്രവർത്തനം ഒട്ടുമിക്ക അനുവദനീയമാണോ എന്നതുമായി അതിന് ബന്ധമില്ല.

മൂന്നാമത്തെ കവാടം രണ്ടിനും മുകളിലാണ്. സേവന മാനേജർ അല്ലെങ്കിൽ ഒരു റാപ്പർ പ്രോസസിനെ അതിന്റെ പരിധി ഗണത്തിൽ കഴിവില്ലാതെ ആരംഭിച്ചിട്ടുണ്ടെങ്കിൽ, ഏത് AppArmor മാറ്റവും അത് തിരികെ കൊണ്ടുവരാൻ കഴിയില്ല, കൂടാതെ പ്രൊഫൈലിൽ കഴിവുകൾ ചേർക്കുന്നത് കർണൽ ബഹുമാനിക്കാത്ത ഒരു ഉദ്ദേശ്യം രേഖപ്പെടുത്തുക മാത്രമാണ്.

നയം തിരുത്തുന്നതിന് മുമ്പ് പ്രിവിലേജ് അവസ്ഥ വായിക്കുക

സജീവമാണെന്ന് നിങ്ങൾ വിശ്വസിക്കുന്ന കോൺഫിഗറേഷനിൽ നിന്നല്ല, പ്രവർത്തിക്കുന്ന പ്രോസസിൽ നിന്ന് തുടങ്ങുക. അവസ്ഥാ ഫയൽ അഞ്ച് കഴിവ് മാസ്കുകളും no-new-privileges ഫ്ലാഗും വെളിപ്പെടുത്തുന്നു, അവ വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff ആണ് കോളിന് പ്രധാനമായ ഗണം: CapBnd-ൽ ഉണ്ടെങ്കിലും CapEff-ൽ ഇല്ലാത്ത കഴിവ് ഉപരിതലം അനുവദിക്കുന്നു, എന്നാൽ ഇപ്പോൾ കൈവശം ഇല്ല. ബൈനറി സാധാരണ setuid അർത്ഥത്തിൽ പ്രിവിലേജുള്ളതല്ലാത്തപ്പോൾ CapAmb പ്രധാനമാണ്, കാരണം പരിസ്ഥിതി കഴിവുകളാണ് ഒരു സേവനം ഫയൽ കഴിവുകളില്ലാതെ exec-ന് കുറുകെ പ്രിവിലേജ് നിലനിർത്തുന്ന വഴി. CapInh-ൽ exec-ന് കുറുകെ പാരമ്പര്യമായി ലഭിക്കാവുന്ന ബിറ്റുകൾ ഉണ്ട്, പക്ഷേ പ്രവർത്തിപ്പിക്കുന്ന ഫയലിന്റെ പാരമ്പര്യ ഗണം അനുവദിക്കുമ്പോൾ മാത്രം, അതിനാൽ അവിടെയുള്ള ഒരു ബിറ്റ് തനിയെ ഒന്നും നൽകുന്നില്ല.

തുടർന്ന് ഏത് പ്രൊഫൈൽ യഥാർത്ഥത്തിൽ ഘടിപ്പിച്ചിരിക്കുന്നു എന്ന് ഉറപ്പാക്കുക. ഒരു പ്രോസസ് നിങ്ങൾ പ്രതീക്ഷിക്കാത്ത പ്രൊഫൈൽ പേരിൽ തടഞ്ഞിരിക്കാം, പ്രത്യേകിച്ച് ഒരു വിതരണം അതിന്റെ സ്വന്തം യൂണിറ്റ് ഫയലും പ്രൊഫൈലും ഒരുമിച്ച് അയയ്ക്കുമ്പോൾ, /proc/PID/attr/current വായിക്കുന്നത് അത് ഒരു വരിയിൽ തീർപ്പാക്കുന്നു. നിങ്ങൾ തിരുത്തിയ ഫയലിനെ കർണൽ റിപ്പോർട്ട് ചെയ്യുന്ന പ്രൊഫൈലുമായി താരതമ്യപ്പെടുത്തുന്നത് കാരണം പരിഹരിക്കുന്നതും ആരും ലോഡ് ചെയ്യാത്ത ഫയൽ തിരുത്തുന്നതും തമ്മിലുള്ള വ്യത്യാസം ആണ്.

ഓഡിറ്റ് ട്രെയിൽ അങ്ങനെ പറയുമ്പോൾ മാത്രം കഴിവ് നിയമം ചേർക്കുക

കർണൽ, ഓഡിറ്റ് രേഖകൾ നിഷേധിച്ച പാളിയെ പേരിടുന്നു. പ്രവർത്തനം capable എന്നും പേര് sys_chroot എന്നും ഉള്ള, അത് സൃഷ്ടിച്ച പ്രൊഫൈലിനൊപ്പമുള്ള നിഷേധം തിരയുക. ആ രേഖ ഉണ്ടെങ്കിൽ പ്രോസസിന് കഴിവ് ഇതിനകം ഉണ്ടായിരുന്നു, AppArmor അത് നിഷേധിച്ചു, ലക്ഷ്യമിട്ട മാറ്റം യഥാർത്ഥ പ്രൊഫൈലിനുള്ളിലെ ഒരു കഴിവ് നിയമമാണ്:

capability sys_chroot,

അത് യഥാർത്ഥത്തിൽ ഘടിപ്പിച്ച പ്രൊഫൈലിൽ ഒരു ഭാഗമായി സൂക്ഷിക്കുക, കൂടാതെ ബന്ധമില്ലാത്ത ഒരു ട്യൂട്ടോറിയലിൽ നിന്ന് നിയമം പകർത്തുന്നതിന് പകരം കീവേഡ് apparmor.d പ്രൊഫൈൽ റഫറൻസുമായി പരിശോധിക്കുക. പങ്കിട്ട include-ൽ ഇടുന്നത് ആ ഫയൽ വലിക്കുന്ന എല്ലാ തടഞ്ഞ പ്രോഗ്രാമിനും അത് നൽകുന്നു, പ്രൊഫൈൽ complain മോഡിലേക്ക് മാറ്റുന്നത് ഇത് പരിഹരിക്കുന്നതിന് പകരം അടുത്ത നിഷേധം മറയ്ക്കുന്നു. പ്രൊഫൈൽ നിയമം ഒരു നയ നിഷേധം നീക്കുന്നു; അത് പ്രിവിലേജ് സൃഷ്ടിക്കുന്നില്ല, അതിനാൽ ഫലപ്രദമായ ഗണത്തിൽ ഒരിക്കലും CAP_SYS_CHROOT ഇല്ലാതിരുന്ന പ്രോസസ് നിയമം ഉണ്ടായിരുന്നാലും പരാജയപ്പെടും.

ഓഡിറ്റ് രേഖയിൽ AppArmor നിഷേധം ഒട്ടുമില്ലെങ്കിൽ, പ്രൊഫൈൽ തിരുത്തുന്നത് നിർത്തുക. നിങ്ങൾ ക്രെഡൻഷ്യൽ പ്രശ്നം കാണുന്നു, ബാക്കിയുള്ള ജോലി യൂണിറ്റ് ഫയലിലോ മാതൃ പ്രോസസിലോ ആണ്, നയ ഭാഷയിലല്ല.

സേവന മാനേജർ സ്വന്തം ഉപരിതലം സൂക്ഷിക്കുന്നു

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

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

ഇവിടെ ക്രമവും പ്രധാനമാണ്. ആദ്യം യൂണിറ്റിന്റെ ഉപരിതലം മാറ്റുക, CapEff-ൽ ഇപ്പോൾ ആ ബിറ്റ് ഉണ്ടെന്ന് ഉറപ്പാക്കുക, അതിന് ശേഷം മാത്രം AppArmor ഇപ്പോഴും നിഷേധിക്കുന്നുണ്ടോ എന്ന് തീരുമാനിക്കുക. രണ്ട് മാറ്റങ്ങളും ഒരുമിച്ച് ചെയ്യുന്നത് പരാജയം തുടർന്നാൽ നിങ്ങളെ വീണ്ടും ഊഹത്തിൽ നിർത്തുന്നു.

നിഷേധം മാറിയതിന് ശേഷം ജയിൽ തന്നെ പരിശോധിക്കുക

വിജയകരമായ chroot റൂട്ട് നീക്കുന്നു, അതിനാൽ ഡീമൺ പിന്നീട് സ്പർശിക്കുന്ന ഓരോ പാതയും പുതിയ വൃക്ഷത്തിനുള്ളിൽ പരിഹരിക്കപ്പെടുന്നു. കാണാത്ത കോൺഫിഗറേഷൻ, ഇല്ലാത്ത ഉപകരണ നോഡ്, പകർത്താത്ത സർട്ടിഫിക്കറ്റ് ഡയറക്ടറി എന്നിവ ഇപ്പോൾ ഫയൽ പിശകായി പ്രത്യക്ഷപ്പെടും, ആ പിശക് കഴിവിന്റെ പ്രശ്നമല്ല, ക്രമീകരണത്തിന്റെ പ്രശ്നമാണ്. മറ്റൊരു വിശാല അനുമതി ചേർക്കുന്നതിന് പകരം അടുത്ത സംഭവം വായിക്കുക. ഈ നീക്കം ആപേക്ഷിക പാതയുടെ അർത്ഥവും മാറ്റുന്നു, അതിനാലാണ് കടുപ്പമാക്കൽ ഗൈഡുകൾ ഡീമൺ കോൺഫിഗറേഷനിൽ സമ്പൂർണ പാതകൾ നിർബന്ധിക്കുന്നത്.

chroot എന്ത് ചെയ്യുന്നില്ല എന്ന് ഓർക്കുന്നതും സഹായകമാണ്. ഇത് ഒരു പാത അതിർത്തിയാണ്, സാൻഡ്ബോക്സല്ല: പ്രിവിലേജ് നിലനിർത്തുന്ന പ്രോസസിന് അതിൽ നിന്ന് രക്ഷപ്പെടാം, അതിനാലാണ് കഴിവ് സാധാരണയായി കോളിന് ശേഷം വീഴ്ത്തുന്നത്, അതിനാലാണ് ഒറ്റപ്പെടുത്തൽ ഡീമണിന് ചുറ്റും തുടരേണ്ടത്. AppArmor പ്രൊഫൈൽ, കഴിവ് പരിധി ഗണം, ഫയൽസിസ്റ്റം നിയന്ത്രണങ്ങൾ എന്നിവ ഒരുമിച്ച് നിലനിർത്തുന്നതാണ് ഈ അഭ്യാസത്തിന്റെ ലക്ഷ്യം, സേവനം ആരംഭിച്ചാൽ നീക്കം ചെയ്യേണ്ട ബാക്കിയല്ല.

തീരുമാന നിയമം ചെറുതാണ്. ഓഡിറ്റ് രേഖ AppArmor എന്ന് പേരിട്ടാൽ, ഘടിപ്പിച്ച പ്രൊഫൈലിൽ ഒരു കഴിവ് നിയമം ചേർക്കുക. ഫലപ്രദ ഗണം ശൂന്യമാണെങ്കിൽ, യൂണിറ്റിന്റെ ഉപരിതലവും പ്രിവിലേജ് വീഴ്ത്തുന്ന ക്രമവും ശരിയാക്കുക. പ്രൊഫൈൽ നിങ്ങൾ തിരുത്തിയതല്ലെങ്കിൽ, തിരുത്തുന്നത് നിർത്തി യഥാർത്ഥമായത് കണ്ടെത്തുക.