PAM kimlik doğrulaması elle çalışıyor ama OpenVPN servisi olarak başarısız oluyor

PAM üzerinden kimlik doğrulama, istemciyi elle çalıştırdığınızda başarılı olabilir ve systemd aynı profili başlattığında AUTH_FAILED ile başarısız olabilir. Parola bu çalıştırmalar arasında değişmez; değişen şey, PAM'e soruyu soran süreç etrafındaki kısıtlar kümesidir. PAM, kendi kimlik bilgilerini değiştirme yeteneği tam olarak sağlamlaştırılmış bir unitin kaldırdığı şey olan bir yardımcı aracılığıyla yanıt verir. Bir yetenek listesine dokunmadan önce o yardımcıyı ve ihtiyaç duyduğu sınırı bulun.

unix_chkpwd, PAM sorusunu yanıtlayan ikili dosyadır

Yerel parola kimlik doğrulamasında pam_unix hash dosyasını nadiren kendisi okur. Dağıtımların setuid root veya setgid shadow olarak kurduğu unix_chkpwd dosyasını çalıştırır; böylece bir parola, /etc/shadow dosyasını okumaması gereken bir süreç adına denetlenebilir. Bu kimliği kazanma yeteneğini kaldırın, yardımcı denetimi tamamlayamaz ve modül sıradan bir kimlik doğrulama hatası döndürür.

Ardından hata, istemcinin görebildiği her günlükte bir kimlik bilgisi sorunu gibi görünür. Tuzak budur: istemci PAM'in ona söylediğini bildirir, PAM ise yalnızca yığının hayır dediğini bildirir. Yardımcıyı root olarak elle çalıştırmak da hiçbir şeyi kanıtlamaz, çünkü servisin hiç kullanmadığı bir ayrıcalık yolunu işletir. systemd'nin gerçekten yüklediği uniti okuyun, sonra yapılan deneme için sistem günlüğünü okuyun. Bu iki görünüm, bir sandbox sorununu yanlış parola sorunundan ayırır.

Parola günlüğünü okumadan önce uniti okuyun

Paketlenmiş bir unit, sizin yazmadığınız bir drop-in taşıyabilir ve etkin yapılandırma birleştirilmiş sonuçtur. Uniti systemd'nin gördüğü biçimde, yardımcının kendini yükseltip yükseltemeyeceğine karar veren sandbox ayarlarıyla birlikte yazdırın. Bu aşamada salt okunur inceleme yeterlidir.

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

İlk komut, unitin ve drop-in'lerinin nereden geldiğini gösterir; bu önemlidir çünkü aylar önce eklenmiş bir geçersiz kılma, neden var olduğu hatırasından daha uzun yaşar. İkincisi, sonraki iki bölümün dayandığı sandbox değerlerini yazdırır.

Gördüklerinizi aynı dağıtım ve sürümden çalışan bir ana makineyle karşılaştırın. User, CapabilityBoundingSet veya NoNewPrivileges içindeki bir fark somut bir ipucudur; düzyazı yorumlarındaki bir fark değildir. Hiçbir şeyi değiştirmeden önce değerleri yazın, çünkü hareketli bir hedefe karşı sonradan yapılan karşılaştırma hiçbir şeyi kanıtlamaz. Servis, boş bir sınır kümesiyle ayrıcalıksız bir hesap olarak çalışıyorsa yardımcının neredeyse hiçbir dayanağı yoktur.

Kimlik bilgisi dönüşümü, dosya erişimi ve politika üç ayrı sınırdır

exec sırasında ne olduğuyla başlayın. Bir setuid ikili dosyası veya file capabilities taşıyan bir dosya kimlik bilgisi dönüşümünü tetikler, bu yüzden ortaya çıkan kimlik çağıranın devamı değildir. Sınır kümesi böyle bir ikilinin elde edebileceğini sınırlar ve NoNewPrivileges setuid, setgid ve file capabilities kazanımlarını tamamen engeller. Bu üçünden herhangi biri, servisin diğer tüm işlevlerini bozmadan yardımcıyı durdurabilir.

Ardından geniş ihtiyari baypası dar okuma erişiminden ayırın. CAP_DAC_OVERRIDE ihtiyari denetimleri neredeyse her yerde atlar, CAP_DAC_READ_SEARCH ise okumayı ve dizin geçişini kendi ek yetkileriyle kapsar. Bunlar farklı etki alanına sahip farklı araçlardır ve hiçbiri izin ver PAM shadow dosyasını okusun yazmanın bir biçimi değildir.

Son olarak, zorunlu politikanın eyleme hiç izin verip vermediğini sorun. Bir Linux yeteneği SELinux'u geçersiz kılmaz ve ona sahip olmak bir tür zorlama kuralı hakkında hiçbir şey kanıtlamaz. Dosya erişimi reddini ve yetenek reddini farklı kanıtlar olarak ele alın, çünkü farklı onarımları ve çoğu zaman farklı sahipleri adlandırırlar. Kaydın tek bir denied sözcüğü yerine her alanını okuyun. Hangi çalıştırılabilir dosyanın eylemi yaptığı, hangi alan adında çalıştığı, ne tür bir hedefe dokunduğu, hangi nesne sınıfının söz konusu olduğu ve politikanın hangi izni reddettiği yanıtı ayrı ayrı daraltır.

Reddi denetim günlüğünden çıkarın

enforcing modundaki bir ana makinede denetim izi, bir reddi kaydeden tek yerdir. Son olayları sorgulayın ve bunları soruşturmaya başladığınız zamana göre değil, başarısız girişin zaman damgasına göre okuyun.

ausearch -m AVC,USER_AVC -ts recent

Boş bir sonuç masumiyet kanıtı değildir. Ya denetimin veri toplamadığı anlamına gelir ya da pencerenizin denemeyi kaçırdığı anlamına gelir ve politikayı devre dışı bırakmadan önce her iki olasılık da dışlanmalıdır.

Red Hat'in SELinux sorun giderme rehberi etiket ve yapılandırma denetimlerini izin kuralları üretmenin önüne koyar, bu da bu sorun için doğru sıradır. Yanlış etiketlenmiş bir yardımcı ikili dosyası ile politikadaki bir boşluk benzer retler üretir ama farklı onarımlar gerektirir. Bir etiket hatası için izin kuralı üretmek kusuru gizler ve bir sonraki paket güncellemesinin onu yeniden sokmasına yol açar. Herhangi bir politika yazmadan önce kurulu yardımcıdaki etiketi doğrulayın.

Değişikliği bir kabul edilen ve bir reddedilen girişle kanıtlayın

Yalnızca gösterdiğiniz sınırı değiştirin, sonra iki sonucu da test edin. Kimlik doğrulaması yapması gereken bir hesap başarılı olmalı, yanlış parolalı bir hesap ise hâlâ başarısız olmalıdır. Her denemeyi başarılı kılan bir değişiklik kimlik doğrulamayı onarmak yerine kaldırmıştır.

Gerçek bir bağlantı denemesi yapın ve hemen ardından günlüğü okuyun. Düzeltmeyi kanıtlayan satır, o deneme için pam_unix(openvpn:auth) girdisidir: kimlik doğrulama başarısı yazmalı ve hiçbir AVC kaydı aynı saniyeyi taşımamalıdır.

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

Çalışan bir tünel bir yeniden bağlanmaya da ihtiyaç duyar, çünkü sandbox değişiklikleri ikinci bağlantıyı ilkinden daha sık bozar. Yeniden bağlanmadan sonra kurulmuş soketi denetleyin ve aynı unitin hâlâ ona hizmet ettiğini doğrulayın.