PAM-aŭtentigo funkcias mane sed malsukcesas kiel OpenVPN-servo

Aŭtentigo per PAM povas sukcesi kiam vi rulas la klienton mane kaj malsukcesi kun AUTH_FAILED tuj kiam systemd lanĉas la saman profilon. La pasvorto ne ŝanĝiĝas inter tiuj ruladoj; tio, kio ŝanĝiĝas, estas la aro de limigoj ĉirkaŭ la procezo, kiu demandas PAM. PAM respondas per helpilo, kies kapablo ŝanĝi siajn proprajn akreditaĵojn estas ĝuste tio, kion fortikigita unuo forigas. Trovu tiun helpilon kaj la limon, kiun ĝi bezonas, antaŭ ol tuŝi kapablan liston.

unix_chkpwd estas la binara dosiero, kiu respondas la PAM-demandon

Kun loka pasvorta aŭtentigo, pam_unix malofte legas la haket-dosieron mem. Ĝi plenumas unix_chkpwd, kiun distribuaĵoj instalas kiel setuid root aŭ setgid shadow, por ke unu pasvorto povu esti kontrolita nome de procezo, kiu nenion havas por fari kun legado de /etc/shadow. Forigu la kapablon akiri tiun identecon kaj la helpilo ne povas fini la kontrolon, do la modulo redonas simplan aŭtentigan malsukceson.

La malsukceso tiam aspektas kiel akreditaĵa problemo en ĉiu registro, kiun la kliento povas vidi. Tio estas la kaptilo: la kliento raportas tion, kion PAM diris al ĝi, kaj PAM raportas nur, ke la stako diris ne. Ruli la helpilon mane kiel root ankaŭ pruvas nenion, ĉar ĝi ekzercas privilegian vojon, kiun la servo neniam uzas. Legu la unuon, kiun systemd efektive ŝargis, poste la sistemregistron por la provo, kiun ĝi faris. Tiuj du vidpunktoj apartigas sabloŝkatolan problemon de malĝusta-pasvorta problemo.

Legu la unuon antaŭ ol legi la pasvortan registron

Pakita unuo povas porti drop-in, kiun vi ne skribis, kaj la efika agordo estas la kunfandita rezulto. Presu la unuon tiel, kiel systemd vidas ĝin, kune kun la sabloŝkatolaj agordoj, kiuj decidas ĉu la helpilo povas sin levi. Nurlega inspektado sufiĉas en ĉi tiu stadio.

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

La unua komando montras, de kie venas la unuo kaj ĝiaj drop-in, kio gravas ĉar anstataŭigo aldonita antaŭ monatoj vivas pli longe ol la memoro pri kial ĝi ekzistas. La dua presas la sabloŝkatolajn valorojn, de kiuj dependas la du sekvaj sekcioj.

Komparu tion, kion vi vidas, kun funkcianta gastiganto de la sama distribuaĵo kaj versio. Diferenco en User, CapabilityBoundingSet aŭ NoNewPrivileges estas konkreta spuro; diferenco en prozaj komentoj ne estas. Skribu la valorojn antaŭ ol ŝanĝi ion, ĉar posta komparo kun moviĝanta celo pruvas nenion. Se la servo rulas kiel neprivilegia konto kun malplena bounding-aro, la helpilo preskaŭ nenion havas por labori.

Akreditaĵa transformo, dosieraliro kaj politiko estas tri limoj

Komencu per tio, kio okazas dum exec. setuid-binara dosiero aŭ dosiero portanta dosierkapablojn kaŭzas akreditaĵan transformon, do la rezulta identeco ne estas daŭrigo de la alvokanto. La bounding-aro limigas tion, kion tia dosiero rajtas akiri, kaj NoNewPrivileges tute blokas akiron de setuid, setgid kaj dosierkapabloj. Iu ajn el tiuj tri povas haltigi la helpilon, dum ĉiu alia serva funkcio restas sendifekta.

Poste apartigu larĝan diskretan ĉirkaŭiron de mallarĝa lega aliro. CAP_DAC_OVERRIDE preterpasas diskretajn kontrolojn preskaŭ ĉie, dum CAP_DAC_READ_SEARCH kovras legadon kaj dosierujan trairadon kun propraj pliaj povoj. Ili estas malsamaj iloj kun malsamaj efikradiusoj, kaj nek unu estas literumo de lasu PAM legi la shadow-dosieron.

Fine demandu, ĉu la deviga politiko entute permesas la agon. Linux-kapablo ne superregas SELinux, kaj posedi unu pruvas nenion pri type enforcement-regulo. Traktu dosier-aliran rifuzon kaj kapablan rifuzon kiel malsamajn pruvojn, ĉar ili nomas malsamajn riparojn kaj ofte malsamajn posedantojn. Legu ĉiun kampon de la rikordo anstataŭ la ununuran vorton denied. Kiu plenumeblo faris la agon, en kiu domajno ĝi rulis, kiun tipon de celo ĝi tuŝis, kiu klaso de objekto estis implikita kaj kiun permeson la politiko rifuzis — ĉiu mallarĝigas la respondon alimaniere.

Eltiru la rifuzon el la revizia registro

Sur plenumiga gastiganto, la revizia spuro estas la sola loko, kiu registras rifuzon. Pridemandu la lastatempajn eventojn kaj legu ilin kontraŭ la tempomarko de la malsukcesa ensaluto, ne kontraŭ la tempo, kiam vi komencis esplori.

ausearch -m AVC,USER_AVC -ts recent

Malplena rezulto ne estas pruvo de senkulpeco. Ĝi signifas aŭ ke reviziado ne kolektas, aŭ ke via fenestro maltrafis la provon, kaj ambaŭ ebloj devas esti ekskluditaj antaŭ ol vi ekskludas la politikon.

La gvidilo pri solvado de SELinux-problemoj de Red Hat metas etikedajn kaj agordajn kontrolojn antaŭ generado de permesaj reguloj, kio estas la ĝusta ordo ankaŭ por ĉi tiu problemo. Malĝuste etikedita helpila binara dosiero kaj truo en la politiko produktas similajn rifuzojn sed bezonas malsamajn riparojn. Generi permesan regulon por etikeda eraro kaŝas la difekton kaj lasas la sekvan pakaĵan ĝisdatigon reenkonduki ĝin. Konfirmu la etikedon sur la instalita helpilo antaŭ ol skribi ajnan politikon.

Pruvu la ŝanĝon per unu akceptita kaj unu rifuzita ensaluto

Ŝanĝu nur la limon, kiun vi pruvis, poste testu ambaŭ rezultojn. Konto, kiu devus aŭtentiĝi, devas sukcesi, kaj konto kun malĝusta pasvorto devas ankoraŭ malsukcesi. Ŝanĝo, kiu sukcesigas ĉiun provon, forigis aŭtentigon anstataŭ ripari ĝin.

Faru realan konektprovan kaj legu la ĵurnalon tuj poste. La linio, kiu pruvas la riparon, estas la pam_unix(openvpn:auth)-rikordo por tiu provo: ĝi devus diri sukcesa aŭtentigo, kaj neniu AVC-rikordo rajtas porti la saman sekundon.

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

Funkcianta tunelo ankaŭ bezonas rekonekton, ĉar sabloŝkatolaj ŝanĝoj rompas la duan konekton pli ofte ol la unuan. Kontrolu la establitan ingon post la rekonekto kaj konfirmu, ke la sama unuo ankoraŭ servas ĝin.