PAM autentifikacija radi ručno, ali ne uspijeva kao OpenVPN usluga

Autentifikacija putem PAM-a može uspjeti kada klijent pokrenete ručno, a ne uspjeti s AUTH_FAILED čim systemd pokrene isti profil. Lozinka se između tih pokretanja ne mijenja; mijenja se skup ograničenja oko procesa koji PAM-u postavlja pitanje. PAM odgovara preko pomoćnog programa čija je sposobnost promjene vlastitih vjerodajnica upravo ono što očvršćeni unit uklanja. Pronađite taj pomoćni program i granicu koja mu treba prije nego što dotaknete popis capabilities.

unix_chkpwd je binarna datoteka koja odgovara na PAM pitanje

Uz lokalnu autentifikaciju lozinkom, pam_unix rijetko sam čita hash datoteku. Izvršava unix_chkpwd, koji distribucije instaliraju kao setuid root ili setgid shadow kako bi se jedna lozinka mogla provjeriti u ime procesa koji nema što raditi s čitanjem /etc/shadow. Uklonite mogućnost stjecanja tog identiteta i pomoćni program ne može dovršiti provjeru, pa modul vraća običnu pogrešku autentifikacije.

Neuspjeh tada u svakom zapisu koji klijent vidi izgleda kao problem s vjerodajnicama. To je zamka: klijent izvješćuje što mu je PAM rekao, a PAM izvješćuje samo da je složaj rekao ne. Ručno pokretanje pomoćnog programa kao root također ništa ne dokazuje, jer provjerava put privilegija koji usluga nikada ne koristi. Pročitajte unit koji je systemd stvarno učitao, a zatim sistemski zapis za pokušaj koji je napravio. Ta dva pogleda razdvajaju problem sandboxa od problema pogrešne lozinke.

Pročitajte unit prije nego što pročitate zapis lozinki

Zapakirani unit može nositi drop-in koji niste napisali, a stvarna konfiguracija je spojeni rezultat. Ispišite unit kako ga systemd vidi, zajedno s postavkama sandboxa koje odlučuju može li se pomoćni program sam podići. Inspekcija samo za čitanje dovoljna je u ovoj fazi.

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

Prva naredba pokazuje odakle dolaze unit i njegovi drop-inovi, što je važno jer nadjačavanje dodano prije mjeseci nadživi sjećanje na razlog svog postojanja. Druga ispisuje vrijednosti sandboxa o kojima ovise sljedeća dva odjeljka.

Usporedite ono što vidite s ispravnim hostom iste distribucije i verzije. Razlika u User, CapabilityBoundingSet ili NoNewPrivileges konkretan je trag; razlika u komentarima proze nije. Zapišite vrijednosti prije bilo kakve promjene, jer kasnija usporedba s pokretnom metom ništa ne dokazuje. Ako usluga radi pod neprivilegiranim računom s praznim bounding skupom, pomoćni program gotovo da nema s čime raditi.

Transformacija vjerodajnica, pristup datotekama i politika tri su granice

Počnite s onim što se događa tijekom exec. setuid binarna datoteka ili datoteka s datotečnim capabilities pokreće transformaciju vjerodajnica, pa rezultirajući identitet nije nastavak pozivatelja. Bounding skup ograničava što takva datoteka može steći, a NoNewPrivileges izravno blokira stjecanje setuid, setgid i datotečnih capabilities. Bilo koja od te tri može zaustaviti pomoćni program, a sve ostale funkcije usluge ostaju netaknute.

Zatim odvojite široko diskrecijsko zaobilaženje od uskog pristupa čitanju. CAP_DAC_OVERRIDE preskače diskrecijske provjere gotovo posvuda, dok CAP_DAC_READ_SEARCH pokriva čitanje i prolaz kroz direktorije sa svojim dodatnim ovlastima. To su različiti alati s različitim radijusom djelovanja i nijedan nije način da se napiše neka PAM čita shadow datoteku.

Na kraju, pitajte dopušta li obvezna politika tu radnju uopće. Linux capability ne nadjačava SELinux, a posjedovanje jedne ne dokazuje ništa o pravilu type enforcement. Odbijanje pristupa datoteci i odbijanje capabilityja tretirajte kao različite dokaze, jer imenuju različite popravke i često različite vlasnike. Pročitajte svako polje zapisa, a ne samo riječ denied. Koja je izvršna datoteka izvršila radnju, u kojoj je domeni radila, kojeg se tipa cilja dotaknula, koja je klasa objekta bila uključena i koje je dopuštenje politika odbila — svako na svoj način sužava odgovor.

Izvučite odbijanje iz revizijskog zapisa

Na hostu u načinu primjene revizijski trag jedino je mjesto koje bilježi odbijanje. Zatražite nedavne događaje i čitajte ih prema vremenskoj oznaci neuspjele prijave, a ne prema vremenu kada ste započeli istragu.

ausearch -m AVC,USER_AVC -ts recent

Prazan rezultat nije dokaz nevinosti. Znači ili da revizija ne prikuplja, ili da je vaš prozor propustio pokušaj, a obje mogućnosti treba isključiti prije nego što isključite politiku.

Red Hatove smjernice za rješavanje problema sa SELinuxom stavljaju provjere oznaka i konfiguracije prije generiranja pravila dopuštanja, što je pravi redoslijed i za ovaj problem. Pogrešno označena pomoćna datoteka i praznina u politici daju slična odbijanja, ali traže različite popravke. Generiranje pravila dopuštanja za pogrešku u označavanju skriva kvar i prepušta sljedećem ažuriranju paketa da ga ponovno uvede. Potvrdite oznaku instaliranog pomoćnog programa prije pisanja bilo kakve politike.

Dokažite promjenu jednom prihvaćenom i jednom odbijenom prijavom

Promijenite samo granicu koju ste dokazali, zatim isprobajte oba ishoda. Račun koji se treba autentificirati mora uspjeti, a račun s pogrešnom lozinkom mora i dalje ne uspjeti. Promjena koja čini da svaki pokušaj uspije uklonila je autentifikaciju umjesto da je popravi.

Napravite stvarni pokušaj veze i odmah zatim pročitajte dnevnik. Redak koji dokazuje popravak jest unos pam_unix(openvpn:auth) za taj pokušaj: treba pisati uspješna autentifikacija, i nijedan zapis AVC ne smije nositi istu sekundu.

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

Ispravan tunel treba i ponovno povezivanje, jer promjene sandboxa češće prekidaju drugu vezu nego prvu. Provjerite uspostavljeni socket nakon ponovnog povezivanja i potvrdite da ga isti unit još poslužuje.