PAM-godkendelse virker manuelt, men fejler som OpenVPN-tjeneste

Godkendelse via PAM kan lykkes, når du kører klienten manuelt, og fejle med AUTH_FAILED, så snart systemd starter samme profil. Adgangskoden ændres ikke mellem disse kørsler; det, der ændres, er det sæt af begrænsninger, der omgiver processen, som stiller PAM spørgsmålet. PAM svarer gennem en hjælper, hvis evne til at ændre sine egne legitimationsoplysninger netop er det, en hærdet unit fjerner. Find den hjælper og den grænse, den har brug for, før du rører en kapabilitetsliste.

unix_chkpwd er den binære fil, der besvarer PAM-spørgsmålet

Med lokal adgangskodegodkendelse læser pam_unix sjældent selve hash-filen. Det udfører unix_chkpwd, som distributioner installerer som setuid root eller setgid shadow, så én adgangskode kan kontrolleres på vegne af en proces, der ikke har noget at gøre med at læse /etc/shadow. Fjern muligheden for at opnå den identitet, og hjælperen kan ikke gennemføre kontrollen, så modulet returnerer en almindelig godkendelsesfejl.

Fejlen ser derefter ud som et legitimationsproblem i hver log, klienten kan se. Det er fælden: klienten rapporterer, hvad PAM fortalte den, og PAM rapporterer kun, at stakken sagde nej. At køre hjælperen manuelt som root beviser heller intet, fordi det afprøver en rettighedsvej, som tjenesten aldrig bruger. Læs den unit, systemd faktisk indlæste, og læs derefter systemloggen for det forsøg, den gjorde. De to visninger adskiller et sandbox-problem fra et forkert-adgangskode-problem.

Læs unit, før du læser adgangskodeloggen

En pakket unit kan bære et drop-in, du ikke selv har skrevet, og den effektive konfiguration er det sammenflettede resultat. Udskriv unit, som systemd ser den, sammen med de sandbox-indstillinger, der afgør, om hjælperen kan hæve sig selv. Skrivebeskyttet inspektion er nok på dette stadium.

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 kommando viser, hvor unit og dens drop-ins kommer fra, hvilket er vigtigt, fordi en tilsidesættelse tilføjet for måneder siden lever længere end erindringen om, hvorfor den findes. Den anden udskriver de sandbox-værdier, som de næste to afsnit afhænger af.

Sammenlign det, du ser, med en fungerende vært med samme distribution og version. En forskel i User, CapabilityBoundingSet eller NoNewPrivileges er et konkret spor; en forskel i prosa-kommentarer er ikke. Skriv værdierne ned, før du ændrer noget, fordi en senere sammenligning med et bevægeligt mål intet beviser. Hvis tjenesten kører som en uprivilegeret konto med et tomt bounding-sæt, har hjælperen næsten intet at arbejde med.

Legitimationsændring, filadgang og politik er tre grænser

Begynd med, hvad der sker under exec. En setuid-binær eller en fil med filkapabiliteter udløser en legitimationsændring, så den resulterende identitet ikke er en fortsættelse af kalderen. Bounding-sættet begrænser, hvad en sådan binær må tilegne sig, og NoNewPrivileges blokerer setuid-, setgid- og filkapabilitetstilegnelser helt. Enhver af de tre kan stoppe hjælperen, mens alle andre tjenestefunktioner forbliver intakte.

Adskil derefter bred diskretionær omgåelse fra smal læseadgang. CAP_DAC_OVERRIDE springer diskretionære kontroller over næsten overalt, mens CAP_DAC_READ_SEARCH dækker læsning og kataloggennemgang med sine egne yderligere beføjelser. De er forskellige værktøjer med forskellige virkningsradier, og ingen af dem er en stavemåde for lad PAM læse shadow-filen.

Spørg til sidst, om den obligatoriske politik overhovedet tillader handlingen. En Linux-kapabilitet tilsidesætter ikke SELinux, og at have én beviser intet om en type enforcement-regel. Behandl en filadgangsafvisning og en kapabilitetsafvisning som forskellige beviser, fordi de navngiver forskellige rettelser og ofte forskellige ejere. Læs hvert felt i posten i stedet for det enkelte ord denied. Hvilken eksekverbar fil handlede, i hvilket domæne den kørte, hvilken type mål den rørte, hvilken klasse objekt der var involveret, og hvilken tilladelse politikken afviste — hver især indsnævrer svaret på sin egen måde.

Træk afvisningen ud af revisionsloggen

På en håndhævende vært er revisionssporet det eneste sted, der registrerer en afvisning. Forespørg de seneste hændelser, og læs dem op mod tidsstemplet for det mislykkede login, ikke op mod det tidspunkt, du begyndte at undersøge.

ausearch -m AVC,USER_AVC -ts recent

Et tomt resultat er ikke bevis på uskyld. Det betyder enten, at revision ikke indsamler, eller at dit vindue missede forsøget, og begge muligheder skal udelukkes, før du udelukker politikken.

Red Hats vejledning til fejlfinding af SELinux sætter kontrol af labels og konfiguration før generering af allow-regler, hvilket også er den rigtige rækkefølge for dette problem. En fejlmærket hjælper-binær og et hul i politikken giver lignende afvisninger, men kræver forskellige reparationer. At generere en allow-regel for en mærkningsfejl skjuler fejlen og overlader det til den næste pakkeopdatering at genindføre den. Bekræft labelen på den installerede hjælper, før du skriver nogen politik.

Bevis ændringen med ét accepteret og ét afvist login

Ændr kun den grænse, du demonstrerede, og test derefter begge udfald. En konto, der bør godkendes, skal lykkes, og en konto med forkert adgangskode skal stadig fejle. En ændring, der får ethvert forsøg til at lykkes, har fjernet godkendelse i stedet for at reparere den.

Udfør et rigtigt forbindelsesforsøg, og læs journalen umiddelbart bagefter. Linjen, der beviser rettelsen, er pam_unix(openvpn:auth)-posten for det forsøg: den skal vise vellykket godkendelse, og ingen AVC-post må bære samme sekund.

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

En fungerende tunnel har også brug for en genopkobling, fordi sandbox-ændringer oftere bryder den anden forbindelse end den første. Kontrollér den etablerede socket efter genopkoblingen, og bekræft, at den samme unit stadig betjener den.