PAM-autentisering fungerer for handa, men sviktar som OpenVPN-teneste

Autentisering via PAM kan lukkast når du køyrer klienten for handa, og svikta med AUTH_FAILED så snart systemd startar den same profilen. Passordet endrar seg ikkje mellom desse køyringane; det som endrar seg, er settet med avgrensingar rundt prosessen som stiller PAM spørsmålet. PAM svarar gjennom eit hjelpeprogram der evna til å byte sine eigne påloggingsdata er nøyaktig det ei herda unit fjernar. Finn det hjelpeprogrammet og grensa det treng, før du rører ei kapabilitetsliste.

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

Med lokal passordautentisering les pam_unix sjeldan hashfila sjølv. Det køyrer unix_chkpwd, som distribusjonane installerer setuid root eller setgid shadow slik at eitt passord kan kontrollerast på vegner av ein prosess som ikkje skal lese /etc/shadow. Fjern moglegheita til å oppnå den identiteten, og hjelpeprogrammet kan ikkje fullføre kontrollen, så modulen returnerer ein vanleg autentiseringsfeil.

Feilen ser då ut som eit problem med påloggingsdata i kvar logg klienten kan sjå. Det er fella: klienten rapporterer det PAM fortalde han, og PAM rapporterer berre at stakken sa nei. Å køyre hjelpeprogrammet for handa som root beviser heller ingenting, fordi det brukar ein privilegiebane tenesta aldri brukar. Les unita systemd faktisk lasta, og les deretter systemloggen for forsøket ho gjorde. Desse to visingane skil eit sandkasseproblem frå eit feil passord.

Les unita før du les passordloggen

Ei pakka unit kan bera ein drop-in du ikkje skreiv, og den effektive konfigurasjonen er det samanslegne resultatet. Skriv ut unita slik systemd ser ho, saman med sandkasseinnstillingane som avgjer om hjelpeprogrammet kan heve seg sjølv. Skriveverna 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 kvar unita og drop-inane kjem frå, noko som betyr noko fordi ei overstyring som vart lagd til for månader sidan lever lengre enn minnet av kvifor ho finst. Den andre skriv ut sandkasseverdiane som dei to neste avsnitta byggjer på.

Samanlikn det du ser med ein fungerande vert med same distribusjon og versjon. Ein skilnad i User, CapabilityBoundingSet eller NoNewPrivileges er eit konkret spor; ein skilnad i prosakommentarar er det ikkje. Skriv ned verdiane før du endrar noko, fordi ein seinare samanlikning mot eit rørleg mål ikkje beviser noko. Viss tenesta køyrer som ein uprivilegert konto med eit tomt grensesett, har hjelpeprogrammet nesten ingenting å arbeide med.

Påloggingsdatatransformasjon, filtilgang og policy er tre grenser

Byrj med det som skjer under exec. Ein setuid-binær eller ei fil med file capabilities utløyser ein påloggingsdatatransformasjon, så den resulterande identiteten er ikkje ein fortsetjing av kallaren. Grensesettet avgrensar kva ein slik binær kan tileigne seg, og NoNewPrivileges blokkerer setuid-, setgid- og file-capability-gevinstar heilt. Kven som helst av desse tre kan stoppe hjelpeprogrammet medan kvar annan tenestefunksjon held seg intakt.

Deretter skil du brei diskresjonær omgåing frå smal lesetilgang. CAP_DAC_OVERRIDE hoppar over diskresjonære kontrollar nesten overalt, medan CAP_DAC_READ_SEARCH dekkjer lesing og katalogtraversering med eigne ekstra fullmakter. Dei er ulike verktøy med ulik rekkjevidd, og ingen av dei er ein måte å skrive la PAM lese shadow-fila.

Til slutt, spør om den obligatoriske policyen tillèt handlinga i det heile. Ein Linux-kapabilitet overstyrer ikkje SELinux, og å ha ein beviser ingenting om ein type-handhevingsregel. Handsame ei filtilgangsnekting og ei kapabilitetsnekting som ulike bevis, fordi dei namngir ulike reparasjonar og ofte ulike eigarar. Les kvart felt i posten i staden for det eine ordet denied. Kva køyrbar fil som utførte handlinga, i kva domene ho køyrde, kva type mål ho rørte, kva klasse objekt som var involvert og kva løyve policyen nekta - kvar av desse avgrensar svaret på kvar sin måte.

Drag nektinga ut av revisjonsloggen

På ein vert i enforcing-modus er revisjonssporet det einaste staden som registrerer ei nekting. Spør etter dei siste hendingane og les dei mot tidsstempelet for den mislukka innlogginga, ikkje mot tida du byrja å undersøkje.

ausearch -m AVC,USER_AVC -ts recent

Eit tomt resultat er ikkje bevis på uskuld. Det betyr anten at revisjonen ikkje samlar inn, eller at vindauget ditt gjekk glipp av forsøket, og begge moglegheitene må utelukkast før du utelukkar policyen.

Feilsøkingsrettleiinga til Red Hat for SELinux set etikett- og konfigurasjonskontrollar før generering av løyvereglar, som også er rett rekkjefølgje for dette problemet. Ein feilmerkt hjelpebinær og eit hol i policyen gir liknande nektingar, men treng ulike reparasjonar. Å generere ein løyveregel for ein etikettfeil skjuler feilen og lèt den neste pakkeoppdateringa gjeninnføre han. Stadfest etiketten på det installerte hjelpeprogrammet før du skriv nokon policy.

Prov endringa med éi godteken og éi avvist innlogging

Endre berre grensa du har demonstrert, og test deretter begge utfalla. Ein konto som skal autentisere, må lukkast, og ein konto med feil passord må framleis svikta. Ei endring som får kvart forsøk til å lukkast, har fjerna autentiseringa i staden for å reparere ho.

Gjer eit ekte tilkoplingsforsøk og les journalen med ein gong etterpå. Linja som beviser rettinga, er oppføringa pam_unix(openvpn:auth) for det forsøket: ho skal seie at autentiseringa lukkast, og ingen AVC-post skal bera same sekund.

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

Ein fungerande tunnel treng også ein gjentilkopling, fordi sandkasseendringar bryt den andre tilkoplinga oftare enn den første. Kontroller den etablerte sockelen etter gjentilkoplinga og stadfest at same unit framleis betener han.