ടെർമിനലിൽ റൂട്ട്, SELinux-ന് കീഴിൽ നിരസിക്കപ്പെട്ടു: hook എന്തുകൊണ്ട് പരാജയപ്പെടുന്നു

നിങ്ങൾ up സ്ക്രിപ്റ്റ് റൂട്ട് ആയി പ്രവർത്തിപ്പിക്കുന്നു, അത് പൂർത്തിയാകുന്നു, സേവനം അത് വിളിക്കുമ്പോൾ അതേ സ്ക്രിപ്റ്റ് പരാജയപ്പെടുന്നു. ഫയലിന്റെ അനുമതികളിൽ ഒന്നും മാറിയിട്ടില്ല, അതിനാൽ അടുത്ത സ്വാഭാവിക നടപടി അവ വീണ്ടും അയച്ചുകൊടുക്കുക എന്നതാണ്, അത് ഒന്നും ശരിയാക്കുന്നില്ല. SELinux ഹോസ്റ്റിൽ നിർണായക ഘടകം പലപ്പോഴും പ്രോസസ്സ് ആരെന്നതല്ല, മറിച്ച് അത് ഏത് ഡൊമെയ്നിൽ പ്രവർത്തിക്കുന്നു എന്നതാണ്, പരിമിതമായ ഡൊമെയ്നിനുള്ളിലെ റൂട്ടും പരിമിതമായി തുടരുന്നു.

അതേ കമാൻഡ്, രണ്ട് വ്യത്യസ്ത സുരക്ഷാ ഡൊമെയ്നുകൾ

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

അതുകൊണ്ടാണ് രണ്ട് പ്രവർത്തനങ്ങളുടെ താരതമ്യം അവയുടെ സന്ദർഭങ്ങൾ താരതമ്യം ചെയ്യുമ്പോൾ മാത്രം ഉപകാരപ്രദമാകുന്നത്. അതേ കമാൻഡ് ഷെല്ലിൽ നിന്നും hook-ൽ നിന്നും പ്രവർത്തിപ്പിക്കുക; ഷെൽ പതിപ്പ് ബൈനറി നിലനിൽക്കുന്നു എന്നും ആർഗ്യുമെന്റുകൾ ശരിയാണെന്നും തെളിയിക്കുന്നു, എന്നാൽ സേവനത്തിന് അത് പ്രവർത്തിപ്പിക്കാൻ അനുമതിയുണ്ടോ എന്നതിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. രണ്ട് വഴികളിലും പ്രവർത്തിപ്പിച്ച് എക്സിറ്റ് കോഡുകൾ മാത്രമല്ല, ഡൊമെയ്നുകൾ താരതമ്യം ചെയ്യുക. ആ താരതമ്യമാണ് അവ്യക്തമായ അനുമതി പരാതിയെ ഒരു ഡൊമെയ്നിനെയും ഒരു ലേബലിനെയും കുറിച്ചുള്ള കൃത്യമായ ചോദ്യമാക്കി മാറ്റുന്നത്.

ഈ തകരാറിന്റെ പരമ്പരാഗത രൂപം ബാഹ്യ ഉപകരണത്തെ വിളിക്കുന്ന ഒരു സഹായിയാണ്. hook തന്നെ അനുവദിക്കപ്പെട്ടേക്കാം, എന്നാൽ അത് വിളിക്കുന്ന ഉപകരണത്തിന് സേവന ഡൊമെയ്നിന് പ്രവർത്തിപ്പിക്കാൻ കഴിയാത്ത ലേബൽ ഉണ്ട്, അല്ലെങ്കിൽ അതിന്റെ ലേബൽ വിലക്കുന്ന ഡയറക്ടറിയിലേക്ക് എഴുതുന്നു.

hook പിശകിന് അടുത്തായി AVC രേഖ വായിക്കുക

AVC നിരസിക്കൽ കേസ് തീരുമാനിക്കുന്ന ഫീൽഡുകൾ പേരിടുന്നു: പ്രോസസ്സിന്റെ സോഴ്സ് സന്ദർഭം, ഒബ്ജക്റ്റിന്റെ ടാർഗെറ്റ് സന്ദർഭം, ഒബ്ജക്റ്റ് ക്ലാസ്, നിരസിക്കപ്പെട്ട നിർദ്ദിഷ്ട അനുമതി. സിദ്ധാന്തം രൂപീകരിക്കുന്നതിന് മുമ്പ് നാലും വായിക്കുക, കാരണം എക്സിക്യൂട്ടിലെ നിരസിക്കലിനും റൈറ്റിലെ നിരസിക്കലിനും തികച്ചും വ്യത്യസ്ത പരിഹാരങ്ങളാണുള്ളത്.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

സോഴ്സ് സന്ദർഭം സേവനം യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന ഡൊമെയ്നുമായി ഒത്തുപോകണം, ടാർഗെറ്റ് സന്ദർഭം പ്രവർത്തനം സ്പർശിച്ച ഫയലിന്റെയോ ഡയറക്ടറിയുടെയോ ലേബലുമായി ഒത്തുപോകണം. ഇവയിലൊന്ന് നിങ്ങൾ പിന്തുടരുന്ന പിശകുമായി ഒത്തുപോകുന്നില്ലെങ്കിൽ, നിങ്ങൾ മറ്റൊരു സംഭവം വായിക്കുകയാണ്.

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

ലേബൽ, കോൺഫിഗറേഷൻ അല്ലെങ്കിൽ നയം: മൂന്ന് പരിഹാരങ്ങൾ

ആദ്യ പരിഹാരം ഫയലിന്റെ ഇൻസ്റ്റാൾ ചെയ്ത സ്ഥാനവുമായി ഒത്തുപോകാത്ത ലേബലാണ്. cp ഉപയോഗിച്ച് സ്ഥലത്തേക്ക് പകർത്തിയതോ എഡിറ്റർ ഉപയോഗിച്ച് എഴുതിയതോ ആയ സ്ക്രിപ്റ്റ് സേവന ഡൊമെയ്നിന് ഉപയോഗിക്കാൻ കഴിയാത്ത ഡിഫോൾട്ട് ലേബൽ വഹിച്ചേക്കാം, പ്രതീക്ഷിത സന്ദർഭം പുനഃസ്ഥാപിക്കുന്നത് നയത്തെ തൊടാതെ അത് ശരിയാക്കുന്നു.

രണ്ടാമത്തേത് കോൺഫിഗറേഷനാണ്. വിതരണം പ്രവർത്തനം നടത്താൻ പിന്തുണയ്ക്കുന്ന മാർഗവും, സഹായിക്ക് രേഖപ്പെടുത്തിയ ഡയറക്ടറിയും, അല്ലെങ്കിൽ ഇതിനകം അനുവദിക്കുന്ന പുതുക്കിയ നയ പാക്കേജും നൽകിയേക്കാം. നിങ്ങളുടെ ലേഔട്ട് പിന്തുണയ്ക്കുന്നതിലേക്ക് മാറ്റുന്നത് നയമെഴുതുന്നതിനേക്കാൾ വിലകുറഞ്ഞതാണ്, അപ്ഡേറ്റുകളെ അതിജീവിക്കുന്നു.

മൂന്നാമത്തേത് യഥാർത്ഥത്തിൽ കാണാത്ത ഒരു നിയമമാണ്, അത് അവസാന മാർഗമായിരിക്കണം. ഓഡിറ്റ് ടൂളുകൾ ഉപയോഗിച്ച് ഒരു സ്ഥാനാർത്ഥി സൃഷ്ടിക്കുക, അത് യഥാർത്ഥത്തിൽ എന്ത് അനുവദിക്കുന്നു എന്ന് വായിക്കുക, നിങ്ങൾ നിരീക്ഷിച്ച പ്രവർത്തനത്തിലേക്കും ഡൊമെയ്നിലേക്കും അത് ചുരുക്കുക, ഉൽപാദനത്തിന് അടുക്കുന്നതിന് മുമ്പ് മറ്റൊരാളെ അത് അവലോകനം ചെയ്യിക്കുക.

പഴയ allow മൊഡ്യൂൾ ഉത്തരമല്ലാത്തതെന്തുകൊണ്ട്

ഈ തകരാറിനുള്ള തിരയൽ ഫലങ്ങൾ റെഡിമെയ്ഡ് മൊഡ്യൂളുകൾ കൊണ്ട് നിറഞ്ഞിരിക്കുന്നു, പലപ്പോഴും hook ഇനി വിളിക്കാത്ത ഒരു ഉപകരണത്തിന്. ഒന്ന് ഇൻസ്റ്റാൾ ചെയ്യുന്നത് നിങ്ങളുടെ നിരസിക്കലുമായി ബന്ധമില്ലാത്ത അനുമതികൾ നൽകുന്നു, ശാശ്വതമായ ഒരു ദ്വാരം ചേർക്കുമ്പോൾ യഥാർത്ഥ പൊരുത്തക്കേട് അതിന്റെ സ്ഥാനത്ത് നിർത്തുന്നു.

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

അനുശാസനാത്മകമായ താരതമ്യം നിങ്ങൾക്ക് വായിക്കാൻ കഴിയുന്ന നിരസിക്കലും നിങ്ങൾ നിർദ്ദേശിക്കുന്ന മാറ്റവും തമ്മിലാണ്. Red Hat-ന്റെ SELinux പ്രശ്നപരിഹാര ഗൈഡ് ലേബലിംഗും കോൺഫിഗറേഷൻ പരിശോധനകളും ജനറേറ്റ് ചെയ്ത നയത്തിന് മുന്നിൽ വയ്ക്കുന്നത് ഇതേ കാരണത്താലാണ്. രേഖയിൽ അനുയോജ്യമായ നിരസിക്കൽ ഇല്ലെങ്കിൽ, SELinux ഒരുപക്ഷേ നിങ്ങളുടെ പ്രശ്നമല്ല, കൂടാതെ പാത, സാൻഡ്ബോക്സ് അല്ലെങ്കിൽ അനുമതി പ്രശ്നങ്ങൾ ഇപ്പോഴും തുറന്നിരിക്കുന്നു.