PAM-autentisering fungerer for hånden, men feiler som OpenVPN-tjeneste

Autentisering via PAM kan lykkes når du kjører klienten for hånden, og feile med AUTH_FAILED så snart systemd starter den samme profilen. Passordet endrer seg ikke mellom disse kjøringene; det som endrer seg, er settet med begrensninger rundt prosessen som stiller PAM spørsmålet. PAM svarer gjennom et hjelpeprogram hvis evne til å bytte sine egne påloggingsdata er nøyaktig det en herdet unit fjerner. Finn det hjelpeprogrammet og grensen det trenger før du rører en kapabilitetsliste.

unix_chkpwd er binærfila som svarer på PAM-spørsmålet

Med lokal passordautentisering leser pam_unix sjelden hashfila selv. Den kjører unix_chkpwd, som distribusjonene installerer setuid root eller setgid shadow slik at ett passord kan kontrolleres på vegne av en prosess som ikke skal lese /etc/shadow. Fjern muligheten til å oppnå den identiteten, og hjelpeprogrammet kan ikke fullføre kontrollen, så modulen returnerer en vanlig autentiseringsfeil.

Feilen ser da ut som et problem med påloggingsdata i hver logg klienten kan se. Det er fella: klienten rapporterer det PAM fortalte den, og PAM rapporterer bare at stakken sa nei. Å kjøre hjelpeprogrammet for hånden som root beviser heller ingenting, fordi det bruker en privilegiebane tjenesten aldri bruker. Les uniten systemd faktisk lastet, og les deretter systemloggen for forsøket den gjorde. Disse to visningene skiller et sandkasseproblem fra et feil passord.

Les uniten før du leser passordloggen

En pakket unit kan bære en drop-in du ikke skrev, og den effektive konfigurasjonen er det sammenslåtte resultatet. Skriv ut uniten slik systemd ser den, sammen med sandkasseinnstillingene som avgjør om hjelpeprogrammet kan heve seg selv. Skrivebeskyttet inspeksjon er nok på dette stadiet.

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p CapabilityBoundingSet -p AmbientCapabilities -p NoNewPrivileges
journalctl -u [email protected] -b

Den første kommandoen viser hvor uniten og drop-inene kommer fra, noe som betyr noe fordi en overstyring som ble lagt til for måneder siden lever lenger enn minnet av hvorfor den finnes. Den andre skriver ut sandkasseverdiene som de to neste avsnittene bygger på.

Sammenlign det du ser med en fungerende vert med samme distribusjon og versjon. En forskjell i User, CapabilityBoundingSet eller NoNewPrivileges er et konkret spor; en forskjell i prosakommentarer er det ikke. Skriv ned verdiene før du endrer noe, fordi en senere sammenligning mot et bevegelig mål ikke beviser noe. Hvis tjenesten kjører som en uprivilegert konto med et tomt grensesett, har hjelpeprogrammet nesten ingenting å arbeide med.

Påloggingsdatatransformasjon, filtilgang og policy er tre grenser

Begynn med det som skjer under exec. En setuid-binær eller en fil med file capabilities utløser en påloggingsdatatransformasjon, så den resulterende identiteten er ikke en fortsettelse av kalleren. Grensesettet begrenser hva en slik binær kan tilegne seg, og NoNewPrivileges blokkerer setuid-, setgid- og file-capability-gevinster helt. Hvilken som helst av disse tre kan stoppe hjelpeprogrammet mens hver annen tjenestefunksjon forblir intakt.

Deretter skiller du bred diskresjonær omgåelse fra smal lesetilgang. CAP_DAC_OVERRIDE hopper over diskresjonære kontroller nesten overalt, mens CAP_DAC_READ_SEARCH dekker lesing og katalogtraversering med egne ekstra fullmakter. De er forskjellige verktøy med forskjellig rekkevidde, og ingen av dem er en måte å skrive la PAM lese shadow-fila.

Til slutt, spør om den obligatoriske policyen tillater handlingen i det hele tatt. En Linux-kapabilitet overstyrer ikke SELinux, og å ha en beviser ingenting om en type-håndhevingsregel. Behandle en filtilgangsnektelse og en kapabilitetsnektelse som forskjellige bevis, fordi de navngir forskjellige reparasjoner og ofte forskjellige eiere. Les hvert felt i posten i stedet for det ene ordet denied. Hvilken kjørbar fil utførte handlingen, i hvilket domene den kjørte, hvilken type mål den rørte, hvilken klasse objekt som var involvert og hvilken tillatelse policyen nektet - hver av disse begrenser svaret på hver sin måte.

Trekk nektelsen ut av revisjonsloggen

På en vert i enforcing-modus er revisjonssporet det eneste stedet som registrerer en nektelse. Spør etter de siste hendelsene og les dem mot tidsstempelet for den mislykkede innloggingen, ikke mot tiden du begynte å undersøke.

ausearch -m AVC,USER_AVC -ts recent

Et tomt resultat er ikke bevis på uskyld. Det betyr enten at revisjonen ikke samler inn, eller at vinduet ditt gikk glipp av forsøket, og begge mulighetene må utelukkes før du utelukker policyen.

Red Hats feilsøkingsveiledning for SELinux setter etikett- og konfigurasjonskontroller før generering av tillatelsesregler, som også er riktig rekkefølge for dette problemet. En feilmerket hjelpebinær og et hull i policyen gir lignende nektelser, men trenger forskjellige reparasjoner. Å generere en tillatelsesregel for en etikettfeil skjuler feilen og lar den neste pakkeoppdateringen gjeninnføre den. Bekreft etiketten på det installerte hjelpeprogrammet før du skriver noen policy.

Bevis endringen med én godtatt og én avvist innlogging

Endre bare grensen du har demonstrert, og test deretter begge utfallene. En konto som skal autentisere, må lykkes, og en konto med feil passord må fortsatt feile. En endring som får hvert forsøk til å lykkes, har fjernet autentiseringen i stedet for å reparere den.

Gjør et ekte tilkoblingsforsøk og les journalen umiddelbart etterpå. Linjen som beviser rettelsen, er oppføringen pam_unix(openvpn:auth) for det forsøket: den skal si at autentiseringen lyktes, og ingen AVC-post skal bære samme sekund.

journalctl -u [email protected] -n 30 --no-pager
ss -tnp | grep openvpn

En fungerende tunnel trenger også en gjentilkobling, fordi sandkasseendringer bryter den andre tilkoblingen oftere enn den første. Kontroller den etablerte sockelen etter gjentilkoblingen og bekreft at samme unit fortsatt betjener den.