PAM-authenticatie werkt met de hand maar faalt als OpenVPN-service

Authenticatie via PAM kan slagen wanneer u de client met de hand start en mislukken met AUTH_FAILED zodra systemd hetzelfde profiel start. Het wachtwoord verandert niet tussen die pogingen; wat verandert is het geheel van beperkingen rond het proces dat PAM de vraag stelt. PAM antwoordt via een helper waarvan het vermogen om zijn eigen referenties te wijzigen precies is wat een geharde unit wegneemt. Zoek die helper en de grens die hij nodig heeft voordat u een capaciteitenlijst aanraakt.

unix_chkpwd is het binaire bestand dat de PAM-vraag beantwoordt

Met lokale wachtwoordauthenticatie leest pam_unix zelden zelf het hashbestand. Het voert unix_chkpwd uit, dat distributies setuid root of setgid shadow installeren zodat één wachtwoord kan worden gecontroleerd ten behoeve van een proces dat niets te maken hoort te hebben met het lezen van /etc/shadow. Neem het vermogen weg om die identiteit te verkrijgen en de helper kan de controle niet afronden, dus geeft de module een gewone authenticatiefout terug.

De fout ziet er dan in elk log uit dat de client kan zien als een probleem met de inloggegevens. Dat is de valkuil: de client meldt wat PAM hem vertelde, en PAM meldt alleen dat de stack nee zei. De helper met de hand als root draaien bewijst ook niets, want dat gebruikt een privilegeroute die de service nooit neemt. Lees de unit die systemd werkelijk heeft geladen en lees daarna het systeemlog over de poging die het deed. Die twee beelden scheiden een sandboxprobleem van een verkeerd wachtwoord.

Lees de unit voordat u het wachtwoordlog leest

Een verpakte unit kan een drop-in bevatten die u niet hebt geschreven, en de effectieve configuratie is het samengevoegde resultaat. Druk de unit af zoals systemd hem ziet, samen met de sandboxinstellingen die bepalen of de helper zichzelf kan verheffen. Alleen-lezen inspectie volstaat in dit stadium.

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

De eerste opdracht laat zien waar de unit en zijn drop-ins vandaan komen, wat ertoe doet omdat een override van maanden geleden langer leeft dan de herinnering waarom hij bestaat. De tweede drukt de sandboxwaarden af waar de volgende twee paragrafen van afhangen.

Vergelijk wat u ziet met een werkende host van dezelfde distributie en versie. Een verschil in User, CapabilityBoundingSet of NoNewPrivileges is een concreet spoor; een verschil in prozacommentaar is dat niet. Schrijf de waarden op voordat u iets verandert, want een latere vergelijking met een bewegend doel bewijst niets. Als de service als onbevoorrecht account met een lege reeks grenzen draait, heeft de helper bijna niets om mee te werken.

Referentietransformatie, bestandstoegang en beleid zijn drie grenzen

Begin met wat er tijdens exec gebeurt. Een setuid-binair bestand of een bestand met bestandscapaciteiten veroorzaakt een referentietransformatie, dus de resulterende identiteit is geen voortzetting van de aanroeper. De reeks grenzen begrenst wat zo'n binair bestand mag verwerven, en NoNewPrivileges blokkeert setuid-, setgid- en bestandscapaciteitsverwerving volledig. Elk van die drie kan de helper stoppen terwijl elke andere functie van de service intact blijft.

Scheid vervolgens brede discretionaire omzeiling van nauwe leestoegang. CAP_DAC_OVERRIDE slaat discretionaire controles bijna overal over, terwijl CAP_DAC_READ_SEARCH lezen en het doorlopen van mappen dekt met eigen extra bevoegdheden. Het zijn verschillende gereedschappen met een verschillende impact, en geen van beide is een spelling van laat PAM het shadowbestand lezen.

Vraag ten slotte of het verplichte beleid de handeling überhaupt toestaat. Een Linux-capaciteit overschrijft SELinux niet, en er een hebben bewijst niets over een regel voor type-handhaving. Behandel een weigering van bestandstoegang en een weigering van een capaciteit als verschillend bewijs, want ze noemen verschillende oplossingen en vaak verschillende eigenaren. Lees elk veld van de registratie in plaats van het enkele woord denied. Welk uitvoerbaar bestand de handeling verrichtte, in welk domein het draaide, welk type doel het aanraakte, welke klasse object betrokken was en welke toestemming het beleid weigerde, vernauwen het antwoord elk op een andere manier.

Haal de weigering uit het auditlog

Op een host met enforcing is het auditpad de enige plek die een weigering vastlegt. Vraag de recente gebeurtenissen op en lees ze tegen de tijdstempel van de mislukte login, niet tegen de tijd waarop u begon te onderzoeken.

ausearch -m AVC,USER_AVC -ts recent

Een leeg resultaat is geen bewijs van onschuld. Het betekent ofwel dat auditing niet verzamelt, ofwel dat uw venster de poging heeft gemist, en beide mogelijkheden moeten worden uitgesloten voordat u het beleid uitsluit.

De SELinux-richtlijn voor probleemoplossing van Red Hat plaatst label- en configuratiecontroles vóór het genereren van allow-regels, wat ook voor dit probleem de juiste volgorde is. Een verkeerd gelabeld helper-binair bestand en een gat in het beleid leveren vergelijkbare weigeringen op maar vergen verschillende reparaties. Een allow-regel genereren voor een labelfout verbergt de fout en zorgt dat de volgende pakketupdate hem opnieuw introduceert. Bevestig het label op de geïnstalleerde helper voordat u beleid schrijft.

Bewijs de wijziging met één geslaagde en één geweigerde login

Wijzig alleen de grens die u hebt aangetoond en test daarna beide uitkomsten. Een account dat moet authenticeren moet slagen, en een account met een verkeerd wachtwoord moet nog steeds falen. Een wijziging waardoor elke poging slaagt, heeft de authenticatie verwijderd in plaats van gerepareerd.

Voer een echte verbindingspoging uit en lees direct daarna het journal. De regel die de oplossing bewijst is de vermelding pam_unix(openvpn:auth) voor die poging: er moet authenticatiesucces staan en geen registratie AVC mag dezelfde seconde dragen.

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

Een werkende tunnel heeft ook een herverbinding nodig, want sandboxwijzigingen breken de tweede verbinding vaker dan de eerste. Controleer de gevestigde socket na de herverbinding en bevestig dat dezelfde unit hem nog steeds bedient.