PAM-autentimine töötab käsitsi, kuid ebaõnnestub OpenVPN-i teenusena

PAM-i kaudu autentimine võib õnnestuda, kui käivitate kliendi käsitsi, ja ebaõnnestuda veaga AUTH_FAILED, kui systemd sama profiili käivitab. Parool nende käivituste vahel ei muutu; muutub protsessi ümbritsevate piirangute hulk, mis PAM-ilt küsib. PAM vastab abiprogrammi kaudu, mille võime oma mandaate muuta on täpselt see, mille karastatud unit eemaldab. Leidke see abiprogramm ja selle vajalik piir enne, kui puudutate võimete nimekirja.

unix_chkpwd on binaarfail, mis vastab PAM-i küsimusele

Kohaliku parooli autentimisel loeb pam_unix harva räsifaili ise. See käivitab unix_chkpwd, mille distributsioonid paigaldavad setuid root või setgid shadow kujul, et ühte parooli saaks kontrollida protsessi nimel, millel pole mingit asja lugeda /etc/shadow. Eemaldage võimalus see identiteet omandada ja abiprogramm ei saa kontrolli lõpule viia, mistõttu moodul tagastab lihtsa autentimisvea.

Siis näeb viga kliendi nähtavas igas logis välja nagu mandaadiprobleem. See on lõks: klient teatab, mida PAM talle ütles, ja PAM teatab ainult, et virn ütles ei. Abiprogrammi käsitsi rootina käivitamine ei tõesta samuti midagi, sest see proovib õiguste rada, mida teenus kunagi ei kasuta. Lugege unit, mille systemd tegelikult laadis, ja seejärel süsteemilogi tehtud katse kohta. Need kaks vaadet eraldavad sandbox-probleemi vale parooli probleemist.

Lugege unit enne, kui loete paroolilogi

Pakendatud unit võib sisaldada drop-in-i, mida te ei kirjutanud, ja tegelik konfiguratsioon on liidetud tulemus. Printige unit nii, nagu systemd seda näeb, koos sandboxi seadetega, mis otsustavad, kas abiprogramm saab end tõsta. Ainult lugemiseks vaatamine on selles etapis piisav.

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

Esimene käsk näitab, kust unit ja selle drop-in-id tulevad, mis on oluline, sest kuid tagasi lisatud alistamine elab kauem kui mälu selle kohta, miks see olemas on. Teine prindib sandboxi väärtused, millest järgmised kaks jaotist sõltuvad.

Võrrelge nähtut sama distributsiooni ja versiooni töötava hostiga. Erinevus väärtuses User, CapabilityBoundingSet või NoNewPrivileges on konkreetne vihje; erinevus proosakommentaarides ei ole. Kirjutage väärtused üles enne muudatuste tegemist, sest hilisem võrdlus liikuva sihtmärgiga ei tõesta midagi. Kui teenus töötab mitteprivilegeeritud kontoga ja tühja bounding-komplektiga, pole abiprogrammil peaaegu millegagi töötada.

Mandaatide teisendamine, failijuurdepääs ja poliitika on kolm piiri

Alustage sellest, mis toimub exec-i ajal. setuid-binaarfail või failikõlblusi kandev fail käivitab mandaatide teisendamise, nii et saadud identiteet ei ole kutsuja jätk. Bounding-komplekt piirab, mida selline fail võib omandada, ja NoNewPrivileges blokeerib setuid-, setgid- ja failikõlbluste omandamise täielikult. Ükskõik milline neist kolmest võib abiprogrammi peatada, jättes kõik muud teenuse funktsioonid puutumata.

Järgmisena eraldage lai diskretsiooniline möödaminek kitsast lugemisjuurdepääsust. CAP_DAC_OVERRIDE jätab diskretsioonilised kontrollid peaaegu kõikjal vahele, samas kui CAP_DAC_READ_SEARCH katab lugemise ja kataloogide läbimise oma täiendavate volitustega. Need on erinevad tööriistad erineva mõjuraadiusega ja kumbki ei ole kirjapilt lausele lase PAM-il shadow-faili lugeda.

Lõpuks küsige, kas kohustuslik poliitika üldse lubab seda toimingut. Linuxi võime ei tühista SELinuxi ja selle omamine ei tõesta midagi type enforcement reegli kohta. Käsitlege failijuurdepääsu keeldumist ja võime keeldumist erinevate tõenditena, sest need nimetavad erinevaid parandusi ja sageli erinevaid omanikke. Lugege kirje iga välja, mitte ainult sõna denied. Milline käivitatav fail toimingu tegi, millises domeenis see töötas, millist tüüpi sihtmärki see puudutas, milline objektiklass oli kaasatud ja millist luba poliitika keeldus — igaüks kitsendab vastust erineval viisil.

Tõmmake keeldumine auditilogist välja

Jõustaval hostil on auditijälg ainus koht, mis keeldumise salvestab. Pärige viimaseid sündmusi ja lugege neid ebaõnnestunud sisselogimise ajatempli järgi, mitte uurimise alustamise aja järgi.

ausearch -m AVC,USER_AVC -ts recent

Tühi tulemus ei ole süütuse tõestus. See tähendab, et kas auditeerimine ei kogu, või et teie aken jättis katse vahele, ja mõlemad võimalused tuleb välistada enne, kui poliitika välistate.

Red Hati SELinuxi tõrkeotsingu juhend seab siltide ja konfiguratsiooni kontrollid enne allow-reeglite genereerimist, mis on ka selle probleemi jaoks õige järjekord. Valesti sildistatud abiprogramm ja poliitika lünk tekitavad sarnaseid keeldumisi, kuid vajavad erinevaid parandusi. Sildistusvea jaoks allow-reegli genereerimine peidab vea ja jätab järgmisele paketiuuendusele selle taastoomise. Kinnitage paigaldatud abiprogrammi silt enne mis tahes poliitika kirjutamist.

Tõestage muudatust ühe vastuvõetud ja ühe tagasi lükatud sisselogimisega

Muutke ainult seda piiri, mida tõestasite, seejärel testige mõlemat tulemust. Konto, mis peaks autentima, peab õnnestuma, ja vale parooliga konto peab endiselt ebaõnnestuma. Muudatus, mis teeb iga katse edukaks, on autentimise eemaldanud, mitte parandanud.

Tehke tegelik ühenduskatse ja lugege päevikut kohe pärast seda. Rida, mis paranduse tõestab, on selle katse pam_unix(openvpn:auth) kirje: see peaks näitama edukat autentimist ja ükski AVC kirje ei tohi kanda sama sekundit.

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

Töötav tunnel vajab ka taasühendust, sest sandboxi muudatused katkestavad teise ühenduse sagedamini kui esimese. Kontrollige pärast taasühendust loodud socketit ja kinnitage, et sama unit teenindab seda endiselt.