ProtectHome'e karşı bir TOTP tohumu: VPN oturum açması neden başarısız olur

Kimlik doğrulayıcı yeni altı haneli bir kod gösterir, VPN onu reddeder ve aynı kod kendi kabuğunuzdan test ettiğinizde sorunsuz doğrulanır. Bu boşluk hikâyenin tamamıdır. Kayıt sırrını açamayan bir PAM modülü, yanlış kodla aynı görünen bir hata döndürür ve ev dizinlerini gizleyen hizmet ortamı bunun yaygın bir nedenidir. Herhangi bir izni gevşetmeden önce üç durumdan hangisinde olduğunuza karar verin.

Bu üç hatadan hangisi?

Birincisi modülün hiç okuyamadığı bir sırdır. İkincisi okuyabildiği ama güncelleyemediği bir sırdır. Üçüncüsü gerçekten yanlış olan bir koddur, genellikle saat kayması veya yeniden kullanılan bir değer yüzünden.

Bir başarısız deneme için hizmet günlüğünü ve sistem kimlik doğrulama günlüğünü okuyarak bunları ayırın, ardından eklentinin hangi PAM hizmetini yüklediğini ve o hizmetin hangi modül satırını kullandığını doğrulayın. Genel bir kimlik doğrulama hatası mesajı bunları ayırt etmez, başarılı bir elle test de etmez, çünkü kabuğunuz hizmetin ortamı değildir.

Yalnızca hizmet başarısız olduğunda birimin dosya sistemi görünümü olağan suçludur.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

Seçenek A: sırrı evden dışarı taşıyın

Hizmet /home dizinini gizlediğinde ve bu korumayı sürdürmeyi tercih ettiğinizde, sırrı onun görebileceği bir yerde saklayın. Modül bir secret= yolu ve dosya işlemlerini yapan bir user= hesabı kabul eder; bu, merkezi bir deponun birçok kimliğe hizmet etmesini sağlar.

Bu, düzenli seçenektir ve en çok özen isteyen seçenektir, çünkü paylaşılan bir depo tek bir dizini her hesabın güvenlik sınırı yapar.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Ona güvenmeden önce üç şeyi kontrol edin: hesap var, modülün çalışma süreci ona geçebiliyor ve dosyalar kısıtlayıcı modlarla ona ait. user= ile birlikte ~ veya ev değişkenli bir yol kullanmayın ve bir yolu çalıştırmak için modülün sahiplik kontrollerini kapatmayın. Parola aşamasını ve yığının geri kalanını bozulmadan koruyun.

Seçenek B: dosyayı bırakın ve bir yol açın

Sır kullanıcının ev dizininde kalmalıysa, birimin ana makinedeki her evi açığa çıkarmadan yalnızca o tek dizini içeren bir görünüme ihtiyacı vardır. Bir drop-in, sandbox'lı bir evin altına dar kapsamlı bir bağlama bağlantısı ekleyebilir.

Bu, kullanıcı başına sahipliği model olarak korur; karşılığında sandbox her değiştiğinde gözden geçirilmesi gereken bir birim değişikliği gerekir.

İki sınır kolayca gözden kaçar. Sandbox'ın gizlediği bir dizinin altına eklenen salt okunur bir yol onu açığa çıkarmaz, çünkü üst dizin orada değildir. Modül durumu güncellemek zorundaysa bağlama yazılabilir olmalıdır ve bu da sonraki seçeneği devreye sokar. Drop-in'i /usr/lib altındaki paketlenmiş birimi düzenlemek yerine ayrı bir dosya olarak yazın, böylece bir paket yükseltmesi onu sessizce geri almasın.

Seçenek C: sandbox'ı koruyun ve durum yazmalarını düzeltin

Sırrı okumak kimlik doğrulamanın yalnızca yarısıdır. Modül zaman kayması bilgisini, yeniden oynatma korumasını veya bir sayacı yeniden yazabilir ve okuma kontrolünü geçen bir dosya yazmada yine de başarısız olabilir.

Bu başarısızlık bir sonraki denemede kötü kod gibi görünür, bu denemede değil; bu yüzden saat kaymasıyla karıştırılır.

Tüm evi yazılabilir yapmak yerine ona kendi yazılabilir dizinini verin ve sırrın yolunu oraya yönlendirin. Dizinin sahibini, dosya sisteminin boş alanını ve birimin başka yerlerde yazmayı kısıtlayıp kısıtlamadığını doğrulayın. Ardından art arda iki oturum açmayı test edin, çünkü ikincisi yazma yolunu kanıtlar, ilki yalnızca okumayı.

Kendiniz olarak değil, hizmet olarak doğrulayın

Önemli olan her kontrol, birimin sandbox'ı içinde birimin kimliğiyle çalışmalıdır.

root olarak başarılı olan bir komut, dosyanın var olduğunu söyler ve başka bir şey söylemez. Gerçek hizmet üzerinden oturum açma, modülün sırrı okuyup kullanıp ihtiyaç duyduğunu geri yazıp yazamadığını söyler.

Son olarak, gereksinimi bozulmadan koruyun. Boş parola seçeneği eklemek, salt okunur hataları kabul etmek veya sandbox'ı kaldırmak, politikayı değiştirerek belirtiyi ortadan kaldırırdı. Kod sunmakla yükümlü bir kullanıcı, sır erişilemez olduğunda yine de reddedilmelidir.