PAM autentifikācija darbojas manuāli, bet neizdodas kā OpenVPN pakalpojums

Autentifikācija ar PAM var izdoties, kad klientu palaižat manuāli, un neizdoties ar AUTH_FAILED, tiklīdz systemd palaiž to pašu profilu. Parole starp šīm palaišanām nemainās; mainās ierobežojumu kopa ap procesu, kas PAM uzdod jautājumu. PAM atbild caur palīgprogrammu, kuras spēja mainīt savus akreditācijas datus ir tieši tas, ko noņem nostiprināta unit. Atrodiet šo palīgprogrammu un tai nepieciešamo robežu, pirms aiztiecat iespēju sarakstu.

unix_chkpwd ir binārā datne, kas atbild uz PAM jautājumu

Ar lokālu paroles autentifikāciju pam_unix reti lasa pašu hash datni. Tas izpilda unix_chkpwd, ko distribūcijas instalē kā setuid root vai setgid shadow, lai vienu paroli varētu pārbaudīt tāda procesa vārdā, kuram nav nekāda darīšana ar /etc/shadow lasīšanu. Noņemiet spēju iegūt šo identitāti, un palīgprogramma nevarēs pabeigt pārbaudi, tāpēc modulis atgriež vienkāršu autentifikācijas kļūdu.

Tad kļūda izskatās kā akreditācijas datu problēma katrā žurnālā, ko klients redz. Tas ir slazds: klients ziņo, ko PAM tam teica, un PAM ziņo tikai to, ka steks teica nē. Palīgprogrammas palaišana manuāli kā root arī neko nepierāda, jo tā izmēģina privilēģiju ceļu, ko pakalpojums nekad neizmanto. Izlasiet unit, ko systemd faktiski ielādēja, pēc tam sistēmas žurnālu par veikto mēģinājumu. Šie divi skati atdala smilškastes problēmu no nepareizas paroles problēmas.

Izlasiet unit, pirms lasāt paroles žurnālu

Iepakotā unit var saturēt drop-in, ko neesat rakstījis, un faktiskā konfigurācija ir apvienotais rezultāts. Izdrukājiet unit tā, kā to redz systemd, kopā ar smilškastes iestatījumiem, kas nosaka, vai palīgprogramma var sevi paaugstināt. Šajā posmā pietiek ar tikai lasīšanas pārbaudi.

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

Pirmā komanda parāda, no kurienes nāk unit un tā drop-in, kas ir svarīgi, jo pirms mēnešiem pievienots pārraksts dzīvo ilgāk nekā atmiņa par to, kāpēc tas pastāv. Otrā izdrukā smilškastes vērtības, no kurām atkarīgas nākamās divas sadaļas.

Salīdziniet redzēto ar strādājošu tās pašas distribūcijas un versijas resursdatoru. Atšķirība User, CapabilityBoundingSet vai NoNewPrivileges ir konkrēta norāde; atšķirība prozas komentāros nav. Pierakstiet vērtības pirms kaut kā mainīšanas, jo vēlāks salīdzinājums ar kustīgu mērķi neko nepierāda. Ja pakalpojums darbojas ar neprivileģētu kontu un tukšu bounding kopu, palīgprogrammai gandrīz nav ar ko strādāt.

Akreditācijas datu transformācija, failu piekļuve un politika ir trīs robežas

Sāciet ar to, kas notiek exec laikā. setuid binārā datne vai datne ar failu iespējām izraisa akreditācijas datu transformāciju, tāpēc iegūtā identitāte nav izsaucēja turpinājums. Bounding kopa ierobežo, ko šāda datne drīkst iegūt, un NoNewPrivileges pilnībā bloķē setuid, setgid un failu iespēju iegūšanu. Jebkura no šīm trim var apturēt palīgprogrammu, kamēr visas pārējās pakalpojuma funkcijas paliek neskartas.

Pēc tam atdaliet plašu diskrecionāru apiešanu no šauras lasīšanas piekļuves. CAP_DAC_OVERRIDE izlaiž diskrecionārās pārbaudes gandrīz visur, bet CAP_DAC_READ_SEARCH aptver lasīšanu un katalogu šķērsošanu ar savām papildu pilnvarām. Tie ir dažādi rīki ar atšķirīgu ietekmes rādiusu, un neviens nav frāzes ļauj PAM lasīt shadow datni rakstība.

Visbeidzot, jautājiet, vai obligātā politika vispār pieļauj šo darbību. Linux iespēja neatceļ SELinux, un tās turēšana neko nepierāda par type enforcement noteikumu. Failu piekļuves atteikumu un iespējas atteikumu uztveriet kā atšķirīgus pierādījumus, jo tie nosauc atšķirīgus labojumus un bieži atšķirīgus īpašniekus. Lasiet katru ieraksta lauku, nevis vienu vārdu denied. Kurš izpildāmais fails veica darbību, kurā domēnā tas darbojās, kāda tipa mērķi tas aizskāra, kura objekta klase bija iesaistīta un kuru atļauju politika noraidīja — katrs savā ziņā sašaurina atbildi.

Izvelciet atteikumu no audita žurnāla

Uz izpildošā resursdatora audita pēdas ir vienīgā vieta, kas reģistrē atteikumu. Vaicājiet jaunākos notikumus un lasiet tos pret neizdevušās pieteikšanās laika zīmogu, nevis pret laiku, kad sākāt izmeklēšanu.

ausearch -m AVC,USER_AVC -ts recent

Tukšs rezultāts nav nevainības pierādījums. Tas nozīmē, ka audita sistēma neievāc datus vai ka jūsu logs palaida garām mēģinājumu, un abas iespējas ir jāizslēdz, pirms izslēdzat politiku.

Red Hat SELinux problēmu novēršanas norādes liek etiķešu un konfigurācijas pārbaudes pirms allow noteikumu ģenerēšanas, un tā ir pareizā secība arī šai problēmai. Nepareizi marķēta palīgprogrammas binārā datne un politikas plaisa rada līdzīgus atteikumus, bet prasa atšķirīgus labojumus. Allow noteikuma ģenerēšana marķējuma kļūdai paslēpj defektu un ļauj nākamajam pakotnes atjauninājumam to atkal ieviest. Apstipriniet instalētās palīgprogrammas etiķeti pirms jebkādas politikas rakstīšanas.

Pierādiet izmaiņas ar vienu pieņemtu un vienu noraidītu pieteikšanos

Mainiet tikai to robežu, kuru pierādījāt, pēc tam pārbaudiet abus iznākumus. Kontam, kuram jāautentificējas, jāizdodas, un kontam ar nepareizu paroli joprojām jāneizdodas. Izmaiņas, kas liek izdoties katram mēģinājumam, ir noņēmušas autentifikāciju, nevis to salabojušas.

Veiciet reālu savienojuma mēģinājumu un tūlīt pēc tam izlasiet žurnālu. Rinda, kas pierāda labojumu, ir šī mēģinājuma pam_unix(openvpn:auth) ieraksts: tajā jābūt norādei par veiksmīgu autentifikāciju, un nevienam AVC ierakstam nedrīkst būt tā pati sekunde.

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

Strādājošam tunelim nepieciešama arī atkārtota savienošanās, jo smilškastes izmaiņas biežāk pārtrauc otro savienojumu nekā pirmo. Pārbaudiet izveidoto ligzdu pēc atkārtotās savienošanās un apstipriniet, ka tā pati unit to joprojām apkalpo.