PAM provjera autentičnosti radi ručno, ali kao OpenVPN usluga ne uspijeva

Provjera autentičnosti preko PAM-a može uspjeti kada klijent pokrenete ručno i ne uspjeti s AUTH_FAILED čim systemd pokrene isti profil. Zaporka se ne mijenja između tih pokretanja; mijenja se skup ograničenja oko procesa koji PAM-u postavlja pitanje. PAM odgovara preko pomoćnika čija je sposobnost promjene vlastitih vjerodajnica upravo ono što očvršćena jedinica uklanja. Nađite tog pomoćnika i granicu koja mu treba prije nego što dotaknete popis sposobnosti.

unix_chkpwd je binarna datoteka koja odgovara na PAM pitanje

Uz lokalnu provjeru autentičnosti zaporkom pam_unix rijetko sam čita datoteku sažetka. Izvršava unix_chkpwd, koji distribucije instaliraju kao setuid root ili setgid shadow kako bi se jedna zaporka mogla provjeriti u ime procesa koji ne bi trebao čitati /etc/shadow. Uklonite mogućnost stjecanja tog identiteta i pomoćnik ne može dovršiti provjeru, pa modul vraća običnu pogrešku provjere autentičnosti.

Neuspjeh tada u svakom zapisu koji klijent vidi izgleda kao problem s vjerodajnicama. To je zamka: klijent izvještava što mu je PAM rekao, a PAM izvještava samo da je stog rekao ne. Ručno pokretanje pomoćnika kao root također ništa ne dokazuje, jer prožima putanju privilegija koju usluga nikad ne koristi. Pročitajte jedinicu koju je systemd stvarno učitao, a zatim sistemski zapis za pokušaj koji je izveo. Ta dva pogleda razdvajaju problem sandboxa od problema pogrešne zaporke.

Pročitajte jedinicu prije nego što pročitate zapis zaporki

Zapakirana jedinica može nositi drop-in koji niste napisali, a stvarna konfiguracija je spojeni rezultat. Ispišite jedinicu kako je vidi systemd, zajedno s postavkama sandboxa koje odlučuju može li se pomoćnik sam podići. Pregled samo za čitanje dovoljan 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 jedinica i njezini drop-inovi, što je važno jer nadjačavanje dodano prije mjeseci živi dulje od sjećanja zašto postoji. 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 nego što bilo što promijenite, jer kasnija usporedba s pokretnom metom ništa ne dokazuje. Ako usluga radi kao neprivilegirani račun s praznim ograničavajućim skupom, pomoćnik gotovo da nema s čime raditi.

Preobrazba vjerodajnica, pristup datotekama i politika tri su granice

Počnite s onim što se događa tijekom exec. Binarna datoteka setuid ili datoteka s file capabilities pokreće preobrazbu vjerodajnica, pa rezultirajući identitet nije nastavak pozivatelja. Ograničavajući skup ograničava što takva datoteka može steći, a NoNewPrivileges potpuno blokira stjecanje setuid, setgid i file capabilities. Bilo koja od te tri može zaustaviti pomoćnika dok svaka druga funkcija usluge ostaje netaknuta.

Zatim razdvojite š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 mape s vlastitim dodatnim ovlastima. To su različiti alati s različitim dosegom i nijedan nije način da napišete neka PAM čita shadow datoteku.

Na kraju, pitajte dopušta li obvezna politika to djelovanje uopće. Linux sposobnost ne nadjačava SELinux, a njezino posjedovanje ništa ne dokazuje o pravilu provedbe tipova. Odbijanje pristupa datoteci i odbijanje sposobnosti tretirajte kao različite dokaze, jer imenuju različite popravke i često različite vlasnike. Čitajte svako polje zapisa umjesto jedne riječi denied. Koji je izvršni program izveo djelovanje, u kojoj je domeni radio, kakve se vrste mete dotaknuo, koji je razred objekta bio uključen i koje je dopuštenje politika odbila - svako od toga suzuje odgovor na drugi način.

Izvucite odbijanje iz revizijskog zapisa

Na hostu u načinu enforcing revizijski je trag jedino 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 podatke, ili da je vaš prozor propustio pokušaj, i obje mogućnosti treba isključiti prije nego što isključite politiku.

Red Hat smjernice za rješavanje problema sa SELinux postavljaju provjere oznaka i konfiguracije prije stvaranja pravila dopuštanja, što je i ispravan redoslijed za ovaj problem. Pogrešno označena pomoćna binarna datoteka i praznina u politici daju slična odbijanja, ali traže različite popravke. Stvaranje pravila dopuštanja za pogrešku oznake skriva kvar i pušta sljedećem ažuriranju paketa da ga ponovno uvede. Potvrdite oznaku na instaliranom pomoćniku prije nego što napišete ikakvu politiku.

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 zaporkom mora i dalje ne uspijevati. Promjena nakon koje svaki pokušaj uspije uklonila je provjeru autentičnosti umjesto da je popravi.

Izvedite stvarni pokušaj povezivanja i odmah zatim pročitajte journal. Redak koji dokazuje popravak jest unos pam_unix(openvpn:auth) za taj pokušaj: mora navoditi uspjeh provjere autentičnosti 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 kvare drugu vezu češće od prve. Provjerite uspostavljeni socket nakon ponovnog povezivanja i potvrdite da ga ista jedinica još poslužuje.