SELinux-ൽ Squid നിരസിക്കലുകൾ കണ്ടെത്തൽ

Squid സൃഷ്ടിക്കുന്ന HTTP ആക്സസ് നിരസിക്കലും ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന്റെ “Permission denied” ഉം വ്യത്യസ്ത അതിരുകളിൽ സംഭവിക്കുന്നു. Squid ഒരു ഫയൽ തുറക്കുകയായിരുന്നോ, സോക്കറ്റ് ബൈൻഡ് ചെയ്യുകയായിരുന്നോ, പുറത്തേക്ക് കണക്റ്റ് ചെയ്യുകയായിരുന്നോ, അതല്ലെങ്കിൽ ക്ലയന്റ് അഭ്യർത്ഥന നിരസിക്കുകയായിരുന്നോ എന്ന് കണ്ടെത്തുക.

ഓഡിറ്റ് ഇവന്റ് പരസ്പരം ബന്ധിപ്പിക്കുക

SELinux സിസ്റ്റങ്ങളിൽ, സേവന പിശക് അതിന്റെ ഓഡിറ്റ് റെക്കോർഡുമായി പൊരുത്തപ്പെടുത്തുക. ഉറവിട ഡൊമെയിൻ, ലക്ഷ്യ തരം, ഒബ്ജക്റ്റ് ക്ലാസ്, നിരസിച്ച അനുമതി എന്നിവ ഏത് പ്രവർത്തനമാണ് നയം തടഞ്ഞതെന്ന് കാണിക്കുന്നു. ശരിയായ Unix ഉടമസ്ഥത സുരക്ഷാ ലേബൽ ഉചിതമാണെന്ന് തെളിയിക്കുന്നില്ല.

ഇഷ്ടാനുസൃത ലിസണിംഗ് പോർട്ടിന് അനുബന്ധ പോർട്ട് ലേബൽ ആവശ്യമായി വരാം. മാറ്റിയ ലോഗ് അല്ലെങ്കിൽ കാഷെ ഡയറക്ടറിക്ക് ഫയൽ ലേബലിംഗ് ആവശ്യമായി വരാം. Squid ലോഗ് പാത്ത് പരാജയത്തിന്, ലേബലിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് ഡയറക്ടറി ട്രാവേഴ്സലും എഴുത്തുകാരൻ അനുമതികളും പരിശോധിക്കുക. അസാധാരണ ഔട്ട്ബൗണ്ട് സേവനത്തിനുള്ള അനുമതി വീണ്ടും മറ്റൊരു പ്രവർത്തനമാണ്; Red Hat-ന്റെ Squid SELinux ഉദാഹരണങ്ങൾ ഈ കേസുകൾ വേർതിരിക്കുന്നു.

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

തെളിവുകൾ ചൂണ്ടിക്കാണിക്കുന്ന നയമോ സ്ഥലമോ തിരുത്തുക, എന്നാൽ ഹോസ്റ്റിലെ പ്രയോഗം നിലനിർത്തുക. ഹോസ്റ്റ് നയ പ്രശ്നം പരിഹരിച്ച ശേഷവും Squid-ന്റെ സ്വന്തം ക്ലയന്റ് പ്രാമാണീകരണവും ആക്സസ് നിയമങ്ങളും ബാധകമാണ്.