PAM-verifikasie werk met die hand maar misluk as ’n OpenVPN-diens

Verifikasie deur PAM kan slaag wanneer jy die kliënt met die hand laat loop, en met AUTH_FAILED misluk sodra systemd dieselfde profiel begin. Die wagwoord verander nie tussen daardie lopies nie; wat verander, is die stel beperkings rondom die proses wat PAM die vraag vra. PAM antwoord deur ’n helper wie se vermoë om sy eie geloofsbriewe te verander juis is wat ’n geharde eenheid verwyder. Vind daardie helper en die grens wat hy nodig het voordat jy ’n vermoëlys aanraak.

unix_chkpwd is die program wat die PAM-vraag beantwoord

Met plaaslike wagwoordverifikasie, lees pam_unix selde self die hash-lêer. Dit voer unix_chkpwd uit, wat verspreidings setuid-root of setgid-shadow installeer sodat een wagwoord namens ’n proses nagegaan kan word wat niks daarmee te doen het om /etc/shadow te lees nie. Verwyder die vermoë om daardie identiteit te verkry, en die helper kan die kontrole nie voltooi nie, so die module gee ’n gewone verifikasiefout terug.

Die fout lyk dan soos ’n geloofsbriefprobleem in elke log wat die kliënt kan sien. Dit is die lokval: die kliënt rapporteer wat PAM hom vertel het, en PAM rapporteer net dat die stapel nee gesê het. Om die helper met die hand as root te laat loop, bewys ook niks, want dit oefen ’n voorregpad uit wat die diens nooit gebruik nie. Lees die eenheid wat systemd werklik gelaai het, en lees dan die stelsellog vir die poging wat dit gemaak het. Daardie twee sienings skei ’n sandputprobleem van ’n verkeerde-wagwoordprobleem.

Lees die eenheid voordat jy die wagwoordlog lees

’n Verpakte eenheid kan ’n drop-in bevat wat jy nie geskryf het nie, en die effektiewe konfigurasie is die saamgevoegde resultaat. Druk die eenheid soos systemd dit sien, saam met die sandputinstellings wat besluit of die helper homself kan verhef. Net-lees-inspeksie is op hierdie stadium genoeg.

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

Die eerste opdrag wys waar die eenheid en sy drop-ins vandaan kom, wat saak maak omdat ’n oorheersing wat maande gelede bygevoeg is, die geheue van hoekom dit bestaan oorleef. Die tweede druk die sandputwaardes wat die volgende twee afdelings nodig het.

Vergelyk wat jy sien met ’n werkende gasheer van dieselfde verspreiding en weergawe. ’n Verskil in User, CapabilityBoundingSet of NoNewPrivileges is ’n konkrete leidraad; ’n verskil in prosa-kommentaar is nie. Skryf die waardes neer voordat jy iets verander, want ’n latere vergelyking teen ’n bewegende teiken bewys niks. As die diens as ’n onbevoorregte rekening met ’n leë bounding-stel loop, het die helper byna niks om mee te werk nie.

Geloofsbrief-transformasie, lêertoegang en beleid is drie grense

Begin met wat tydens exec gebeur. ’n Setuid-program of ’n lêer met lêervermoëns veroorsaak ’n geloofsbrieftransformasie, so die resulterende identiteit is nie ’n voortsetting van die oproeper nie. Die bounding-stel perk wat so ’n program mag verkry, en NoNewPrivileges blokkeer setuid-, setgid- en lêervermoë-verkryging heeltemal. Enige een van daardie drie kan die helper stop terwyl elke ander diensfunksie ongeskonde bly.

Skei vervolgens breë diskresionêre omseiling van noue leestoegang. CAP_DAC_OVERRIDE slaan diskresionêre kontroles byna oral oor, terwyl CAP_DAC_READ_SEARCH lees en gidsdeurloop dek met sy eie bykomende magte. Hulle is verskillende gereedskap met verskillende trefwydtes, en nie een is ’n spelling van laat PAM die shadow-lêer lees nie.

Vra laastens of die verpligte beleid die handeling hoegenaamd toelaat. ’n Linux-vermoë oorheers nie SELinux nie, en om een te hou bewys niks oor ’n tipe-afdwingingsreël nie. Behandel ’n lêertoegang-weiering en ’n vermoë-weiering as verskillende bewyse, want hulle noem verskillende oplossings en dikwels verskillende eienaars. Lees elke veld van die rekord eerder as die enkele woord denied. Watter uitvoerbare lêer die handeling gedoen het, in watter domein dit geloop het, watter tipe teiken dit geraak het, watter klas objek betrokke was en watter toestemming die beleid geweier het, vernou die antwoord elkeen op ’n ander manier.

Trek die weiering uit die Ouditlog

Op ’n afdwingende gasheer is die ouditspoor die enigste plek wat ’n weiering aanteken. Vra die onlangse gebeure na en lees hulle teen die tydstempel van die mislukte aanmelding, nie teen die tyd toe jy begin ondersoek het nie.

ausearch -m AVC,USER_AVC -ts recent

’n Leë resultaat is nie bewys van onskuld nie. Dit beteken óf dat ouditering nie versamel nie, óf dat jou venster die poging gemis het, en albei moontlikhede moet uitgesluit word voordat jy die beleid uitsluit.

Red Hat se SELinux-probleemoplossingsriglyne plaas etiket- en konfigurasiekontroles voor die genereer van toelaatreëls, wat ook vir hierdie probleem die regte volgorde is. ’n Verkeerd geëtiketteerde helper-program en ’n beleidsgaping lewer soortgelyke weierings maar benodig verskillende herstelwerk. Die genereer van ’n toelaatreël vir ’n etiketteringsfout verberg die fout en laat die volgende pakketopdatering dit herintroduceer. Bevestig die etiket op die geïnstalleerde helper voordat jy enige beleid skryf.

Bewys die verandering met een aanvaarde en een verworpe aanmelding

Verander net die grens wat jy gedemonstreer het, en toets dan albei uitkomste. ’n Rekening wat behoort te verifieer, moet slaag, en ’n rekening met ’n verkeerde wagwoord moet steeds misluk. ’n Verandering wat elke poging laat slaag, het verifikasie verwyder eerder as om dit te herstel.

Voer ’n werklike verbindingspoging uit en lees die joernaal dadelik daarna. Die reël wat die regstelling bewys, is die pam_unix(openvpn:auth)-inskrywing vir daardie poging: dit moet verifikasie geslaag lees, en geen AVC-rekord moet dieselfde sekonde hê nie.

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

’n Werkende tonnel het ook ’n herverbinding nodig, want sandputveranderinge breek die tweede verbinding dikwels meer as die eerste. Kontroleer die gevestigde socket na die herverbinding en bevestig dat dieselfde eenheid dit steeds bedien.