VPN സർട്ടിഫിക്കറ്റ് നീക്കുന്നത് അതിന്റെ SELinux ലേബൽ എന്തുകൊണ്ട് തകർക്കുന്നു

സർട്ടിഫിക്കറ്റുകൾ ശരിയായ ഡയറക്ടറിയിൽ വായിക്കാവുന്ന മോഡും root ഉടമസ്ഥതയും ഉള്ളതായിരിക്കാം, എന്നിട്ടും ഫയൽ തുറക്കാനാകുന്നില്ലെന്ന് സേവനം റിപ്പോർട്ട് ചെയ്യാം. SELinux സിസ്റ്റത്തിൽ ഈ സംയോജനം അനുമതികളെയല്ല, ഒരു നിർദ്ദിഷ്ട സംവിധാനത്തെ സൂചിപ്പിക്കുന്നു. ലേബൽ ഫയലിനൊപ്പം സഞ്ചരിച്ചു, കാരണം പേരുമാറ്റം പുതിയ ഒരു വസ്തുവിനെ സൃഷ്ടിക്കുന്നില്ല. inode പഴയ പാതയിൽ ഉണ്ടായിരുന്ന സുരക്ഷാ സന്ദർഭം നിലനിർത്തി, പുതിയ പാതയുടെ നയത്തിന് സ്വന്തം സന്ദർഭം അനുവദിക്കാനുള്ള അവസരം ലഭിച്ചില്ല.

പേരുമാറ്റം യഥാർത്ഥത്തിൽ ഒരു ലേബലിനോട് എന്ത് ചെയ്യുന്നു

ഒരു ഫയൽ അതിന്റെ SELinux സന്ദർഭം inode-നോട് ബന്ധിപ്പിച്ച ആട്രിബ്യൂട്ട് ഡാറ്റയായി വഹിക്കുന്നു. ഒരു ഫയൽ സിസ്റ്റത്തിനുള്ളിൽ പേരുമാറ്റം ഡയറക്ടറി എൻട്രി മാറ്റുന്നു, മറ്റൊന്നുമല്ല, ഇത് വേഗതയേറിയതും ആറ്റോമികവുമാണ്, സന്ദർഭം നീക്കത്തെ അതിജീവിക്കുന്നതിന്റെ കാരണവും ഇതുതന്നെ. ഒരു നയവും ചോദിക്കപ്പെടുന്നില്ല, ഒരു സ്ഥിരസ്ഥിതിയും പ്രയോഗിക്കപ്പെടുന്നില്ല, ഒരു മുന്നറിയിപ്പും അച്ചടിക്കപ്പെടുന്നില്ല.

പകർത്തൽ വ്യത്യസ്തമായി പെരുമാറുന്നു. ഒരു പകർപ്പ് ലക്ഷ്യ ഡയറക്ടറിയിൽ പുതിയ inode സൃഷ്ടിക്കുന്നു, നയം ആ ഡയറക്ടറിയുടെ തരത്തിൽ നിന്ന് സന്ദർഭം അനുവദിക്കുന്നു, അതിനാൽ പകർത്തിയ സർട്ടിഫിക്കറ്റ് സാധാരണയായി ശരിയായ ലേബൽ നേടുന്നു, നീക്കിയത് തെറ്റായി തുടരുന്നു. ഈ ഒരു വ്യത്യാസം ഈ തരത്തിലുള്ള ടിക്കറ്റുകളിലെ മിക്ക ആശയക്കുഴപ്പവും വിശദീകരിക്കുന്നു.

ഫയൽ സിസ്റ്റങ്ങൾക്കിടയിലുള്ള നീക്കങ്ങൾ പകർത്തൽ അർത്ഥശാസ്ത്രത്തിലേക്ക് മടങ്ങുന്നു, അതിനാൽ അതേ കമാൻഡ് രണ്ട് മെഷീനുകളിൽ /etc സ്വന്തം വോള്യൂമിൽ ഉണ്ടോ എന്നതിനെ ആശ്രയിച്ച് വ്യത്യസ്തമായി പെരുമാറാം. ഉപകരണം വിശ്വസനീയമല്ലെന്ന് തീരുമാനിക്കുന്നതിന് മുമ്പ് ഇത് പരിശോധിക്കുക. മൗണ്ട് പട്ടികയിലേക്ക് ഒരു നോട്ടം നിങ്ങൾ ഏത് തരത്തിലുള്ള നീക്കമാണ് നടത്തിയതെന്ന് പറയും.

നിലവിലെ ലേബൽ പ്രതീക്ഷിതമായതിനെതിരെ വായിക്കുക

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

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

വിശ്വസിക്കേണ്ടത് ഡ്രൈ റൺ ആണ്, കാരണം നയത്തിൽ നിന്ന് വ്യതിചലിക്കുന്ന സന്ദർഭമുള്ള ഓരോ ഫയലും അത് പേരെടുത്ത് പറയുന്നു, സിസ്റ്റത്തെ സ്പർശിക്കാതെ വിടുന്നു. സർട്ടിഫിക്കറ്റ് ആ പട്ടികയിൽ പ്രത്യക്ഷപ്പെട്ടാൽ, പാത അർത്ഥമാക്കുന്നതും ഫയൽ അവകാശപ്പെടുന്നതും തമ്മിലുള്ള പൊരുത്തക്കേട് നിങ്ങൾ കണ്ടെത്തി. പ്രത്യക്ഷപ്പെട്ടില്ലെങ്കിൽ, ലേബൽ ഇതിനകം നയം ആഗ്രഹിക്കുന്നതാണ്, നിങ്ങളുടെ സമയം മറ്റെവിടെയോ സംബന്ധിക്കുന്നു.

തുടർന്ന് വ്യത്യാസം യഥാർത്ഥ നിരസിക്കലുമായി ബന്ധിപ്പിക്കുക. പൊരുത്തക്കേട് തെറ്റായ ലേബലിന്റെ തെളിവാണ്, സേവനം അതുകൊണ്ട് പരാജയപ്പെട്ടു എന്നതിന്റെ തെളിവല്ല, ലോഗിൽ അനുബന്ധ നിരസിക്കൽ ഇല്ലാതെ പ്രയോഗിച്ച തിരുത്ത് അധിക ഘട്ടങ്ങളുള്ള ഒരു ഊഹമാണ്.

ഒഴിവുകഴിവ് കണ്ടുപിടിക്കുന്നതിനുപകരം മാപ്പിംഗ് പുനഃസ്ഥാപിക്കുക

സാധാരണ സ്ഥാനത്തിന് നയം ഇതിനകം പാത മാപ്പ് ചെയ്തിട്ടുണ്ട്, അതിനാൽ restorecon അത് പ്രയോഗിക്കുന്നു, ജോലി തീർന്നു. നിങ്ങൾ നന്നാക്കുന്ന ഡയറക്ടറിയിൽ പരിധി നിർത്തുക; മുഴുവൻ ഫയൽ സിസ്റ്റവും വീണ്ടും ലേബൽ ചെയ്യുന്നത് മന്ദഗതിയിലാണ്, തടസ്സപ്പെടുത്തുന്നതാണ്, യഥാർത്ഥ പിശകിനെ വളരെ വലിയ മാറ്റത്തിനടിയിൽ അത് കുഴിച്ചിടുന്നു.

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

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon ഒരു മാപ്പിംഗ് പ്രയോഗിക്കുന്നു; അതിന് ഒന്ന് കണ്ടുപിടിക്കാനാകില്ല. പാതയെ വിവരിക്കുന്ന ഒരു നിയമവുമില്ലെങ്കിൽ, പുനഃസ്ഥാപിക്കാൻ ഒന്നുമില്ല, അതുകൊണ്ടാണ് വീണ്ടും ലേബൽ ചെയ്യലിന് മുമ്പ് സ്ഥിരമായ മാപ്പിംഗ് നിലനിൽക്കേണ്ടത്. ഏത് കോൺഫിഗറേഷനാണ് ആ മാപ്പിംഗ് സ്വന്തമാക്കുന്നതെന്ന് രേഖപ്പെടുത്തുക, അല്ലാത്തപക്ഷം പിന്നീടുള്ള നീക്കമോ പാക്കേജ് അപ്ഡേറ്റോ വീണ്ടും ലേബൽ ചെയ്യലോ വീണ്ടും തകരാറ് സൃഷ്ടിക്കും, അടുത്ത വ്യക്തി പൂജ്യത്തിൽ നിന്ന് തുടങ്ങും.

chcon എന്തുകൊണ്ട് പരിഹാരമല്ല

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

അതിലും മോശം, അത് തെറ്റായ പാഠം പഠിപ്പിക്കുന്നു: അടിസ്ഥാന മാപ്പിംഗ് ഇപ്പോഴും ഇല്ല, അതിനാൽ തകരാർ ആഴ്ചകൾക്കുശേഷം വ്യക്തമായ ട്രിഗറും ആ പരിഹാരത്തിന്റെ ഓർമ്മയും ഇല്ലാതെ മടങ്ങുന്നു. chcon ഒരു സിദ്ധാന്തം സ്ഥിരീകരിക്കാനുള്ള താൽക്കാലിക പരീക്ഷണമായി മാത്രം ഉപയോഗിക്കുക, പിന്നീട് അതിനെ അടുത്ത വീണ്ടും ലേബൽ ചെയ്യലിനെ അതിജീവിക്കുന്ന മാപ്പിംഗ് കൊണ്ട് മാറ്റി, പകരം യഥാർത്ഥത്തിൽ സ്ഥാനത്തുണ്ടോ എന്ന് പരിശോധിക്കുക.

ലേബൽ ശരിയായിരിക്കുമ്പോൾ പ്രവേശനം ഇപ്പോഴും പരാജയപ്പെടുമ്പോൾ

മാതൃ ഡയറക്ടറികളിൽ നിന്ന് ആരംഭിക്കുക. പാതയുടെ ഓരോ ഘടകത്തിലും ട്രാവേഴ്സൽ അനുമതി പരിശോധിക്കുന്നു, അതിനാൽ സേവനത്തിന് പ്രവേശിക്കാനാകാത്ത ഡയറക്ടറിക്കുള്ളിൽ ശരിയായി ലേബൽ ചെയ്ത സർട്ടിഫിക്കറ്റും വായിക്കാനാകാതെ തുടരുന്നു. SELinux-ഉം സാധാരണ അനുമതിയും ഓരോ ഘട്ടവും അനുവദിക്കണം, ഒന്ന് നന്നാക്കുന്നത് മറ്റൊന്നിനെ നന്നാക്കുന്നില്ല.

തുടർന്ന് പ്രോസസ് ഐഡന്റിറ്റിയും സേവനത്തിന്റെ സ്വന്തം സാൻഡ്ബോക്സിംഗും പരിശോധിക്കുക. നിയന്ത്രിത സാൻഡ്ബോക്സുള്ള ഒരു യൂണിറ്റ് നയം സന്തോഷത്തോടെ അനുവദിക്കുന്ന ഒരു ഫയലിലേക്കുള്ള പ്രവേശനം നിരസിക്കാം, ലോഗ് വരിയിൽ നിന്ന് രണ്ട് കാരണങ്ങളും ഒരുപോലെ തോന്നുന്നു. യഥാർത്ഥത്തിൽ ഏത് പ്രോസസാണ് ചോദിക്കുന്നതെന്ന് സ്ഥിരീകരിക്കുക, നിങ്ങൾ ഊഹിക്കുന്ന പ്രോസസല്ല.

dontaudit നിയമങ്ങൾക്ക് നിരസിക്കൽ സന്ദേശങ്ങൾ അടിച്ചമർത്താനാകുമെന്ന് ഓർക്കുക, അതിനാൽ ശൂന്യമായ ഓഡിറ്റ് ലോഗ് തെളിവല്ല, ദുർബലമായ തെളിവാണ്. നയം ശരിയെന്ന് തോന്നിയാലും പ്രവേശനം പരാജയപ്പെട്ടാൽ, വിശാലമായ അനുമതി മൊഡ്യൂൾ സൃഷ്ടിക്കുന്നതിന് മുമ്പ് അന്വേഷിക്കുക, ലക്ഷണം അപ്രത്യക്ഷമാകാൻ SELinux പ്രവർത്തനരഹിതമാക്കരുത്. രണ്ട് ഷോർട്ട്കട്ടുകളും പ്രവർത്തിക്കുന്നതായി തോന്നുന്ന ഒരു സിസ്റ്റവും ആർക്കും വിവരിക്കാനാകാത്ത ഒരു സുരക്ഷാ നിലപാടും നൽകുന്നു. ഒരു ചെറിയ അന്വേഷണം രണ്ടിനെക്കാളും നല്ലതാണ്.