PAM autentifikavimas rankiniu būdu veikia, bet kaip OpenVPN paslauga nepavyksta

Autentifikavimas per PAM gali pavykti, kai klientą paleidžiate rankiniu būdu, ir nepavykti su AUTH_FAILED, kai systemd paleidžia tą patį profilį. Slaptažodis tarp šių paleidimų nesikeičia; keičiasi aplink procesą, kuris užduoda PAM klausimą, esančių apribojimų rinkinys. PAM atsako per pagalbinę programą, kurios gebėjimas keisti savo prisijungimo duomenis ir yra būtent tai, ką pašalina sustiprintas unit. Raskite tą pagalbinę programą ir jai reikalingą ribą prieš liesdami galimybių sąrašą.

unix_chkpwd yra dvejetainis failas, atsakantis į PAM klausimą

Naudojant vietinį slaptažodžio autentifikavimą, pam_unix retai pats skaito maišos failą. Jis vykdo unix_chkpwd, kurį distribucijos įdiegia kaip setuid root arba setgid shadow, kad vieną slaptažodį būtų galima patikrinti proceso, kuris neturi jokio reikalo skaityti /etc/shadow, vardu. Pašalinkite galimybę įgyti tą tapatybę ir pagalbinė programa negalės užbaigti patikros, todėl modulis grąžina paprastą autentifikavimo klaidą.

Tada klaida atrodo kaip prisijungimo duomenų problema kiekviename žurnale, kurį klientas mato. Tai spąstai: klientas praneša, ką PAM jam pasakė, o PAM praneša tik tai, kad dėklas pasakė ne. Pagalbinės programos paleidimas rankiniu būdu kaip root taip pat nieko neįrodo, nes tai išbando privilegijų kelią, kurio paslauga niekada nenaudoja. Perskaitykite unit, kurį systemd iš tikrųjų įkėlė, tada sistemos žurnalą apie atliktą bandymą. Šie du vaizdai atskiria smėlio dėžės problemą nuo neteisingo slaptažodžio problemos.

Perskaitykite unit prieš skaitydami slaptažodžių žurnalą

Supakuotame unite gali būti drop-in, kurio neparašėte, o efektyvioji konfigūracija yra sujungtas rezultatas. Atspausdinkite unit taip, kaip jį mato systemd, kartu su smėlio dėžės nustatymais, kurie nusprendžia, ar pagalbinė programa gali save pakelti. Šiame etape pakanka tik skaitymo patikros.

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

Pirmoji komanda parodo, iš kur ateina unit ir jo drop-in, o tai svarbu, nes prieš mėnesius pridėtas perrašymas gyvena ilgiau nei atmintis apie tai, kodėl jis egzistuoja. Antroji atspausdina smėlio dėžės reikšmes, nuo kurių priklauso kiti du skyriai.

Palyginkite tai, ką matote, su veikiančiu tos pačios distribucijos ir versijos kompiuteriu. Skirtumas User, CapabilityBoundingSet arba NoNewPrivileges yra konkretus pėdsakas; skirtumas prozos komentaruose — ne. Užsirašykite reikšmes prieš ką nors keisdami, nes vėlesnis palyginimas su judančiu taikiniu nieko neįrodo. Jei paslauga veikia su neprivilegijuota paskyra ir tuščiu bounding rinkiniu, pagalbinė programa beveik neturi su kuo dirbti.

Prisijungimo duomenų transformacija, failų prieiga ir politika yra trys ribos

Pradėkite nuo to, kas vyksta exec metu. setuid dvejetainis failas arba failas su failų galimybėmis sukelia prisijungimo duomenų transformaciją, todėl gauta tapatybė nėra kviečiančiojo tęsinys. Bounding rinkinys riboja, ką toks failas gali įgyti, o NoNewPrivileges visiškai blokuoja setuid, setgid ir failų galimybių įgijimą. Bet kuri iš šių trijų gali sustabdyti pagalbinę programą, o visos kitos paslaugos funkcijos lieka nepažeistos.

Tada atskirkite plačią diskrecinę apėjimą nuo siauros skaitymo prieigos. CAP_DAC_OVERRIDE beveik visur praleidžia diskrecines patikras, o CAP_DAC_READ_SEARCH apima skaitymą ir katalogų perėjimą su savo papildomais įgaliojimais. Tai skirtingi įrankiai su skirtingu poveikio spinduliu, ir nė vienas nėra frazės leisk PAM skaityti shadow failą rašyba.

Galiausiai paklauskite, ar privalomoji politika apskritai leidžia šį veiksmą. Linux galimybė nepanaikina SELinux, o jos turėjimas nieko neįrodo apie type enforcement taisyklę. Failų prieigos atsisakymą ir galimybės atsisakymą traktuokite kaip skirtingus įrodymus, nes jie įvardija skirtingus taisymus ir dažnai skirtingus savininkus. Skaitykite kiekvieną įrašo lauką, o ne vien žodį denied. Kuris vykdomasis failas atliko veiksmą, kuriame domene jis veikė, kokio tipo taikinį jis palietė, kuri objekto klasė buvo susijusi ir kurį leidimą politika atmetė — kiekvienas skirtingai susiaurina atsakymą.

Ištraukite atmetimą iš audito žurnalo

Vykdančiajame kompiuteryje audito pėdsakas yra vienintelė vieta, kuri įrašo atmetimą. Užklauskite naujausių įvykių ir skaitykite juos pagal nepavykusio prisijungimo laiko žymą, o ne pagal laiką, kai pradėjote tyrimą.

ausearch -m AVC,USER_AVC -ts recent

Tuščias rezultatas nėra nekaltybės įrodymas. Tai reiškia, kad arba auditas nerenka, arba jūsų langas praleido bandymą, ir abi galimybės turi būti atmestos prieš atmetant politiką.

Red Hat SELinux trikčių šalinimo gairės etikečių ir konfigūracijos patikras iškelia prieš allow taisyklių generavimą, ir tai yra teisinga tvarka ir šiai problemai. Neteisingai pažymėtas pagalbinis dvejetainis failas ir politikos spraga duoda panašius atmetimus, bet reikalauja skirtingų taisymų. Allow taisyklės generavimas etiketės klaidai paslepia defektą ir leidžia kitam paketo atnaujinimui jį vėl įvesti. Patvirtinkite įdiegtos pagalbinės programos etiketę prieš rašydami bet kokią politiką.

Įrodykite pakeitimą vienu priimtu ir vienu atmestu prisijungimu

Pakeiskite tik tą ribą, kurią parodėte, tada išbandykite abu rezultatus. Paskyra, kuri turėtų autentifikuotis, turi pavykti, o paskyra su neteisingu slaptažodžiu turi vis tiek nepavykti. Pakeitimas, dėl kurio kiekvienas bandymas pavyksta, pašalino autentifikavimą, o ne jį sutaisė.

Atlikite tikrą ryšio bandymą ir iškart po jo perskaitykite žurnalą. Eilutė, įrodanti taisymą, yra to bandymo pam_unix(openvpn:auth) įrašas: joje turėtų būti nurodytas sėkmingas autentifikavimas, ir joks AVC įrašas neturi turėti tų pačių sekundžių.

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

Veikiančiam tuneliui taip pat reikia pakartotinio prisijungimo, nes smėlio dėžės pakeitimai dažniau nutraukia antrąjį ryšį nei pirmąjį. Patikrinkite nustatytą lizdą po pakartotinio prisijungimo ir patvirtinkite, kad tas pats unit vis dar jį aptarnauja.