PAM-autentisering fungerer manuelt, men feiler som OpenVPN-tjeneste

Autentisering gjennom PAM kan lykkes når du kjører klienten manuelt, og feile med AUTH_FAILED så snart systemd starter samme profil. Passordet endres ikke mellom disse kjøringene; det som endres, er settet med begrensninger rundt prosessen som stiller PAM spørsmålet. PAM svarer gjennom en hjelper hvis evne til å endre sine egne legitimasjoner er nettopp det en herdet unit fjerner. Finn den hjelperen og grensen den 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 selve hash-fila. Den kjører unix_chkpwd, som distribusjoner installerer som setuid root eller setgid shadow, slik at ett passord kan kontrolleres på vegne av en prosess som ikke har noe med å lese /etc/shadow å gjøre. Fjern muligheten til å oppnå den identiteten, og hjelperen kan ikke fullføre kontrollen, så modulen returnerer en vanlig autentiseringsfeil.

Feilen ser da ut som et legitimasjonsproblem i hver logg klienten kan se. Det er fellen: klienten rapporterer hva PAM fortalte den, og PAM rapporterer bare at stakken sa nei. Å kjøre hjelperen manuelt som root beviser heller ingenting, fordi det prøver en rettighetsvei tjenesten aldri bruker. Les uniten systemd faktisk lastet, og deretter systemloggen for forsøket den gjorde. Disse to visningene skiller et sandkasseproblem fra et feil-passord-problem.

Les uniten før du leser passordloggen

En pakket unit kan inneholde en drop-in du ikke har skrevet, og den effektive konfigurasjonen er det sammenslåtte resultatet. Skriv ut uniten slik systemd ser den, sammen med sandkasseinnstillingene som avgjør om hjelperen 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 lagt til for måneder siden lever lenger enn minnet om hvorfor den finnes. Den andre skriver ut sandkasseverdiene de neste to avsnittene avhenger av.

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 prosa-kommentarer er ikke. Skriv ned verdiene før du endrer noe, fordi en senere sammenligning med et bevegelig mål ikke beviser noe. Hvis tjenesten kjører som en uprivilegert konto med et tomt bounding-sett, har hjelperen nesten ingenting å arbeide med.

Legitimasjonstransformasjon, filtilgang og policy er tre grenser

Begynn med det som skjer under exec. En setuid-binær eller en fil med filkapabiliteter utløser en legitimasjonstransformasjon, så den resulterende identiteten er ikke en fortsettelse av kalleparten. Bounding-settet begrenser hva en slik fil kan tilegne seg, og NoNewPrivileges blokkerer setuid-, setgid- og filkapabilitetstilegnelser helt. Enhver av de tre kan stoppe hjelperen mens alle andre tjenestefunksjoner forblir intakte.

Skill deretter 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 kataloggjennomgang med sine egne ekstra fullmakter. De er forskjellige verktøy med forskjellige virkningsradier, og ingen av dem er en stavemåte for la PAM lese shadow-fila.

Til slutt, spør om den obligatoriske policyen i det hele tatt tillater handlingen. En Linux-kapabilitet overstyrer ikke SELinux, og å ha én beviser ingenting om en type enforcement-regel. Behandle en filtilgangsavvisning og en kapabilitetsavvisning som forskjellige bevis, fordi de navngir forskjellige rettelser og ofte forskjellige eiere. Les hvert felt i posten i stedet for det ene ordet denied. Hvilken kjørbar fil handlet, i hvilket domene den kjørte, hvilken type mål den berørte, hvilken klasse objekt som var involvert og hvilken tillatelse policyen avslo – hver av dem innsnevrer svaret på sin måte.

Trekk avvisningen ut av revisjonsloggen

På en håndhevende vert er revisjonssporet det eneste stedet som registrerer en avvisning. 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 veiledning for feilsøking av SELinux setter kontroll av etiketter og konfigurasjon før generering av allow-regler, som også er riktig rekkefølge for dette problemet. En feilmerket hjelper-binær og et hull i policyen gir lignende avvisninger, men krever forskjellige reparasjoner. Å generere en allow-regel for en merkefeil skjuler feilen og overlater til neste pakkeoppdatering å gjeninnføre den. Bekreft etiketten på den installerte hjelperen før du skriver noen policy.

Bevis endringen med én akseptert og én avvist innlogging

Endre bare grensen du demonstrerte, og test deretter begge utfallene. En konto som skal autentiseres, må lykkes, og en konto med feil passord må fortsatt feile. En endring som gjør ethvert forsøk vellykket, har fjernet autentiseringen i stedet for å reparere den.

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

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

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