PAM-autentisering fungerar för hand men misslyckas som OpenVPN-tjänst

Autentisering via PAM kan lyckas när du kör klienten för hand och misslyckas med AUTH_FAILED så snart systemd startar samma profil. Lösenordet ändras inte mellan de körningarna; det som ändras är uppsättningen begränsningar kring processen som ställer frågan till PAM. PAM svarar via ett hjälpprogram vars förmåga att byta sina egna referenser är precis det som en härdad unit tar bort. Hitta det hjälpprogrammet och den gräns det behöver innan du rör en behörighetslista.

unix_chkpwd är binärfilen som svarar på PAM-frågan

Med lokal lösenordsautentisering läser pam_unix sällan hashfilen själv. Det kör unix_chkpwd, som distributionerna installerar setuid root eller setgid shadow så att ett lösenord kan kontrolleras för en process som inte ska läsa /etc/shadow. Ta bort möjligheten att få den identiteten och hjälpprogrammet kan inte slutföra kontrollen, så modulen returnerar ett vanligt autentiseringsfel.

Felet ser då ut som ett referensproblem i varje logg klienten kan se. Det är fällan: klienten rapporterar vad PAM sade till den, och PAM rapporterar bara att stacken sade nej. Att köra hjälpprogrammet för hand som root bevisar inte heller något, eftersom det använder en privilegieväg som tjänsten aldrig använder. Läs den unit som systemd faktiskt laddade och läs sedan systemloggen för försöket den gjorde. Dessa två vyer skiljer ett sandlådeproblem från ett felaktigt lösenord.

Läs uniten innan du läser lösenordsloggen

En paketerad unit kan bära en drop-in som du inte skrev, och den effektiva konfigurationen är det sammanslagna resultatet. Skriv ut uniten som systemd ser den, tillsammans med sandlådeinställningarna som avgör om hjälpprogrammet kan höja sig självt. Skrivskyddad inspektion räcker i detta skede.

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

Det första kommandot visar var uniten och dess drop-ins kommer ifrån, vilket spelar roll eftersom en överstyrning som lades till för månader sedan lever längre än minnet av varför den finns. Det andra skriver ut sandlådevärdena som de två följande avsnitten bygger på.

Jämför det du ser med en fungerande värd med samma distribution och version. En skillnad i User, CapabilityBoundingSet eller NoNewPrivileges är ett konkret spår; en skillnad i prosakommentarer är det inte. Skriv ner värdena innan du ändrar något, eftersom en senare jämförelse mot ett rörligt mål inte bevisar något. Om tjänsten körs som ett oprivilegierat konto med en tom gränsmängd har hjälpprogrammet nästan inget att arbeta med.

Referenstransformering, filåtkomst och policy är tre gränser

Börja med vad som händer under exec. En setuid-binär eller en fil med file capabilities utlöser en referenstransformering, så den resulterande identiteten är inte en fortsättning på anroparen. Gränsmängden begränsar vad en sådan binär får förvärva, och NoNewPrivileges blockerar setuid-, setgid- och file-capability-förvärv helt. Vilken som helst av dessa tre kan stoppa hjälpprogrammet medan varje annan tjänstefunktion förblir intakt.

Separera sedan bred diskretionär kringgång från smal läsåtkomst. CAP_DAC_OVERRIDE hoppar över diskretionära kontroller nästan överallt, medan CAP_DAC_READ_SEARCH täcker läsning och kataloggenomgång med sina egna extra befogenheter. De är olika verktyg med olika räckvidd, och ingen av dem är ett sätt att skriva låt PAM läsa shadowfilen.

Fråga slutligen om den obligatoriska policyn tillåter åtgärden alls. En Linux-behörighet åsidosätter inte SELinux, och att ha en bevisar inget om en typgenomdrivningsregel. Behandla ett nekande av filåtkomst och ett nekande av en behörighet som olika bevis, eftersom de anger olika åtgärder och ofta olika ägare. Läs varje fält i posten i stället för det enda ordet denied. Vilken körbar fil som utförde åtgärden, i vilken domän den körde, vilken typ av mål den rörde, vilken klass av objekt som var inblandad och vilken behörighet policyn nekade - var och en av dessa begränsar svaret på olika sätt.

Dra ut nekandet ur granskningsloggen

På en värd i enforcing-läge är granskningsspåret den enda platsen som registrerar ett nekande. Fråga efter de senaste händelserna och läs dem mot tidsstämpeln för den misslyckade inloggningen, inte mot tiden då du började undersöka.

ausearch -m AVC,USER_AVC -ts recent

Ett tomt resultat är inte bevis på oskuld. Det betyder antingen att granskningen inte samlar in, eller att ditt fönster missade försöket, och båda möjligheterna måste uteslutas innan du utesluter policyn.

Red Hats felsökningsvägledning för SELinux sätter etikett- och konfigurationskontroller före generering av tillåtelseregler, vilket också är rätt ordning för detta problem. En felmärkt hjälpbinär och en lucka i policyn ger liknande nekanden men kräver olika reparationer. Att generera en tillåtelseregel för ett etikettfel döljer felet och låter nästa paketuppdatering återinföra det. Bekräfta etiketten på det installerade hjälpprogrammet innan du skriver någon policy.

Bevisa ändringen med en accepterad och en avvisad inloggning

Ändra bara den gräns du har demonstrerat och testa sedan båda utfallen. Ett konto som ska autentisera måste lyckas, och ett konto med fel lösenord måste fortfarande misslyckas. En ändring som får varje försök att lyckas har tagit bort autentiseringen i stället för att reparera den.

Gör ett riktigt anslutningsförsök och läs journalen omedelbart efteråt. Raden som bevisar rättelsen är posten pam_unix(openvpn:auth) för det försöket: den ska säga att autentiseringen lyckades, och ingen AVC-post ska bära samma sekund.

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

En fungerande tunnel behöver också en återanslutning, eftersom sandlådeändringar bryter den andra anslutningen oftare än den första. Kontrollera den upprättade socketen efter återanslutningen och bekräfta att samma unit fortfarande betjänar den.