Gumagana nang manu-mano ang PAM auth pero nabibigo bilang OpenVPN service

Maaaring magtagumpay ang authentication sa pamamagitan ng PAM kapag manu-manong pinatakbo mo ang client at mabigo naman sa AUTH_FAILED kapag sinimulan ng systemd ang parehong profile. Hindi nagbabago ang password sa pagitan ng mga pagtakbong iyon; ang nagbabago ay ang hanay ng mga paghihigpit sa paligid ng prosesong nagtatanong sa PAM. Sumasagot ang PAM sa pamamagitan ng helper na ang kakayahang palitan ang sariling mga kredensyal ay eksaktong inaalis ng hardened na unit. Hanapin ang helper na iyon at ang hangganang kailangan nito bago mo galawin ang isang listahan ng kakayahan.

Ang unix_chkpwd ang binary na sumasagot sa tanong ng PAM

Sa lokal na password authentication, bihirang basahin mismo ng pam_unix ang hash file. Pinapatakbo nito ang unix_chkpwd, na ini-install ng mga distribusyon bilang setuid root o setgid shadow upang masuri ang isang password sa ngalan ng prosesong walang karapatang bumasa ng /etc/shadow. Alisin ang kakayahang makuha ang identidad na iyon at hindi makukumpleto ng helper ang pagsusuri, kaya nagbabalik ang module ng ordinaryong failure sa authentication.

Ang kabiguan ay mukhang problema sa kredensyal sa bawat log na nakikita ng client. Iyon ang bitag: iniuulat ng client ang sinabi ng PAM dito, at iniuulat lamang ng PAM na sinabi ng stack na hindi. Ang manu-manong pagpapatakbo ng helper bilang root ay wala ring pinapatunayan, dahil ginagamit nito ang isang landas ng pribilehiyo na hindi kailanman ginagamit ng serbisyo. Basahin ang unit na aktwal na ikinarga ng systemd, pagkatapos basahin ang system log para sa pagtatangkang ginawa nito. Ang dalawang pananaw na iyon ay naghihiwalay ng problema sa sandbox mula sa problema sa maling password.

Basahin ang unit bago basahin ang password log

Ang packaged na unit ay maaaring may dalang drop-in na hindi mo isinulat, at ang epektibong configuration ay ang pinagsamang resulta. I-print ang unit ayon sa nakikita ng systemd, kasama ang mga setting ng sandbox na nagpapasya kung makapagpapataas ng sarili ang helper. Sapat na ang read-only na inspeksyon sa yugtong ito.

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

Ipinapakita ng unang command kung saan nagmumula ang unit at ang mga drop-in nito, na mahalaga dahil ang override na idinagdag ilang buwan na ang nakalilipas ay mas matagal pang nabubuhay kaysa sa alaala kung bakit ito umiiral. Ipinapakita ng pangalawa ang mga halaga ng sandbox na pinagtatayuan ng susunod na dalawang seksyon.

Ihambing ang nakikita mo sa isang gumaganang host na may parehong distribusyon at bersyon. Ang pagkakaiba sa User, CapabilityBoundingSet o NoNewPrivileges ay kongkretong bakas; ang pagkakaiba sa mga komentong prosa ay hindi. Isulat ang mga halaga bago magbago ng anuman, dahil ang huling paghahambing laban sa gumagalaw na target ay wala ring pinapatunayan. Kung tumatakbo ang serbisyo bilang isang account na walang pribilehiyo na may walang laman na hanay ng hangganan, halos wala nang gamit ang helper.

Ang pagbabago ng kredensyal, pag-access ng file at patakaran ay tatlong hangganan

Magsimula sa nangyayari sa panahon ng exec. Ang setuid binary o file na may file capabilities ay nagdudulot ng pagbabago ng kredensyal, kaya ang resultang identidad ay hindi karugtong ng tumatawag. Nililimitahan ng hanay ng hangganan ang maaaring makuha ng naturang binary, at ganap na hinaharangan ng NoNewPrivileges ang pagkuha ng setuid, setgid at file capabilities. Alinman sa tatlong iyon ay maaaring huminto sa helper habang nananatiling buo ang bawat iba pang tungkulin ng serbisyo.

Susunod, paghiwalayin ang malawak na diskresyunaryong paglampas mula sa makitid na pag-access sa pagbasa. Nilalampasan ng CAP_DAC_OVERRIDE ang mga diskresyunaryong pagsusuri halos saanman, samantalang sinasaklaw ng CAP_DAC_READ_SEARCH ang pagbasa at paglalakbay sa direktoryo kasama ang sarili nitong karagdagang kapangyarihan. Magkaibang kasangkapan sila na may magkaibang saklaw, at wala sa kanila ang paraan ng pagsulat na hayaang basahin ng PAM ang shadow file.

Sa huli, itanong kung pinapayagan man ng mandatoryong patakaran ang aksyon. Hindi binabalewala ng kakayahan ng Linux ang SELinux, at ang pagkakaroon nito ay wala ring pinapatunayan tungkol sa tuntunin ng pagpapatupad ng uri. Tratuhin ang pagtanggi sa pag-access ng file at ang pagtanggi sa kakayahan bilang magkaibang ebidensya, dahil magkaibang pag-aayos at kadalasan ay magkaibang may-ari ang tinutukoy nila. Basahin ang bawat field ng record sa halip na ang nag-iisang salitang denied. Aling executable ang gumawa ng aksyon, sa aling domain ito tumakbo, anong uri ng target ang nahawakan nito, anong klase ng object ang nasangkot at aling pahintulot ang tinanggihan ng patakaran - bawat isa sa mga ito ay nagpapakitid ng sagot sa ibang paraan.

Ilabas ang pagtanggi mula sa audit log

Sa isang host na nasa enforcing mode, ang audit trail ang tanging lugar na nagtatala ng pagtanggi. Tanungin ang mga kamakailang kaganapan at basahin ang mga ito laban sa timestamp ng nabigong login, hindi laban sa oras na sinimulan mo ang pagsisiyasat.

ausearch -m AVC,USER_AVC -ts recent

Ang walang laman na resulta ay hindi ebidensya ng kawalang-kasalanan. Ibig sabihin nito ay alinman sa hindi nangongolekta ang audit, o nalampasan ng iyong window ang pagtatangka, at ang dalawang posibilidad ay dapat ibukod bago mo ibukod ang patakaran.

Inuuna ng gabay ng Red Hat sa pag-troubleshoot ng SELinux ang mga pagsusuri sa label at configuration bago ang pagbuo ng mga tuntunin ng pagpapahintulot, na siya ring tamang pagkakasunod-sunod para sa problemang ito. Ang maling label na helper binary at ang puwang sa patakaran ay gumagawa ng magkatulad na pagtanggi ngunit nangangailangan ng magkaibang pag-aayos. Ang pagbuo ng tuntunin ng pagpapahintulot para sa pagkakamali sa label ay nagtatago ng depekto at hinahayaang maipakilala itong muli ng susunod na update ng package. Tiyakin ang label sa naka-install na helper bago sumulat ng anumang patakaran.

Patunayan ang pagbabago sa isang tinanggap at isang tinanggihang login

Baguhin lamang ang hangganang napatunayan mo, pagkatapos subukan ang parehong kinalabasan. Ang account na dapat mag-authenticate ay dapat magtagumpay, at ang account na may maling password ay dapat pa ring mabigo. Ang pagbabagong nagpapagtagumpay sa bawat pagtatangka ay nag-alis ng authentication sa halip na inayos ito.

Gumawa ng tunay na pagtatangka sa koneksyon at basahin agad ang journal pagkatapos. Ang linyang nagpapatunay ng pag-aayos ay ang entry na pam_unix(openvpn:auth) para sa pagtatangkang iyon: dapat sabihin nitong nagtagumpay ang authentication, at walang rekord na AVC ang dapat magdala ng parehong segundo.

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

Kailangan din ng gumaganang tunnel ang isang muling pagkonekta, dahil mas madalas masira ng mga pagbabago sa sandbox ang pangalawang koneksyon kaysa sa una. Suriin ang naitatag na socket pagkatapos ng muling pagkonekta at tiyaking iyon pa rin ang unit na naglilingkod dito.