PAM പ്രമാണീകരണം കൈകൊണ്ട് പ്രവർത്തിക്കുന്നു, പക്ഷേ OpenVPN സേവനമായി പരാജയപ്പെടുന്നു
root ഷെല്ലിൽ നിന്ന് പ്രവർത്തിക്കുന്നതും systemd-ന് കീഴിൽ പരാജയപ്പെടുന്നതുമായ PAM ലോഗിൻ പാസ്വേഡിനല്ല, സഹായിയിലേക്കാണ് വിരൽ ചൂണ്ടുന്നത്. അനുമതികൾ, ഫയൽ ആക്സസ്, SELinux എന്നിവ വേർതിരിക്കുക.
PAM വഴിയുള്ള പ്രമാണീകരണം നിങ്ങൾ ക്ലയന്റ് കൈകൊണ്ട് പ്രവർത്തിപ്പിക്കുമ്പോൾ വിജയിക്കാം, systemd അതേ പ്രൊഫൈൽ ആരംഭിക്കുമ്പോൾ AUTH_FAILED ഉപയോഗിച്ച് പരാജയപ്പെടാം. ആ പ്രവർത്തനങ്ങൾക്കിടയിൽ പാസ്വേഡ് മാറുന്നില്ല; മാറുന്നത് PAM-നോട് ചോദ്യം ചോദിക്കുന്ന പ്രക്രിയയെ ചുറ്റിപ്പറ്റിയുള്ള നിയന്ത്രണങ്ങളുടെ കൂട്ടമാണ്. PAM സ്വന്തം ക്രെഡൻഷ്യലുകൾ മാറ്റാനുള്ള കഴിവുള്ള ഒരു സഹായി വഴി ഉത്തരം നൽകുന്നു, കഠിനമാക്കിയ unit നീക്കം ചെയ്യുന്നത് കൃത്യം അതാണ്. കഴിവുകളുടെ പട്ടിക തൊടുന്നതിന് മുമ്പ് ആ സഹായിയെയും അതിന് ആവശ്യമായ അതിർത്തിയെയും കണ്ടെത്തുക.
unix_chkpwd ആണ് PAM ചോദ്യത്തിന് ഉത്തരം നൽകുന്ന ബൈനറി
പ്രാദേശിക പാസ്വേഡ് പ്രമാണീകരണത്തോടെ, pam_unix അപൂർവ്വമായേ hash ഫയൽ സ്വയം വായിക്കൂ. അത് unix_chkpwd പ്രവർത്തിപ്പിക്കുന്നു, അതിനെ വിതരണങ്ങൾ setuid root അല്ലെങ്കിൽ setgid shadow ആയി ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതുവഴി /etc/shadow വായിക്കാൻ യാതൊരു കാര്യവുമില്ലാത്ത ഒരു പ്രക്രിയയുടെ പേരിൽ ഒരു പാസ്വേഡ് പരിശോധിക്കാം. ആ ഐഡന്റിറ്റി നേടാനുള്ള കഴിവ് നീക്കം ചെയ്താൽ സഹായിക്ക് പരിശോധന പൂർത്തിയാക്കാൻ കഴിയില്ല, അതിനാൽ മൊഡ്യൂൾ സാധാരണ പ്രമാണീകരണ പരാജയം തിരികെ നൽകുന്നു.
പിന്നീട് പരാജയം ക്ലയന്റ് കാണാൻ കഴിയുന്ന എല്ലാ ലോഗിലും ക്രെഡൻഷ്യൽ പ്രശ്നം പോലെ തോന്നുന്നു. അതാണ് കെണി: ക്ലയന്റ് PAM അതിനോട് പറഞ്ഞത് റിപ്പോർട്ട് ചെയ്യുന്നു, PAM സ്റ്റാക്ക് ഇല്ല എന്ന് പറഞ്ഞു എന്ന് മാത്രം റിപ്പോർട്ട് ചെയ്യുന്നു. root ആയി സഹായിയെ കൈകൊണ്ട് പ്രവർത്തിപ്പിക്കുന്നതും ഒന്നും തെളിയിക്കുന്നില്ല, കാരണം അത് സേവനം ഒരിക്കലും ഉപയോഗിക്കാത്ത ഒരു പ്രത്യേകാവകാശ പാത പരീക്ഷിക്കുന്നു. systemd യഥാർത്ഥത്തിൽ ലോഡ് ചെയ്ത unit വായിക്കുക, തുടർന്ന് നടത്തിയ ശ്രമത്തിനായി സിസ്റ്റം ലോഗ് വായിക്കുക. ഈ രണ്ട് കാഴ്ചകൾ സാൻഡ്ബോക്സ് പ്രശ്നത്തെ തെറ്റായ പാസ്വേഡ് പ്രശ്നത്തിൽ നിന്ന് വേർതിരിക്കുന്നു.
പാസ്വേഡ് ലോഗ് വായിക്കുന്നതിന് മുമ്പ് unit വായിക്കുക
പാക്കേജ് ചെയ്ത unit നിങ്ങൾ എഴുതാത്ത ഒരു drop-in വഹിച്ചേക്കാം, ഫലപ്രദമായ കോൺഫിഗറേഷൻ ലയിപ്പിച്ച ഫലമാണ്. systemd കാണുന്നതുപോലെ unit അച്ചടിക്കുക, സഹായിക്ക് സ്വയം ഉയർത്താൻ കഴിയുമോ എന്ന് തീരുമാനിക്കുന്ന സാൻഡ്ബോക്സ് ക്രമീകരണങ്ങളോടൊപ്പം. ഈ ഘട്ടത്തിൽ വായന-മാത്ര പരിശോധന മതി.
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -bആദ്യ കമാൻഡ് unit-ഉം അതിന്റെ drop-in-കളും എവിടെ നിന്ന് വരുന്നു എന്ന് കാണിക്കുന്നു, ഇത് പ്രധാനമാണ് കാരണം മാസങ്ങൾക്ക് മുമ്പ് ചേർത്ത ഒരു ഓവർറൈഡ് അത് എന്തിന് നിലനിൽക്കുന്നു എന്ന ഓർമ്മയെക്കാൾ കൂടുതൽ കാലം ജീവിക്കുന്നു. രണ്ടാമത്തേത് അടുത്ത രണ്ട് വിഭാഗങ്ങൾ ആശ്രയിക്കുന്ന സാൻഡ്ബോക്സ് മൂല്യങ്ങൾ അച്ചടിക്കുന്നു.
നിങ്ങൾ കാണുന്നത് അതേ വിതരണത്തിന്റെയും പതിപ്പിന്റെയും പ്രവർത്തിക്കുന്ന ഹോസ്റ്റുമായി താരതമ്യം ചെയ്യുക. User, CapabilityBoundingSet അല്ലെങ്കിൽ NoNewPrivileges ലെ വ്യത്യാസം കൃത്യമായ സൂചനയാണ്; ഗദ്യ കമന്റുകളിലെ വ്യത്യാസമല്ല. എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് മൂല്യങ്ങൾ എഴുതിവയ്ക്കുക, കാരണം ചലിക്കുന്ന ലക്ഷ്യത്തോടുള്ള പിന്നീടുള്ള താരതമ്യം ഒന്നും തെളിയിക്കുന്നില്ല. സേവനം ഒരു അനധികൃത അക്കൗണ്ടും ശൂന്യമായ bounding സെറ്റും ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നുണ്ടെങ്കിൽ, സഹായിക്ക് പ്രവർത്തിക്കാൻ ഏതാണ്ട് ഒന്നുമില്ല.
ക്രെഡൻഷ്യൽ പരിവർത്തനം, ഫയൽ ആക്സസ്, നയം എന്നിവ മൂന്ന് അതിർത്തികളാണ്
exec സമയത്ത് സംഭവിക്കുന്നതിൽ നിന്ന് തുടങ്ങുക. ഒരു setuid ബൈനറിയോ ഫയൽ കഴിവുകൾ വഹിക്കുന്ന ഫയലോ ക്രെഡൻഷ്യൽ പരിവർത്തനം ഉണ്ടാക്കുന്നു, അതിനാൽ ലഭിക്കുന്ന ഐഡന്റിറ്റി വിളിച്ചയാളുടെ തുടർച്ചയല്ല. boundary സെറ്റ് അത്തരം ഒരു ഫയലിന് നേടാനാകുന്നത് പരിമിതപ്പെടുത്തുന്നു, NoNewPrivileges setuid, setgid, ഫയൽ-കഴിവ് നേട്ടങ്ങൾ പൂർണ്ണമായി തടയുന്നു. ആ മൂന്നിൽ ഏതെങ്കിലും സഹായിയെ നിർത്താം, സേവനത്തിന്റെ മറ്റെല്ലാ പ്രവർത്തനങ്ങളും കേടുകൂടാതെ നിൽക്കും.
അടുത്തതായി വിശാലമായ വിവേചനാധികാര ബൈപ്പാസിനെ ഇടുങ്ങിയ വായനാ ആക്സസിൽ നിന്ന് വേർതിരിക്കുക. CAP_DAC_OVERRIDE ഏതാണ്ട് എല്ലായിടത്തും വിവേചനാധികാര പരിശോധനകൾ ഒഴിവാക്കുന്നു, CAP_DAC_READ_SEARCH അതിന്റെ സ്വന്തം അധിക അധികാരങ്ങളോടെ വായനയും ഡയറക്ടറി ട്രാവേഴ്സലും ഉൾക്കൊള്ളുന്നു. അവ വ്യത്യസ്ത സ്വാധീന പരിധിയുള്ള വ്യത്യസ്ത ഉപകരണങ്ങളാണ്, ഒന്നും PAM shadow ഫയൽ വായിക്കട്ടെ എന്ന വാക്യത്തിന്റെ അക്ഷരവിന്യാസമല്ല.
അവസാനം, നിർബന്ധിത നയം ആ പ്രവൃത്തി അനുവദിക്കുന്നുണ്ടോ എന്ന് ചോദിക്കുക. ഒരു Linux കഴിവ് SELinux-നെ മറികടക്കുന്നില്ല, ഒന്ന് കൈവശം വയ്ക്കുന്നത് type enforcement നിയമത്തെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല. ഫയൽ-ആക്സസ് നിരാകരണവും കഴിവ് നിരാകരണവും വ്യത്യസ്ത തെളിവുകളായി കാണുക, കാരണം അവ വ്യത്യസ്ത പരിഹാരങ്ങളും പലപ്പോഴും വ്യത്യസ്ത ഉടമകളും പേരിടുന്നു. റെക്കോർഡിന്റെ ഓരോ ഫീൽഡും വായിക്കുക, denied എന്ന ഒറ്റ വാക്കല്ല. ഏത് എക്സിക്യൂട്ടബിളാണ് പ്രവൃത്തി ചെയ്തത്, ഏത് ഡൊമെയ്നിൽ പ്രവർത്തിച്ചു, ഏത് തരം ലക്ഷ്യത്തെ സ്പർശിച്ചു, ഏത് ഒബ്ജക്ട് ക്ലാസ് ഉൾപ്പെട്ടിരുന്നു, നയം ഏത് അനുമതി നിരാകരിച്ചു — ഓരോന്നും വ്യത്യസ്ത രീതിയിൽ ഉത്തരം ചുരുക്കുന്നു.
ഓഡിറ്റ് ലോഗിൽ നിന്ന് നിരാകരണം പുറത്തെടുക്കുക
നടപ്പാക്കുന്ന ഹോസ്റ്റിൽ, ഓഡിറ്റ് ട്രെയിൽ മാത്രമാണ് നിരാകരണം രേഖപ്പെടുത്തുന്ന ഇടം. സമീപകാല സംഭവങ്ങൾ ചോദിച്ച് പരാജയപ്പെട്ട ലോഗിന്റെ ടൈംസ്റ്റാമ്പിനെതിരെ വായിക്കുക, അന്വേഷണം തുടങ്ങിയ സമയത്തിനെതിരെയല്ല.
ausearch -m AVC,USER_AVC -ts recentശൂന്യമായ ഫലം നിരപരാധിത്വത്തിന്റെ തെളിവല്ല. അതിനർത്ഥം ഓഡിറ്റിംഗ് ശേഖരിക്കുന്നില്ല, അല്ലെങ്കിൽ നിങ്ങളുടെ വിൻഡോ ശ്രമം വിട്ടുപോയി, നയം ഒഴിവാക്കുന്നതിന് മുമ്പ് രണ്ട് സാധ്യതകളും ഒഴിവാക്കണം.
Red Hat-ന്റെ SELinux പ്രശ്നപരിഹാര മാർഗ്ഗനിർദ്ദേശം ലേബലും കോൺഫിഗറേഷൻ പരിശോധനകളും allow നിയമങ്ങൾ സൃഷ്ടിക്കുന്നതിന് മുമ്പ് വയ്ക്കുന്നു, ഇത് ഈ പ്രശ്നത്തിനും ശരിയായ ക്രമമാണ്. തെറ്റായി ലേബൽ ചെയ്ത സഹായി ബൈനറിയും നയത്തിലെ വിടവും സമാനമായ നിരാകരണങ്ങൾ ഉണ്ടാക്കുന്നു പക്ഷേ വ്യത്യസ്ത പരിഹാരങ്ങൾ ആവശ്യപ്പെടുന്നു. ലേബലിംഗ് പിശകിന് allow നിയമം സൃഷ്ടിക്കുന്നത് വീഴ്ച മറയ്ക്കുകയും അടുത്ത പാക്കേജ് അപ്ഡേറ്റ് അത് വീണ്ടും കൊണ്ടുവരാൻ അനുവദിക്കുകയും ചെയ്യുന്നു. ഏതെങ്കിലും നയം എഴുതുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത സഹായിയുടെ ലേബൽ സ്ഥിരീകരിക്കുക.
ഒരു സ്വീകരിച്ചതും ഒരു നിരസിച്ചതുമായ ലോഗിൻ ഉപയോഗിച്ച് മാറ്റം തെളിയിക്കുക
നിങ്ങൾ പ്രദർശിപ്പിച്ച അതിർത്തി മാത്രം മാറ്റുക, തുടർന്ന് രണ്ട് ഫലങ്ങളും പരിശോധിക്കുക. പ്രമാണീകരണം നടക്കേണ്ട അക്കൗണ്ട് വിജയിക്കണം, തെറ്റായ പാസ്വേഡുള്ള അക്കൗണ്ട് ഇപ്പോഴും പരാജയപ്പെടണം. എല്ലാ ശ്രമവും വിജയിപ്പിക്കുന്ന മാറ്റം പ്രമാണീകരണം നന്നാക്കുന്നതിനുപകരം നീക്കം ചെയ്തു.
യഥാർത്ഥ കണക്ഷൻ ശ്രമം നടത്തി ഉടൻ തന്നെ ജേണൽ വായിക്കുക. പരിഹാരം തെളിയിക്കുന്ന വരി ആ ശ്രമത്തിന്റെ pam_unix(openvpn:auth) എൻട്രിയാണ്: അതിൽ പ്രമാണീകരണം വിജയിച്ചു എന്ന് കാണണം, ഒരു AVC റെക്കോർഡും അതേ സെക്കൻഡ് വഹിക്കരുത്.
journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpnപ്രവർത്തിക്കുന്ന ടണലിന് വീണ്ടും കണക്റ്റുചെയ്യലും ആവശ്യമാണ്, കാരണം സാൻഡ്ബോക്സ് മാറ്റങ്ങൾ ആദ്യത്തേതിനേക്കാൾ രണ്ടാമത്തെ കണക്ഷൻ കൂടുതൽ തവണ തകർക്കുന്നു. വീണ്ടും കണക്റ്റുചെയ്തതിന് ശേഷം സ്ഥാപിതമായ സോക്കറ്റ് പരിശോധിച്ച് അതേ unit ഇപ്പോഴും അതിന് സേവനം നൽകുന്നുണ്ടെന്ന് സ്ഥിരീകരിക്കുക.