Preverjanje pristnosti s PAM deluje ročno, kot storitev OpenVPN pa odpove

Preverjanje pristnosti prek PAM lahko uspe, ko odjemalca zaženete ročno, in odpove z AUTH_FAILED takoj ko systemd zažene isti profil. Geslo se med tema zagonoma ne spremeni; spremeni se nabor omejitev okoli procesa, ki PAM postavlja vprašanje. PAM odgovarja prek pomočnika, katerega zmožnost spreminjanja lastnih poverilnic je natanko tisto, kar utrjena enota odstrani. Poiščite tega pomočnika in mejo, ki jo potrebuje, preden se dotaknete seznama zmožnosti.

unix_chkpwd je binarna datoteka, ki odgovori na vprašanje PAM

Pri lokalnem preverjanju pristnosti z geslom pam_unix le redko sam bere zgoščeno datoteko. Zažene unix_chkpwd, ki ga distribucije namestijo kot setuid root ali setgid shadow, da se eno geslo lahko preveri v imenu procesa, ki naj ne bi bral /etc/shadow. Odvzemite zmožnost pridobitve te identitete in pomočnik ne more dokončati preverjanja, zato modul vrne običajno napako preverjanja pristnosti.

Napaka se nato v vsakem dnevniku, ki ga odjemalec vidi, kaže kot težava s poverilnicami. To je past: odjemalec poroča, kar mu je povedal PAM, PAM pa poroča le, da je sklad rekel ne. Ročni zagon pomočnika kot root prav tako ničesar ne dokaže, ker preizkusi pot privilegijev, ki je storitev nikoli ne uporabi. Preberite enoto, ki jo je systemd dejansko naložil, in nato sistemski dnevnik za izvedeni poskus. Ta dva pogleda ločita težavo peskovnika od težave z napačnim geslom.

Preberite enoto, preden preberete dnevnik gesel

Pakirana enota lahko nosi drop-in, ki ga niste napisali, dejanska konfiguracija pa je združen rezultat. Izpišite enoto, kot jo vidi systemd, skupaj z nastavitvami peskovnika, ki odločajo, ali se pomočnik lahko dvigne sam. V tej fazi zadošča pregled samo za branje.

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

Prvi ukaz pokaže, od kod prihajajo enota in njeni drop-ini, kar je pomembno, ker preglasitev, dodana pred meseci, živi dlje od spomina, zakaj obstaja. Drugi izpiše vrednosti peskovnika, od katerih sta odvisna naslednja dva razdelka.

Primerjajte, kar vidite, z delujočim gostiteljem iste distribucije in različice. Razlika v User, CapabilityBoundingSet ali NoNewPrivileges je konkreten namig; razlika v komentarjih proze ni. Zapišite vrednosti, preden karkoli spremenite, ker poznejša primerjava s premikajočo se tarčo ničesar ne dokaže. Če storitev teče kot neprivilegiran račun s praznim omejitvenim naborom, pomočnik nima skoraj ničesar za delo.

Preoblikovanje poverilnic, dostop do datotek in politika so tri meje

Začnite s tem, kar se zgodi med exec. Binarna datoteka setuid ali datoteka z file capabilities sproži preoblikovanje poverilnic, zato nastala identiteta ni nadaljevanje klicatelja. Omejitveni nabor omejuje, kaj lahko taka datoteka pridobi, in NoNewPrivileges popolnoma blokira pridobitev setuid, setgid in file capabilities. Katera koli od teh treh lahko ustavi pomočnika, medtem ko vsaka druga funkcija storitve ostane nedotaknjena.

Nato ločite široko diskrecijsko obhajanje od ozkega dostopa za branje. CAP_DAC_OVERRIDE preskoči diskrecijske kontrole skoraj povsod, medtem ko CAP_DAC_READ_SEARCH pokriva branje in prehod po imenikih z lastnimi dodatnimi pooblastili. To sta različni orodji z različnim dosegom, in nobeno ni način, da napišete naj PAM bere datoteko shadow.

Nazadnje vprašajte, ali obvezna politika dejanje sploh dovoljuje. Zmožnost Linuxa ne preglasi SELinuxa in imeti jo ne dokaže ničesar o pravilu uveljavljanja tipov. Zavrnitev dostopa do datoteke in zavrnitev zmožnosti obravnavajte kot različna dokaza, ker imenujeta različne popravke in pogosto različne lastnike. Preberite vsako polje zapisa namesto same besede denied. Kateri izvršljivi program je izvedel dejanje, v kateri domeni je tekel, kakšne vrste cilja se je dotaknil, kateri razred predmeta je bil vpleten in katero dovoljenje je politika zavrnila - vsako od tega odgovor zoži na drug način.

Izvlecite zavrnitev iz revizijskega dnevnika

Na gostitelju v načinu enforcing je revizijska sled edino mesto, ki zabeleži zavrnitev. Poizvedite po nedavnih dogodkih in jih berite glede na časovni žig neuspešne prijave, ne glede na čas, ko ste začeli preiskavo.

ausearch -m AVC,USER_AVC -ts recent

Prazen rezultat ni dokaz nedolžnosti. Pomeni bodisi da revizija ne zbira podatkov bodisi da je vaše okno poskus zgrešilo, in obe možnosti je treba izključiti, preden izključite politiko.

Smernice Red Hata za odpravljanje težav s SELinux postavljajo preverjanja oznak in konfiguracije pred ustvarjanjem dovoljevalnih pravil, kar je tudi pravi vrstni red za to težavo. Napačno označena pomožna binarna datoteka in vrzel v politiki dajeta podobne zavrnitve, a zahtevata različne popravke. Ustvarjanje dovoljevalnega pravila za napako oznake skrije napako in pusti naslednji posodobitvi paketa, da jo znova vnese. Potrdite oznako na nameščenem pomočniku, preden napišete kakršno koli politiko.

Dokažite spremembo z eno sprejeto in eno zavrnjeno prijavo

Spremenite le mejo, ki ste jo dokazali, nato preizkusite oba izida. Račun, ki bi se moral preveriti, mora uspeti, račun z napačnim geslom pa mora še vedno odpovedati. Sprememba, po kateri uspe vsak poskus, je preverjanje pristnosti odstranila, ne popravila.

Izvedite resničen poskus povezave in takoj zatem preberite dnevnik. Vrstica, ki dokaže popravek, je vnos pam_unix(openvpn:auth) za ta poskus: navesti mora uspeh preverjanja pristnosti in noben zapis AVC ne sme nositi iste sekunde.

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

Delujoč tunel potrebuje tudi ponovno povezavo, ker spremembe peskovnika pokvarijo drugo povezavo pogosteje kot prvo. Po ponovni povezavi preverite vzpostavljeni vtič in potrdite, da ga še vedno streže ista enota.