PAM-auðkenning virkar í hönd en bregst sem OpenVPN-þjónusta

Auðkenning í gegnum PAM getur tekist þegar þú keyrir biðlarann í hönd og brugðist með AUTH_FAILED um leið og systemd ræsir sama prófíl. Lykilorðið breytist ekki milli þessara keyrslna; það sem breytist er mengi takmarkana í kringum ferlið sem spyr PAM spurningarinnar. PAM svarar í gegnum hjálparforrit sem hæfileikinn til að breyta eigin skilríkjum sínum er einmitt það sem hert unit fjarlægir. Finndu þetta hjálparforrit og mörkin sem það þarf áður en þú snertir getulista.

unix_chkpwd er tvíundarskráin sem svarar PAM-spurningunni

Með staðbundinni lykilorðsauðkenningu les pam_unix sjaldan hash-skrána sjálfa. Það keyrir unix_chkpwd, sem dreifingar setja upp sem setuid root eða setgid shadow svo hægt sé að sannreyna eitt lykilorð fyrir hönd ferlis sem hefur ekkert að gera við að lesa /etc/shadow. Fjarlægðu hæfileikann til að öðlast þessa auðkenni og hjálparforritið getur ekki lokið athuguninni, svo einingin skilar einfaldri auðkenningarvillu.

Villan lítur þá út eins og skilríkjavandamál í hverri skrá sem biðlarinn sér. Það er gildran: biðlarinn greinir frá því sem PAM sagði honum, og PAM greinir aðeins frá því að staflan hafi sagt nei. Að keyra hjálparforritið í hönd sem root sannar ekkert heldur, því það æfir forréttindaleið sem þjónustan notar aldrei. Lestu unitið sem systemd hlað inn í raun og veru, lestu síðan kerfisskrána fyrir tilraunina sem það gerði. Þessar tvær sýnir aðskilja sandkassavandamál frá rangt-lykilorðsvandamáli.

Lestu unitið áður en þú lest lykilorðaskrána

Pakkað unit getur borið drop-in sem þú skrifaðir ekki, og raunverulega stillingin er sameinuð útkoman. Prentaðu unitið eins og systemd sér það, ásamt sandkassastillingunum sem ákveða hvort hjálparforritið geti hækkað sig. Einungis lestrar skoðun nægir á þessu stigi.

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

Fyrsta skipunin sýnir hvaðan unitið og drop-in þess koma, sem skiptir máli því yfirskrif sem bætt var við fyrir mánuðum lifir lengur en minnið um hvers vegna hún er til. Sú seinni prentar sandkassagildin sem næstu tveir hlutar byggja á.

Berðu það sem þú sér saman við vinnandi hýsil af sömu dreifingu og útgáfu. Munur í User, CapabilityBoundingSet eða NoNewPrivileges er áþreifanleg vísbending; munur í prósaathugasemdum er það ekki. Skrifaðu gildin niður áður en þú breytir einhverju, því síðari samanburður við hreyfanlegt mark sannar ekkert. Ef þjónustan keyrir sem óforréttindaaðgangur með tómt bounding-mengi hefur hjálparforritið nánast ekkert að vinna með.

Skilríkjaumbreyting, skráaaðgangur og stefna eru þrjú mörk

Byrjaðu á því sem gerist í exec. setuid-tvíundarskrá eða skrá sem ber skráargetu veldur skilríkjaumbreytingu, svo auðkennið sem verður til er ekki framhald kallsins. Bounding-mengið takmarkar hvað slík skrá má öðlast, og NoNewPrivileges lokar algjörlega fyrir öflun setuid, setgid og skráargetu. Eitthvert þessara þriggja getur stöðvað hjálparforritið á meðan hver önnur þjónustuvirkni helst ósnortin.

Næst skaltu aðskilja breiða geðþóttaframhjáhald frá þröngum lestraraðgangi. CAP_DAC_OVERRIDE sleppir geðþóttaprófunum nánast hvar sem er, á meðan CAP_DAC_READ_SEARCH nær yfir lestur og möppugöngu með eigin viðbótarvöld. Þetta eru mismunandi verkfæri með mismunandi áhrifageisla, og hvorugt er stafsetning á láta PAM lesa shadow-skrána.

Að lokum skaltu spyrja hvort skilyrðisstefnan leyfi aðgerðina yfirhöfuð. Linux-geta hnekkir ekki SELinux, og að hafa eina sannar ekkert um type enforcement-reglu. Meðhöndlaðu skráaraðgangsneitun og getuneitun sem ólíkar sannanir, því þær nefna ólíkar lagfæringar og oft ólíka eigendur. Lestu hvert svið færslunnar frekar en eitt orðið denied. Hvaða keyrsluskrá framkvæmdi aðgerðina, í hvaða léni hún hljóp, hvers konar mark hún snerti, hvaða flokkur hlutar átti hlut að máli og hvaða leyfi stefnan neitaði — hvert þeirra þrengir svarið á sinn hátt.

Dragðu neitunina út úr endurskoðunarskránni

Á framfylgjandi hýsli er endurskoðunarslóðin eini staðurinn sem skráir neitun. Spurðu eftir nýlegum atburðum og lestu þá gagnvart tímaritmerki misheppnaðrar innskráningar, ekki gagnvart tímanum sem þú byrjaðir rannsóknina.

ausearch -m AVC,USER_AVC -ts recent

Tóm útkoma er ekki sönnun sakleysis. Hún þýðir annaðhvort að endurskoðun safnar ekki, eða að glugginn þinn missti tilraunina, og útiloka verður báða möguleika áður en þú útilokar stefnuna.

Leiðbeiningar Red Hat um úrræði SELinux setja merkja- og stillingarprófanir á undan myndun allow-reglna, sem er líka rétta röðin fyrir þetta vandamál. Rangt merkt hjálpartvíund og skarð í stefnu skila svipuðum neitunum en þurfa mismunandi lagfæringar. Að búa til allow-reglu fyrir merkingarvillu felur gallann og lætur næstu pakkauppfærslu koma honum aftur inn. Staðfestu merkið á uppsettu hjálparforritinu áður en þú skrifar einhverja stefnu.

Sannaðu breytinguna með einni samþykktri og einni hafnaðri innskráningu

Breyttu aðeins mörkunum sem þú sýndir fram á, prófaðu síðan báðar útkomur. Reikningur sem á að auðkenna verður að takast, og reikningur með rangt lykilorð verður að mistakast enn. Breyting sem lætur hverja tilraun takast hefur fjarlægt auðkenningu í stað þess að lagfæra hana.

Gerðu raunverulega tengitilraun og lestu dagbókina strax á eftir. Línan sem sannar lagfæringuna er pam_unix(openvpn:auth)-færslan fyrir þá tilraun: hún ætti að segja auðkenning tókst, og engin AVC-færsla má bera sömu sekúndu.

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

Vinnandi göng þurfa líka endurtengingu, því sandkassabreytingar brjóta seinni tenginguna oftar en þá fyrri. Athugaðu stofnaða sokkinn eftir endurtenginguna og staðfestu að sama unitið þjóni honum enn.