PAM autentifikasiyası əl ilə işləyir, lakin OpenVPN xidməti kimi uğursuz olur

PAM vasitəsilə autentifikasiya müştərini əl ilə işlətdikdə uğurlu ola bilər, systemd eyni profili başladanda isə AUTH_FAILED ilə uğursuz olur. Parol bu işə salmalar arasında dəyişmir; dəyişən şey PAM-a sual verən prosesin ətrafındakı məhdudiyyətlər toplusudur. PAM öz etimadnamələrini dəyişmək qabiliyyəti olan köməkçi proqram vasitəsilə cavab verir və məhz bu qabiliyyəti sərtləşdirilmiş unit aradan qaldırır. Həmin köməkçini və onun ehtiyac duyduğu sərhədi imkanlar siyahısına toxunmazdan əvvəl tapın.

unix_chkpwd PAM sualına cavab verən binar fayldır

Yerli parol autentifikasiyası ilə pam_unix nadir hallarda hash faylını özü oxuyur. O, unix_chkpwd proqramını icra edir; distributivlər onu setuid root və ya setgid shadow kimi quraşdırır ki, /etc/shadow oxumaqla heç bir işi olmayan proses adından bir parolu yoxlamaq mümkün olsun. Bu kimliyi qazanmaq qabiliyyətini götürün və köməkçi yoxlamanı tamamlaya bilməyəcək, buna görə modul adi autentifikasiya uğursuzluğu qaytarır.

Sonra uğursuzluq müştərinin görə bildiyi hər jurnalda etimadnamə problemi kimi görünür. Tələ budur: müştəri PAM-ın ona dediyini bildirir, PAM isə yalnız yığının “yox” dediyini bildirir. Köməkçini root kimi əl ilə işlətmək də heç nəyi sübut etmir, çünki bu, xidmətin heç vaxt istifadə etmədiyi imtiyaz yolunu sınaqdan keçirir. systemd-nin həqiqətən yüklədiyi unit-i oxuyun, sonra etdiyi cəhd üçün sistem jurnalını oxuyun. Bu iki baxış sandbox problemini yanlış parol probleminə qarşı ayırır.

Parol jurnalını oxumazdan əvvəl unit-i oxuyun

Paketlənmiş unit sizin yazmadığınız drop-in daşıya bilər və effektiv konfiqurasiya birləşdirilmiş nəticədir. Unit-i systemd-nin gördüyü kimi çap edin, köməkçinin özünü yüksəldə bilib-bilmədiyini müəyyən edən sandbox parametrləri ilə birlikdə. Bu mərhələdə yalnız oxuma yoxlaması kifayətdir.

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

Birinci əmr unit-in və onun drop-in-lərinin haradan gəldiyini göstərir; bu vacibdir, çünki aylar əvvəl əlavə edilmiş ləğvetmə nə üçün mövcud olduğunun yaddaşından uzun yaşayır. İkinci əmr növbəti iki bölmənin asılı olduğu sandbox dəyərlərini çap edir.

Gördüklərinizi eyni distributiv və versiyanın işlək hostu ilə müqayisə edin. User, CapabilityBoundingSet və ya NoNewPrivileges fərqi konkret ipucudur; nəsr şərhindəki fərq deyil. Nəyisə dəyişməzdən əvvəl dəyərləri yazın, çünki hərəkət edən hədəflə sonrakı müqayisə heç nəyi sübut etmir. Xidmət boş bounding dəsti olan imtiyazsız hesabla işləyirsə, köməkçinin işləyəcək demək olar ki, heç nəsi yoxdur.

Etimadnamə çevrilməsi, fayl girişi və siyasət üç sərhəddir

exec zamanı baş verənlərdən başlayın. setuid binar və ya fayl imkanları daşıyan fayl etimadnamə çevrilməsinə səbəb olur, ona görə yaranan kimlik çağıranın davamı deyil. Bounding dəsti belə binarın nə qazana biləcəyini məhdudlaşdırır və NoNewPrivileges setuid, setgid və fayl imkanı qazanmalarını tamamilə bloklayır. Bu üçündən hər hansı biri köməkçini dayandıra bilər, halbuki digər bütün xidmət funksiyaları toxunulmaz qalır.

Sonra geniş diskresion yan keçməni dar oxu girişindən ayırın. CAP_DAC_OVERRIDE demək olar ki, hər yerdə diskresion yoxlamaları atlayır, CAP_DAC_READ_SEARCH isə oxuma və kataloq keçidini öz əlavə səlahiyyətləri ilə əhatə edir. Onlar fərqli təsir radiusları olan fərqli alətlərdir və heç biri “PAM shadow faylını oxusun” ifadəsinin yazılışı deyil.

Nəhayət, məcburi siyasətin hərəkətə ümumiyyətlə icazə verib-vermədiyini soruşun. Linux imkanı SELinux-u ləğv etmir və birini saxlamaq type enforcement qaydası haqqında heç nə sübut etmir. Fayl girişinin rədd edilməsini və imkan rəddini fərqli sübut kimi qəbul edin, çünki onlar fərqli düzəlişlər və çox vaxt fərqli sahiblər adlandırır. Qeydin hər sahəsini oxuyun, tək “denied” sözünü deyil. Hansı icra edilə bilən fayl hərəkəti etdi, hansı domendə işlədi, hansı tipli hədəfə toxundu, hansı obyekt sinfi iştirak edirdi və siyasət hansı icazəni rədd etdi — hər biri cavabı fərqli şəkildə daraldır.

Rəddi audit jurnalından çıxarın

İcraedici hostda audit izi rəddi qeyd edən yeganə yerdir. Son hadisələri sorğulayın və onları uğursuz girişin vaxt damğasına görə oxuyun, araşdırmaya başladığınız vaxta görə deyil.

ausearch -m AVC,USER_AVC -ts recent

Boş nəticə günahsızlığın sübutu deyil. Bu ya auditin toplamadığını, ya da pəncərənizin cəhdi buraxdığını bildirir və siyasəti istisna etməzdən əvvəl hər iki ehtimal istisna edilməlidir.

Red Hat-ın SELinux problemlərinin aradan qaldırılması təlimatı etiket və konfiqurasiya yoxlamalarını icazə qaydalarının yaradılmasından əvvəl qoyur, bu da bu problem üçün düzgün ardıcıllıqdır. Səhv etiketlənmiş köməkçi binar və siyasət boşluğu oxşar rədd yaradır, lakin fərqli təmirlər tələb edir. Etiketləmə səhvi üçün icazə qaydası yaratmaq qüsuru gizlədir və növbəti paket yeniləməsinin onu yenidən gətirməsinə imkan verir. Hər hansı siyasət yazmadan əvvəl quraşdırılmış köməkçidəki etiketi təsdiqləyin.

Dəyişikliyi bir qəbul edilmiş və bir rədd edilmiş girişlə sübut edin

Yalnız nümayiş etdirdiyiniz sərhədi dəyişin, sonra hər iki nəticəni sınayın. Autentifikasiya etməli olan hesab uğurlu olmalıdır, yanlış parolu olan hesab isə hələ də uğursuz olmalıdır. Hər cəhdi uğurlu edən dəyişiklik autentifikasiyanı təmir etmək əvəzinə aradan qaldırmışdır.

Real bağlantı cəhdi edin və dərhal sonra jurnalı oxuyun. Düzəlişi sübut edən sətir həmin cəhd üçün pam_unix(openvpn:auth) girişidir: autentifikasiya uğuru oxunmalı və heç bir AVC qeydi eyni saniyəni daşımamalıdır.

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

İşlək tunel yenidən qoşulma da tələb edir, çünki sandbox dəyişiklikləri ikinci bağlantını birincidən daha tez-tez pozur. Yenidən qoşulmadan sonra qurulmuş soketi yoxlayın və eyni unit-in hələ də ona xidmət etdiyini təsdiqləyin.