PAM-ferifikaasje wurket by de hân mar mislearret as OpenVPN-tsjinst

Ferifikaasje fia PAM kin slagje as jo de klient by de hân starte, en mislearje mei AUTH_FAILED sadree’t systemd itselde profyl start. It wachtwurd feroaret net tusken dy rinnen; wat feroaret is de set beheiningen om it proses dat PAM de fraach stelt. PAM antwurdet fia in helper waans fermogen om syn eigen bewizen te feroarjen krekt is wat in hurdere unit fuorthellet. Fyn dy helper en de grins dy’t er nedich hat foardat jo in fermogenslist oanreitsje.

unix_chkpwd is it binêre bestân dat de PAM-fraach beantwurdet

Mei lokale wachtwurdferifikaasje lêst pam_unix sels komselden it hash-bestân. It fiert unix_chkpwd út, dat distribúsjes as setuid root of setgid shadow ynstallearje sadat ien wachtwurd kontrolearre wurde kin namens in proses dat neat te dwaan hat mei it lêzen fan /etc/shadow. Helje it fermogen om dy identiteit te krijen fuort en de helper kin de kontrôle net foltôgje, dus de module jout in gewoane ferifikaasjeflater werom.

De flater liket dan op in bewizensprobleem yn elk log dat de klient sjen kin. Dat is de falstrik: de klient rapportearret wat PAM him sei, en PAM rapportearret allinnich dat de stapel nee sei. It by de hân draaien fan de helper as root bewiist ek neat, want it testet in foarrjochtswei dy’t de tsjinst nea brûkt. Lês de unit dy’t systemd eins laden hat, en lês dan it systeemlog foar de poging dy’t it die. Dy twa bylden skiede in sandbox-probleem fan in ferkeard-wachtwurd-probleem.

Lês de unit foardat jo it wachtwurdlog lêze

In ferpakke unit kin in drop-in drage dy’t jo net skreaun hawwe, en de effektive konfiguraasje is it gearfoege resultaat. Printsje de unit sa’t systemd dy sjocht, tegearre mei de sandbox-ynstellingen dy’t beslute oft de helper himsels ferheffe kin. Allinnich-lêzen ynspeksje is op dit stuit genôch.

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

It earste kommando lit sjen wêr’t de unit en syn drop-ins wei komme, wat fan belang is om’t in oerskriuwing dy’t moannen lyn tafoege is langer libbet as de ûnthâlding wêrom’t er bestiet. It twadde printsjet de sandbox-wearden dêr’t de folgjende twa seksjes fan ôfhingje.

Fergelykje wat jo sjogge mei in wurkjende host fan deselde distribúsje en ferzje. In ferskil yn User, CapabilityBoundingSet of NoNewPrivileges is in konkreet oanwizing; in ferskil yn proaza-kommentaren net. Skriuw de wearden op foardat jo eat feroarje, want in lettere fergeliking mei in beweegjend doel bewiist neat. As de tsjinst as in net-privilegearre account mei in lege bounding-set draait, hat de helper hast neat om mei te wurkjen.

Bewizenstransformaasje, bestânstagon en belied binne trije grinzen

Begjin mei wat der by exec bart. In setuid-binêre of in bestân mei bestânsfermogens feroarsaket in bewizenstransformaasje, sadat de resultearjende identiteit gjin fuortsetting fan de oanropper is. De bounding-set beheint wat sa’n bestân krije mei, en NoNewPrivileges blokkearret it krijen fan setuid, setgid en bestânsfermogens folslein. Elk fan dy trije kin de helper stopje wylst elke oare tsjinstfunksje yntakt bliuwt.

Skiedje dêrnei brede diskresjonêre omgong fan smelle lêstagon. CAP_DAC_OVERRIDE slacht diskresjonêre kontrôles hast oeral oer, wylst CAP_DAC_READ_SEARCH lêzen en mapferkear dekt mei syn eigen ekstra foegen. It binne ferskillende ark mei ferskillende ynfloedsradius, en gjin fan beide is in stavering fan lit PAM it shadow-bestân lêze.

Freegje úteinlik oft it ferplichte belied de aksje oerhaad tastiet. In Linux-fermogen oerhearsket SELinux net, en ien hawwen bewiist neat oer in type enforcement-regel. Behannelje in bestânstagon-wegering en in fermogenswegering as ferskillend bewiis, want se neame ferskillende repesaasjes en faak ferskillende eigners. Lês elk fjild fan it record ynstee fan it inkelde wurd denied. Hokker útfierber bestân die de aksje, yn hokker domein rûn it, hokker type doel it oanrekke, hokker klasse objekt der by belutsen wie en hokker tastimming it belied wegere — elk ferlingt it antwurd op in oare manier.

Lûk de wegering út it auditlog

Op in hanthavende host is it auditpaad it iennichste plak dat in wegering fêstleit. Freegje de resinte barrens op en lês se tsjin it tiidstimpel fan de mislearre oanmelding, net tsjin de tiid doe’t jo it ûndersyk begûnen.

ausearch -m AVC,USER_AVC -ts recent

In leech resultaat is gjin bewiis fan ûnskuld. It betsjut of dat auditing net sammelt, of dat jo finster de poging mist hat, en beide mooglikheden moatte útsletten wurde foardat jo it belied útslute.

Red Hat syn SELinux-probleemoplossingsguidance set label- en konfiguraasjekontrôles foar it generearjen fan allow-regels, wat ek de juste oarder foar dit probleem is. In ferkeard labelle helper-binêre en in gat yn it belied jouwe ferlykbere wegeringen mar freegje ferskillende reparaasjes. It generearjen fan in allow-regel foar in labelflater ferberget de fout en lit de folgjende pakketferzje it opnij ynfiere. Befêstigje it label op de ynstallearre helper foardat jo hokker belied dan ek skriuwe.

Bewiis de feroaring mei ien akseptearre en ien wegere oanmelding

Feroarje allinnich de grins dy’t jo sjen litten hawwe, en test dan beide útkomsten. In account dat ferifiearje moat, moat slagje, en in account mei in ferkeard wachtwurd moat noch mislearje. In feroaring dy’t elke poging slagje lit, hat ferifikaasje fuorthelle ynstee fan reparearre.

Doch in echte ferbiningspoging en lês it journaal daliks dêrnei. De rigel dy’t de reparaasje bewiist is de pam_unix(openvpn:auth)-ynfier foar dy poging: der moat ferifikaasje slagge stean, en gjin AVC-record mei deselde sekonde drage.

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

In wurkjende tunnel hat ek in werferbining nedich, want sandbox-feroarings brekke de twadde ferbining fakker as de earste. Kontrolearje de fêstige socket nei de werferbining en befêstigje dat deselde unit dy noch betsjinnet.