systemd sağlamlaştırmasını OpenVPN'in user düşüşü üzerine yığmayın

Birbirine yapıştırılmış iki en az ayrıcalık tarifi daha katı bir dağıtım üretmez. Bir model, daemon'un ayrıcalıklarla başlayıp başlatmadan sonra ayrıcalıksız bir hesaba düşmesine izin verir; diğeri hizmet yöneticisinin onu ilk komuttan itibaren kısıtlı bir kimlik altında başlatmasını sağlar. Her biri tek başına çalışır ve birleşim çoğu zaman iki işten hiçbirini temiz yapamayan bir hizmet üretir. Geri kalanı kararı sırayla ele alır.

İki model, değişimin tek sahibi

İlk model daemona aittir. Topluluk OpenVPN sürümünün user ve group seçenekleri tünel ve anahtarlar kurulduktan sonra kimliği değiştirir, persist-key ile persist-tun ise bu kaynakları sonrasında da kullanılabilir tutar.

İkinci model hizmet yöneticisine aittir. systemd User= veya Group= ayarı sürecin hangi kimlik altında başlayacağını belirler, yetenek yönergeleri ise neleri tutabileceğini belirler. Modeller arasında seçim yapmak güvenlik sorusu olmadan önce paketleme sorusudur ve paket bakımcısı buna çoktan yanıt vermiştir. Sizin işiniz üçüncü bir seçenek icat etmek değil, o yanıtı bulmaktır.

Her ikisi de meşrudur. Hata, onları tek bir tasarımın katmanları olarak görmektir, çünkü ikinci model birincinin kimlik değişimini sürecin artık izinli olmadığı bir işleme dönüştürebilir.

Kimliğin nerede değiştiğine karar verin

Birim zaten özel bir hesap olarak başlıyorsa, daemona başka bir hesap olmasını söylemek, sağlamlaştırılmış bir hizmetin asla yapmaması gereken bir setuid geçişi ister. Hata, net bir politika iletisi yerine başlangıçta izin hatası olarak görünür. Bu, eksik bir yetenek gibi okunur, bu da insanları kimlik sorusu yerine daha geniş bir sınır kümesine iter.

Bir şeyi düzenlemeden önce kurulu paketin gerçekte ne sunduğunu okuyun, drop-in dizini de dahil. Bazı birimler yönetici zaten ilgilendiği için daemonun kendi düşüşünü bilerek atlar, bazıları ise başlatma sonrası değişim için o seçeneklere güvenir. Hangi modeli devraldığınızı bilmeden ikisinden birini kaldırmak, çalışan bir hizmetin başlamayı bırakmasının yoludur.

Seçilen modeli tek satırda yazın: yöneticiye mi yoksa daemona mı ait. Sonraki her yönerge bu cümleyle tutarlı olmalı ve karışık bir birim uzlaşma değil hata olarak görülmelidir.

Yetenekler sınırlardır, bağış değil

Bir yetenek sınır kümesi, bir sürecin en fazla neleri tutabileceğini söyler. Bu bir tavandır ve orada bir yetenek listelemek kendi başına hiçbir şey vermez, bu yüzden cömert bir sınır kümesine sahip bir birim yine de tünel oluşturamayabilir.

Bir yeteneği gerçekten bir hizmetin ortam kümesine koyan şey AmbientCapabilities= ayarıdır. systemd çalıştırma başvurusu iki yönergeyi ayrı ayrı belgeler ve bu ayrım çevrimiçi yetenek tavsiyelerinin çoğunu açıklar.

Bir yeteneği ancak başarısız işlem onu tanımladıktan sonra ekleyin. Daha geniş bir sınır kümesi gerçek nedeni gizler ve hizmeti tasarımın amaçladığından daha ayrıcalıklı bırakır. Tavan artık işi tanımlamadığı için birimin gözden geçirilmesini de zorlaştırır. Gerçek arıza giderildikten sonra fazladan yeteneği kaldırın.

Yetkiyi yaşam döngüsü boyunca haritalayın

Sürecin her aşamada ne yapması gerektiğini listeleyin: başlangıç, kararlı durum, yeniden kimlik doğrulama ve sökme. Arayüz oluşturma, rota değişiklikleri, korunan bir anahtarı okuma ve bir yardımcıyı çağırma hepsi aynı anda veya aynı gereksinimler altında gerçekleşmez. Listeyi yeteneğe göre sıralamadan önce aşamaya göre sıralayın.

Kalıcılık seçenekleri kaynakları yeniden müzakere boyunca korur ve hiç sahip olunmamış izinler vermez. Sürecin başlangıçta okuyamadığı bir anahtar sonrasında da okunamaz kalır, kalıcılık bayrakları ne derse desin. Bayraklar zaten çalışanı korur.

Paylaşılan değil, özel bir hesap kullanın. OpenVPN geliştiricileri nobody hesabını genel bir örnek olarak kullanma alışkanlığına karşı uyarır, çünkü ana makinedeki diğer hizmetler zaten o hesapla çalışıyor olabilir ve sahip olduğunuzu düşündüğünüz yalıtım orada yoktur.

Yerel yükü değiştiren özellikler, örneğin veri kanalı boşaltması veya farklı bağlanan bir derleme, hangi işlemlerin gerektiğini kaydırabilir. Haritayı paket değiştiğinde gözden geçirin, yalnızca bir şey bozulduğunda değil.

Planı yazın ve kurtarma erişimini koruyun

Dağıtım kaydı yöneticiyi, başlangıç kimliğini, amaçlanan kararlı kimliği ve her izni onu gerektiren işlemle birlikte adlandırmalıdır. O kayıt, sonraki değişikliği deneysel değil gözden geçirilebilir kılar.

Düzenleme yaparken konsol erişimini açık tutun, çünkü başlangıçta başarısız olan bir birimi uzaktan onarmak zordur. Değişikliği tamamlandı ilan etmeden önce bir yeniden başlatma ve tam yeniden başlatma test edin. Yeniden başlatmayı atlatan bir birim, ağ ayağa kalkmadan önce yine de başarısız olabilir.

Başarı, anlaşılmış en az yetkili bir yaşam döngüsüdür; root olmayan bir ad altında tesadüfen çalışan bir süreç değildir.