Autentifikácia PAM funguje ručne, ale ako služba OpenVPN zlyháva

Autentifikácia cez PAM môže uspieť, keď klienta spustíte ručne, a zlyhať s AUTH_FAILED hneď ako systemd spustí ten istý profil. Heslo sa medzi týmito spusteniami nemení; mení sa množina obmedzení okolo procesu, ktorý kladie PAM otázku. PAM odpovedá cez pomocník, ktorého schopnosť zmeniť vlastné poverenia je presne to, čo spevnená jednotka odstraňuje. Nájdite toho pomocníka a hranicu, ktorú potrebuje, skôr než sa dotknete zoznamu schopností.

unix_chkpwd je binárka, ktorá odpovedá na otázku PAM

Pri lokálnej autentifikácii heslom pam_unix zriedka číta hash súbor sám. Spúšťa unix_chkpwd, ktorý distribúcie inštalujú ako setuid root alebo setgid shadow, aby sa jedno heslo dalo overiť v mene procesu, ktorý nemá čo čítať /etc/shadow. Odoberte schopnosť získať túto identitu a pomocník nedokončí kontrolu, takže modul vráti obyčajné zlyhanie autentifikácie.

Zlyhanie potom v každom zázname, ktorý klient vidí, vyzerá ako problém s povereniami. To je pasca: klient hlási, čo mu povedala PAM, a PAM hlási len to, že zásobník povedal nie. Spustenie pomocníka ručne ako root tiež nič nedokazuje, pretože precvičuje cestu privilégií, ktorú služba nikdy nepoužíva. Prečítajte si jednotku, ktorú systemd skutočne načítal, a potom systémový záznam k vykonanému pokusu. Tieto dva pohľady oddeľujú problém sandboxu od problému nesprávneho hesla.

Prečítajte si jednotku skôr, než si prečítate záznam hesiel

Zabalená jednotka môže niesť drop-in, ktorý ste nenapísali, a efektívna konfigurácia je výsledkom zlúčenia. Vypíšte jednotku tak, ako ju vidí systemd, spolu s nastaveniami sandboxu, ktoré určujú, či sa pomocník môže sám povýšiť. Inšpekcia iba na čítanie v tejto fáze stačí.

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

Prvý príkaz ukazuje, odkiaľ jednotka a jej drop-iny pochádzajú, čo je dôležité, pretože prepis pridaný pred mesiacmi žije dlhšie než spomienka na to, prečo existuje. Druhý vypisuje hodnoty sandboxu, od ktorých závisia dve nasledujúce časti.

Porovnajte to, čo vidíte, s funkčným hostiteľom rovnakej distribúcie a verzie. Rozdiel v User, CapabilityBoundingSet alebo NoNewPrivileges je konkrétna stopa; rozdiel v komentároch prózy nie je. Zapíšte si hodnoty predtým, než čokoľvek zmeníte, pretože neskoršie porovnanie s pohyblivým cieľom nič nedokazuje. Ak služba beží ako neprivilegovaný účet s prázdnou obmedzujúcou množinou, pomocník nemá takmer s čím pracovať.

Transformácia poverení, prístup k súborom a politika sú tri hranice

Začnite tým, čo sa deje počas exec. Binárka setuid alebo súbor s file capabilities vyvolá transformáciu poverení, takže výsledná identita nie je pokračovaním volajúceho. Obmedzujúca množina určuje, čo takáto binárka môže získať, a NoNewPrivileges úplne blokuje získanie setuid, setgid a file capabilities. Ktorákoľvek z týchto troch môže pomocníka zastaviť a pritom nechať každú inú funkciu služby nedotknutú.

Ďalej oddeľte široké diskrečné obchádzanie od úzkeho prístupu na čítanie. CAP_DAC_OVERRIDE obchádza diskrečné kontroly takmer všade, kým CAP_DAC_READ_SEARCH pokrýva čítanie a prechod adresármi s vlastnými dodatočnými právomocami. Sú to rôzne nástroje s rôznym dosahom a ani jeden nie je spôsob, ako napísať nechaj PAM čítať shadow súbor.

Nakoniec sa opýtajte, či povinná politika túto akciu vôbec povoľuje. Schopnosť Linuxu neprebíja SELinux a jej vlastníctvo nič nedokazuje o pravidle vynucovania typov. Berte odmietnutie prístupu k súboru a odmietnutie schopnosti ako rozdielne dôkazy, pretože menujú rozdielne opravy a často rozdielnych vlastníkov. Čítajte každé pole záznamu namiesto jediného slova denied. Ktorý spustiteľný súbor akciu vykonal, v ktorej doméne bežal, aký typ cieľa sa dotkol, aká trieda objektu bola zapojená a ktoré povolenie politika odmietla - každé z toho zužuje odpoveď iným spôsobom.

Vytiahnite odmietnutie z audítorského záznamu

Na hostiteľovi v režime enforcing je audítorská stopa jediným miestom, ktoré zaznamenáva odmietnutie. Spýtajte sa na nedávne udalosti a čítajte ich vo vzťahu k časovej pečiatke zlyhaného prihlásenia, nie vo vzťahu k času, keď ste začali vyšetrovanie.

ausearch -m AVC,USER_AVC -ts recent

Prázdny výsledok nie je dôkazom neviny. Znamená buď že audit nezberá údaje, alebo že vaše okno pokus minulo, a obe možnosti treba vylúčiť skôr, než vylúčite politiku.

Príručka Red Hatu na riešenie problémov so SELinux stavia kontroly označenia a konfigurácie pred generovanie povoľovacích pravidiel, čo je správne poradie aj pre tento problém. Nesprávne označená pomocná binárka a medzera v politike dávajú podobné odmietnutia, ale vyžadujú rozdielne opravy. Generovanie povoľovacieho pravidla pre chybu označenia skryje závadu a nechá ďalšiu aktualizáciu balíka, aby ju znovu zaviedla. Potvrďte označenie na nainštalovanom pomocníkovi skôr, než napíšete akúkoľvek politiku.

Dokážte zmenu jedným prijatým a jedným odmietnutým prihlásením

Zmeňte iba hranicu, ktorú ste preukázali, a potom otestujte oba výsledky. Účet, ktorý sa má autentifikovať, musí uspieť, a účet s nesprávnym heslom musí stále zlyhávať. Zmena, po ktorej každý pokus uspeje, autentifikáciu odstránila, nie opravila.

Vykonajte skutočný pokus o pripojenie a hneď potom si prečítajte journal. Riadok, ktorý dokazuje opravu, je záznam pam_unix(openvpn:auth) pre ten pokus: má uvádzať úspech autentifikácie a žiadny záznam AVC nemá niesť tú istú sekundu.

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

Funkčný tunel potrebuje aj opätovné pripojenie, pretože zmeny sandboxu pokazia druhé pripojenie častejšie než prvé. Po opätovnom pripojení skontrolujte nadviazaný socket a potvrďte, že ho stále obsluhuje tá istá jednotka.