CentOS8 Stream - ce este contextul de securitate în permisiunile fișierelor și cum poate afecta accesul?

Am instalat unele dintre aplicațiile mele de bază aspnet pe Linux înainte de a folosi CentOS8. De data aceasta am folosit CentOS8-Stream. Nu știu dacă asta contribuie la problemă.

Faptele:

1. Nu am putut face certificate de utilizare Apache. Totul a fost ca înainte și totuși nu a funcționat. În cele din urmă, am găsit un link obscur pe internet care a folosit ls -lrtZ /etc/pki/tls/certs a afișa context de securitate (Nici nu știam că există). Deci, pur și simplu cp fișierele de certificat și Apache este acum în regulă.

2. Cu toate acestea, aplicația mea aspnet eșuează încercați să scrieți o bază de date numai în citire. Am încercat cp păcăleală, dar nu va ajuta.. De asemenea, nu apar jurnalele de aplicații

Fișierul db:

-rw-rw-rw-. 1 root root unconfined_u:object_r:httpd_sys_content_t:s0

Nu inteleg cum asta context de securitate poate trece peste regulat permisiuni de tip chmod?? Și ce să faci pentru a o repara? Adică cât de multă permisiunea explicită poate ajunge să fie rwrwrw?

Este ceva nou? caracteristică de SELinux? Il pot opri complet?

Notă: 1 și 2 nu sunt legate - cred că au aceeași cauză principală, dar nimic între ele. Dacă accesez aplicația aspnet direct fără Apache - are aceeași eroare

SELinux este un sistem de control al accesului bazat pe roluri, care poate controla în detaliu ceea ce este permis să facă unui proces. De exemplu, un server web este mai sigur atunci când nu poate citi și spune /etc/shadow chiar și ca utilizator root, nici nu porniți un shell web. Contextul de securitate este fundamental pentru acest sistem și există încă de la început.

Contextul fișierului SELinux este un lucru separat de permisiunile UNIX sau ACL-urile extinse. Toate trebuie să permită; da, selinux poate nega când permisiunile de bază ale fișierelor ar indica permis.

Citeste RHEL 8 Utilizarea manualului SELinux si Pagina wiki CentOS pe SELinux. Utilizați instrumentele de depanare acolo, în special sealert -a /var/log/audit/audit.log Examinați orice refuzuri în timpul problemei aplicației dvs. Verificați dacă există booleeni pentru a comuta comportamentul dorit.

Datorită lui @John Mahowald, am găsit unghiul potrivit pentru a analiza problema.

Rădăcina cauzei este că toate VM-urile mele anterioare folosesc SELinux permisiv în timp ce cel nou (GCP) rulează aplicarea modul.

Deci, dacă dați peste efecte ciudate pe care nu le puteți explica - vedeți linkurile lui John. Dar folosește sestatus comanda mai întâi pentru a vedea ce mod este setat SELinux-ul tău.

P.S. Am decis să-l las la fel de permisiv, deoarece aplicarea pur și simplu nu este viabilă de menținut. Cred că întregul SELinux este un elefant alb. Trebuie inlocuit