Autentizace přes PAM funguje ručně, ale jako služba OpenVPN selhává

Autentizace přes PAM může uspět, když klienta spustíte ručně, a selhat s AUTH_FAILED, jakmile systemd spustí stejný profil. Heslo se mezi těmito spuštěními nemění; mění se soubor omezení kolem procesu, který se PAM ptá. PAM odpovídá prostřednictvím pomocného programu, jehož schopnost měnit vlastní přihlašovací údaje je přesně to, co zpevněná unit odstraňuje. Najděte tento pomocný program a hranici, kterou potřebuje, než se dotknete seznamu capabilities.

unix_chkpwd je binárka, která odpovídá na otázku PAM

Při místní autentizaci heslem pam_unix jen zřídka čte samotný hash soubor. Spouští unix_chkpwd, který distribuce instalují jako setuid root nebo setgid shadow, aby šlo jedno heslo ověřit jménem procesu, který nemá co činit se čtením /etc/shadow. Odeberte možnost získat tuto identitu a pomocný program nemůže kontrolu dokončit, takže modul vrátí obyčejné selhání autentizace.

Selhání pak ve všech protokolech, které klient vidí, vypadá jako problém s přihlašovacími údaji. To je past: klient hlásí, co mu řekla PAM, a PAM hlásí jen, že stack řekl ne. Ruční spuštění pomocného programu jako root také nic nedokazuje, protože procvičuje cestu oprávnění, kterou služba nikdy nepoužívá. Přečtěte si unit, kterou systemd skutečně načetl, a potom systémový protokol pro daný pokus. Tyto dva pohledy oddělují problém sandboxu od problému špatného hesla.

Přečtěte si unit dřív, než si přečtete protokol hesel

Zabalená unit může nést drop-in, který jste nenapsali, a efektivní konfigurace je sloučený výsledek. Vypište unit tak, jak ji vidí systemd, spolu s nastavením sandboxu, které rozhoduje, zda se pomocný program může sám povýšit. Inspekce pouze pro čtení je v této fázi dostačující.

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

První příkaz ukazuje, odkud unit a její drop-iny pocházejí, což je důležité, protože přepis přidaný před měsíci přežije paměť o tom, proč existuje. Druhý vypisuje hodnoty sandboxu, na kterých závisí následující dvě sekce.

Porovnejte, co vidíte, s funkčním hostitelem stejné distribuce a verze. Rozdíl v User, CapabilityBoundingSet nebo NoNewPrivileges je konkrétní stopa; rozdíl v textových komentářích ne. Zapište hodnoty, než cokoli změníte, protože pozdější srovnání s pohyblivým cílem nic nedokazuje. Pokud služba běží pod neprivilegovaným účtem s prázdnou bounding množinou, pomocný program nemá téměř s čím pracovat.

Transformace přihlašovacích údajů, přístup k souborům a politika jsou tři hranice

Začněte tím, co se děje během exec. setuid binárka nebo soubor nesoucí souborové capabilities spustí transformaci přihlašovacích údajů, takže výsledná identita není pokračováním volajícího. Bounding množina omezuje, co taková binárka může získat, a NoNewPrivileges rovnou blokuje získání setuid, setgid a souborových capabilities. Kterákoli z těch tří může pomocný program zastavit, aniž by ostatní funkce služby utrpěly.

Dále oddělte široké diskreční obcházení od úzkého přístupu pro čtení. CAP_DAC_OVERRIDE přeskakuje diskreční kontroly téměř všude, zatímco CAP_DAC_READ_SEARCH pokrývá čtení a průchod adresáři se svými dalšími pravomocemi. Jsou to různé nástroje s různým dosahem a ani jeden není způsobem, jak napsat „ať PAM čte shadow soubor“.

Nakonec se zeptejte, zda povinná politika akci vůbec dovoluje. Linux capability nepřebíjí SELinux a její držení nic nedokazuje o pravidle type enforcement. Odmítnutí přístupu k souboru a odmítnutí capability berte jako odlišné důkazy, protože pojmenovávají různé opravy a často různé vlastníky. Čtěte každé pole záznamu, ne jen slovo denied. Která spustitelná binárka akci provedla, v jaké doméně běžela, jakého typu byl cíl, jaká třída objektu byla zapojena a které oprávnění politika odmítla – každé zužuje odpověď jiným způsobem.

Vytáhněte odmítnutí z auditního protokolu

Na hostiteli v režimu vynucení je auditní stopa jediné místo, které odmítnutí zaznamenává. Vyhledejte nedávné události a čtěte je proti časovému razítku neúspěšného přihlášení, ne proti času, kdy jste začali vyšetřovat.

ausearch -m AVC,USER_AVC -ts recent

Prázdný výsledek není důkaz neviny. Znamená buď že audit nesbírá, nebo že vaše okno pokus minulo, a obě možnosti je třeba vyloučit, než politiku vyloučíte.

Pokyny Red Hatu k řešení problémů se SELinuxem staví kontroly popisků a konfigurace před generování pravidel allow, což je správné pořadí i pro tento problém. Špatně označená pomocná binárka a mezera v politice dávají podobná odmítnutí, ale vyžadují různé opravy. Vygenerování pravidla allow pro chybu v označení skryje závadu a nechá příští aktualizaci balíčku ji znovu zavést. Potvrďte popisek nainstalovaného pomocného programu, než napíšete jakoukoli politiku.

Dokažte změnu jedním přijatým a jedním odmítnutým přihlášením

Změňte jen hranici, kterou jste prokázali, a pak otestujte oba výsledky. Účet, který se má autentizovat, musí uspět, a účet se špatným heslem musí stále selhat. Změna, která nechá uspět každý pokus, autentizaci spíš odstranila, než opravila.

Proveďte skutečný pokus o připojení a hned potom si přečtěte journal. Řádek, který opravu dokazuje, je záznam pam_unix(openvpn:auth) pro tento pokus: má uvádět úspěšnou autentizaci a žádný záznam AVC nemá nést stejnou sekundu.

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

Funkční tunel potřebuje i opětovné připojení, protože změny sandboxu častěji rozbijí druhé připojení než první. Po opětovném připojení zkontrolujte navázaný socket a potvrďte, že ho stále obsluhuje stejná unit.