Vërtetimi me PAM funksionon me dorë, por dështon si shërbim OpenVPN

Vërtetimi përmes PAM mund të ketë sukses kur e nis klientin me dorë dhe mund të dështojë me AUTH_FAILED sapo systemd nis të njëjtin profil. Fjalëkalimi nuk ndryshon midis atyre nisjeve; ajo që ndryshon është grupi i kufizimeve rreth procesit që i bën PAM pyetjen. PAM përgjigjet përmes një ndihmësi, aftësia e të cilit për të ndryshuar kredencialet e veta është pikërisht ajo që heq një unit i fortifikuar. Gjeje atë ndihmës dhe kufirin që i duhet para se të prekësh një listë aftësish.

unix_chkpwd është binari që i përgjigjet pyetjes së PAM

Me vërtetim lokal me fjalëkalim, pam_unix rrallë e lexon vetë skedarin hash. Ekzekuton unix_chkpwd, të cilin shpërndarjet e instalojnë si setuid root ose setgid shadow, që një fjalëkalim të mund të kontrollohet në emër të një procesi që nuk duhet të lexojë /etc/shadow. Hiqe aftësinë për të fituar atë identitet dhe ndihmësi nuk mund ta përfundojë kontrollin, prandaj moduli kthen një dështim të thjeshtë vërtetimi.

Dështimi atëherë duket si problem kredencialesh në çdo regjistër që klienti mund të shohë. Ky është kurthi: klienti raporton atë që i tha PAM, dhe PAM raporton vetëm se stiva tha jo. Ekzekutimi i ndihmësit me dorë si root gjithashtu nuk provon asgjë, sepse ushtron një rrugë privilegjesh që shërbimi nuk e përdor kurrë. Lexo unitin që systemd ngarkoi në të vërtetë, pastaj lexo regjistrin e sistemit për përpjekjen që bëri. Këto dy pamje ndajnë një problem sandbox nga një problem fjalëkalimi të gabuar.

Lexo unitin para se të lexosh regjistrin e fjalëkalimeve

Një unit i paketuar mund të mbajë një drop-in që nuk e ke shkruar, dhe konfigurimi efektiv është rezultati i bashkuar. Printo unitin ashtu siç e sheh systemd, bashkë me cilësimet e sandbox që vendosin nëse ndihmësi mund të ngrihet vetë. Inspektimi vetëm-lexim mjafton në këtë fazë.

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

Komanda e parë tregon nga vijnë uniti dhe drop-in-et e tij, gjë që ka rëndësi sepse një anulim i shtuar muaj më parë jeton më gjatë se kujtesa për arsyen pse ekziston. E dyta printon vlerat e sandbox nga të cilat varen dy seksionet e radhës.

Krahaso atë që sheh me një host funksional të të njëjtit distribucion dhe version. Një ndryshim në User, CapabilityBoundingSet ose NoNewPrivileges është një gjurmë konkrete; një ndryshim në komentet e prozës nuk është. Shkruaji vlerat para se të ndryshosh çdo gjë, sepse një krahasim i mëvonshëm me një objektiv në lëvizje nuk provon asgjë. Nëse shërbimi ekzekutohet si një llogari pa privilegje me një grup kufizues bosh, ndihmësi pothuajse nuk ka me çfarë të punojë.

Transformimi i kredencialeve, aksesi te skedarët dhe politika janë tre kufij

Fillo me atë që ndodh gjatë exec. Një binar setuid ose një skedar që mban file capabilities shkakton një transformim kredencialesh, kështu që identiteti që rezulton nuk është vazhdim i thirrësit. Grupi kufizues kufizon atë që një binar i tillë mund të fitojë, dhe NoNewPrivileges bllokon plotësisht fitimin e setuid, setgid dhe file capabilities. Secili prej këtyre të treve mund ta ndalojë ndihmësin duke i lënë të paprekura të gjitha funksionet e tjera të shërbimit.

Më pas, ndaj anashkalimin e gjerë diskrecional nga aksesi i ngushtë i leximit. CAP_DAC_OVERRIDE kalon kontrollet diskrecionale pothuajse kudo, ndërsa CAP_DAC_READ_SEARCH mbulon leximin dhe kalimin nëpër drejtori me fuqitë e veta shtesë. Janë mjete të ndryshme me rreze të ndryshme veprimi, dhe asnjëri nuk është një mënyrë për të shkruar lëri PAM të lexojë skedarin shadow.

Së fundi, pyet nëse politika e detyrueshme e lejon fare veprimin. Një aftësi Linux nuk e anulon SELinux, dhe ta kesh atë nuk provon asgjë për një rregull të zbatimit të tipit. Trajto një refuzim të aksesit te skedari dhe një refuzim të aftësisë si dëshmi të ndryshme, sepse emërtojnë rregullime të ndryshme dhe shpesh pronarë të ndryshëm. Lexo çdo fushë të regjistrit në vend të fjalës së vetme denied. Cili ekzekutues e kreu veprimin, në cilin domen punonte, çfarë lloj objektivi preku, cila klasë objekti ishte e përfshirë dhe cilën leje refuzoi politika - secila prej këtyre e ngushton përgjigjen në një mënyrë tjetër.

Nxirre refuzimin nga regjistri i auditimit

Në një host në modalitetin enforcing, gjurmët e auditimit janë i vetmi vend që regjistron një refuzim. Pyet për ngjarjet e fundit dhe lexoji ato në lidhje me vulën kohore të hyrjes së dështuar, jo në lidhje me kohën kur fillove hetimin.

ausearch -m AVC,USER_AVC -ts recent

Një rezultat bosh nuk është provë pafajësie. Do të thotë ose që auditimi nuk po mbledh, ose që dritarja jote e humbi përpjekjen, dhe të dyja mundësitë duhet të përjashtohen para se të përjashtosh politikën.

Udhëzuesi i Red Hat për zgjidhjen e problemeve të SELinux i vendos kontrollet e etiketës dhe të konfigurimit përpara gjenerimit të rregullave lejuese, që është edhe rendi i duhur për këtë problem. Një binar ndihmës i etiketuar gabim dhe një boshllëk në politikë prodhojnë refuzime të ngjashme, por kërkojnë rregullime të ndryshme. Gjenerimi i një rregulli lejues për një gabim etikete fsheh defektin dhe e lë përditësimin tjetër të paketës ta rikthejë atë. Konfirmo etiketën në ndihmësin e instaluar para se të shkruash çdo politikë.

Vërteto ndryshimin me një hyrje të pranuar dhe një të refuzuar

Ndrysho vetëm kufirin që demonstruat, pastaj provo të dyja rezultatet. Një llogari që duhet të vërtetohet duhet të ketë sukses, dhe një llogari me fjalëkalim të gabuar duhet të vazhdojë të dështojë. Një ndryshim që bën çdo përpjekje të ketë sukses e ka hequr vërtetimin në vend që ta rregullojë.

Kryej një përpjekje reale lidhjeje dhe lexo regjistrin menjëherë pas saj. Rreshti që provon rregullimin është zëri pam_unix(openvpn:auth) për atë përpjekje: duhet të thotë sukses vërtetimi, dhe asnjë regjistër AVC nuk duhet të mbajë të njëjtën sekondë.

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

Një tunel funksional ka nevojë edhe për një rilidhje, sepse ndryshimet e sandbox e prishin lidhjen e dytë më shpesh sesa të parën. Kontrollo socket-in e vendosur pas rilidhjes dhe konfirmo se i njëjti unit vazhdon ta shërbejë atë.