OpenVPN'de chroot başarısız oluyor: AppArmor kuralı mı, yetenek mi?

Daemon chroot başarısızlığını kaydediyor ve profil zaten cömert görünüyor, bu yüzden akla yatkın düzeltme bir yol kuralını genişletip yeniden başlatmak. Bu genellikle hiçbir şeyi değiştirmez, çünkü chroot profilini hiçbir zaman devredemediği bir ayrıcalıkla kilitlenmiştir. Hangi katmana dokunacağınıza karar vermek üç kontrol gerektirir ve bunlar ucuzdur: sürecin neyi tutmasına izin verildiği, ilkenin neye izin verdiği ve başlatıcının bunlardan biri önem kazanmadan önce neyi kaldırdığı.

İki ayrı kapı ve yalnızca biri AppArmor'a ait

chroot, sürecin çalıştığı kullanıcı ad alanında CAP_SYS_CHROOT gerektirir. Bu, çağrı yollarla herhangi bir şey yapmadan önce çekirdeğin denetlediği olağan Linux ayrıcalığıdır. Bundan ayrı olarak, zorlayıcı bir AppArmor profili, süreç bu yeteneğe sahip olsa bile onu reddedebilir, çünkü zorunlu ilke kimlik bilgilerinin yerine değil, onlara ek olarak danışılır. Bu ayrım pratikte önemlidir: iki katman farklı dosyalarda yaşar ve genellikle farklı kişilerce bakımı yapılır.

Bu iki kapı aynı errno ile başarısız olur. İkisi de EPERM üretir ve ikisi de daemon günlüğünde genel bir izin şikâyeti olarak görünür, bu yüzden profil içeriği hakkında tahmin yürütmek bu kadar zaman kaybettirir. Eklemek üzere olduğunuz yol kuralı, chroot başarılı olduktan sonraki dosya erişimini denetler; işlemin baştan itibaren izinli olup olmadığıyla ilgisi yoktur.

Üçüncü bir kapı ikisinin de yukarısındadır. Hizmet yöneticisi veya bir sarmalayıcı süreci, yetenek sınır kümesinde olmadan başlattıysa hiçbir AppArmor değişikliği onu geri getiremez ve profile yetenek eklemek yalnızca çekirdeğin yerine getirmeyeceği bir niyeti belgeler.

İlkeyi düzenlemeden önce ayrıcalık durumunu okuyun

Etkin olduğunu düşündüğünüz yapılandırmadan değil, çalışan süreçten başlayın. Durum dosyası beş yetenek maskesi ve no-new-privileges bayrağını gösterir ve bunlar farklı sorulara yanıt verir:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

CapEff, çağrı için önemli olan kümedir: CapBnd içinde olup CapEff içinde olmayan bir yetenek tavan tarafından izinlidir ve o anda tutulmuyordur. CapAmb, ikili olağan setuid anlamında ayrıcalıklı olmadığında önemlidir, çünkü ortam yetenekleri bir hizmetin dosya yetenekleri olmadan exec boyunca ayrıcalığı koruma yoludur. CapInh, exec boyunca miras alınabilecek bitleri tutar, ancak yalnızca yürütülen dosyanın miras kümesi buna izin verdiğinde, dolayısıyla oradaki bir bit tek başına hiçbir şey vermez.

Ardından hangi profilin gerçekten bağlı olduğunu doğrulayın. Bir süreç beklemediğiniz bir profil adıyla kısıtlanmış olabilir, özellikle bir dağıtım kendi unit dosyasını ve profilini birlikte teslim ettiğinde, /proc/PID/attr/current dosyasını okumak bunu tek satırda çözer. Düzenlediğiniz dosyayı çekirdeğin bildirdiği profille karşılaştırmak nedeni düzeltmek ile kimsenin yüklemediği bir dosyayı düzenlemek arasındaki farktır.

Yetenek kuralını yalnızca denetim izi öyle söylüyorsa ekleyin

Çekirdek ve denetim kayıtları reddeden katmanı adlandırır. capable işlemini ve sys_chroot adını taşıyan bir ret ile onu üreten profili arayın. Böyle bir kayıt varsa süreç yeteneğe zaten sahipti ve AppArmor onu reddetti, hedeflenen değişiklik gerçek profilin içindeki bir yetenek kuralıdır:

capability sys_chroot,

Onu gerçekten bağlı olan profilde bir parça olarak tutun ve kuralı ilgisiz bir eğitimden kopyalamak yerine anahtar sözcüğü apparmor.d profil başvurusu ile karşılaştırın. Paylaşılan bir include içine koymak, o dosyayı yükleyen her kısıtlı programa bu hakkı verir ve profili complain kipine geçirmek bu sorunu çözmek yerine bir sonraki reddi gizler. Profil kuralı bir ilke reddini ortadan kaldırır; ayrıcalık üretmez, bu yüzden CAP_SYS_CHROOT hiçbir zaman etkin kümesinde olmayan bir süreç kural yerinde olsa bile başarısız olmaya devam eder.

Denetim kaydı hiçbir AppArmor reddi göstermiyorsa profili düzenlemeyi bırakın. Bir kimlik bilgisi sorunuyla karşı karşıyasınız ve kalan iş unit dosyasında ya da üst süreçte, ilke dilinde değil.

Hizmet yöneticisi kendi tavanını tutar

systemd her hizmet için bir yetenek sınır kümesi belirler ve varsayılan olarak bu küme dardır. Orada dışlanan her şey, profil ne derse desin süreç için kullanılamaz, bu yüzden sertleştirilmiş unit dosyaları daemon elle başlatıldığında çalışan bir işlemde başarısız olabilir. İlgili yönergeler unit içinde kolayca okunur ve hatayı uygulamanın kendisi bildirdiğinde kolayca gözden kaçar. Dağıtım paketinin sağladığı drop-in dosyaları, kimsenin yapılandırdığını hatırlamadığı bir tavanın olağan kaynağıdır.

Tavanı yükseltmek ve yeteneği vermek iki değişikliktir, bir değil. Sınır kümesindeki bir girdi sürecin yeteneği tutabileceğini söyler; onu etkin kümeye eklemez ve NoNewPrivs, her şey uyuşsa bile sonraki bir yükseltmenin başarılı olmasını engelleyebilir. Yalnızca işlemin ihtiyaç duyduğunu ekleyin, sertleştirmenin geri kalanını bozmayın ve tek bir çağrının geçmesi için tüm yetenekleri verme kestirmesine direnin.

Sıra burada da önemlidir. Önce unit tavanını değiştirin, CapEff'in artık o biti içerdiğini doğrulayın ve ancak ondan sonra AppArmor'un hâlâ reddedip etmediğine karar verin. İki değişikliği birden yapmak, başarısızlık sürerse sizi yeniden tahmin etmeye bırakır.

Ret ortadan kalktıktan sonra hapishanenin kendisini denetleyin

Başarılı bir chroot kökü taşır, bu yüzden daemonun sonrasında dokunduğu her yol yeni ağaç içinde çözülür. Eksik yapılandırma, bulunmayan bir aygıt düğümü veya kopyalanmamış bir sertifika dizini artık dosya hatası olarak görünür ve bu hata yetenek değil yerleşim sorunudur. Bir başka geniş izin eklemek yerine sonraki olayı okuyun. Taşıma göreli bir yolun anlamını da değiştirir, bu yüzden sertleştirme kılavuzları daemon yapılandırmasında mutlak yollar konusunda ısrar eder.

chroot'un ne yapmadığını hatırlamak da yardımcı olur. Bu bir yol sınırıdır, sandbox değil: ayrıcalığı koruyan bir süreç ondan kaçabilir, bu yüzden yetenek genellikle çağrıdan sonra bırakılır ve bu yüzden kısıtlama daemonun çevresinde kalmalıdır. AppArmor profilini, yetenek sınır kümesini ve dosya sistemi kısıtlamalarını birlikte korumak alıştırmanın amacıdır, hizmet başladıktan sonra kaldırılacak bir artık değil.

Karar kuralı kısadır. Denetim kaydı AppArmor'u adlandırıyorsa bağlı profile bir yetenek kuralı ekleyin. Etkin küme boşsa unit tavanını ve ayrıcalık düşürme sırasını düzeltin. Profil düzenlediğiniz profil değilse düzenlemeyi bırakın ve gerçeğini bulun.