systemd servis sıkılaştırması: yazılabilir dizini ve gerçek işlevi birlikte sınamak

Bir Linux servisinin root olmadan çalışması yararlı bir başlangıçtır; fakat dosya sistemi ve diğer kaynaklara erişiminin uygun sınırda olduğunu tek başına göstermez. systemd servis bazında çeşitli kısıtlar sunar. Bu yazı servis açılmama sorunundan farklı olarak çalışan bir hizmetin erişimini kontrollü daraltmaya odaklanır. Örnek mirror-lab.service tamamen temsili bir addır; gerçek MagicMirror cihazında bu ayarların uygulandığı veya sınandığı iddia edilmiyor.

Önce hizmetin gerçekten neye ihtiyacı olduğunu çıkarın

Çalıştırılabilir dosya, yapılandırma, kalıcı durum, geçici dosya ve günlük için ayrı yollar belirleyin. Hangi alanın yalnız okunacağı, hangisine yazılacağı belli olsun. Alt süreçler, cihaz erişimi ve süreçler arası iletişim de envantere girsin. Grafik veya ses oturumuna bağlı bir bileşeni sıradan arka plan hizmeti gibi değerlendirmeyin. Servisi çalıştıran kimlik ve mevcut izinler anlaşılmadan genel bir sıkılaştırma listesi uygulamayın.

Kurulu systemd sürümünün yerel kılavuzunu esas alın. Resmî geliştirme kaynağında bulunan bir seçeneğin dağıtımınızdaki sürümde bulunması garanti değildir. Çekirdek, konteyner ve kullanıcı servisi bağlamı da uygulanabilirliği etkileyebilir. Desteklenmeyen seçeneğin yok sayılmasıyla güvenli biçimde etkinleşmesini karıştırmayın. Kabul kaydına sürüm, hizmet türü ve gerçekten etkin olan ayarlar yazılmalıdır; yalnızca dosyaya eklenen satırlar yeterli kanıt değildir.

1. Gerekli kaynakları çıkar
2. Sürüm desteğini doğrula
3. Tek kısıtı pilotta uygula
4. İzinli ve yasak yazmayı sına
5. Önceki ayara kontrollü dön

Yazma alanını daraltırken klasik izinleri unutmayın

ProtectSystem gibi seçenekler servis için dosya sistemi görünümünü kısıtlamaya yardımcı olabilir. ReadWritePaths ile belirli alanların yazılabilir görünmesi, Unix dosya izinlerini kendiliğinden aşmaz. Çalışan kimliğin gerekli sahiplik ve izinleri ayrıca sağlaması gerekir. Tersine geniş bir dizini istisna yapmak da amaçlanan dar kapsamı zayıflatabilir. Kalıcı durum için StateDirectory gibi yönetilen seçeneklerin kurulu sürümdeki davranışını değerlendirin.

Bir veritabanının yalnız ana dosyaya değil yan günlük ve kilit dosyalarına da ihtiyaç duyabileceğini hesaba katın. SQLite kullanan bir hizmette yalnız dosya yolunu düşünmek, aynı dizinde oluşturulan yardımcı dosyalarda hata üretebilir. Hata çözmek için bütün korumayı kapatmak yerine gereken dizin kapsamını laboratuvarda doğrulayın. Yedek veya günlük işinin farklı kimlikle çalışması durumunda onun gereksinimi de ayrı ele alınmalıdır.

NoNewPrivileges bütün yetkileri kaldırmaz

NoNewPrivileges işlemlerin çalıştırma yoluyla yeni ayrıcalık elde etmesini sınırlandıran bir mekanizmadır; hizmetin mevcut bütün yetkilerini yok etmez. Ağ erişimi, açık dosya tanıtıcıları ve başka hizmetlerden istenebilen işlemler ayrıca değerlendirilmelidir. Bir seçeneği etkinleştirmek uygulamadaki yetkilendirme kusurlarını otomatik düzeltmez. Resmî systemd belgelerinin anlattığı kombinasyon ve kapsam sınırlarını dikkate alın; tek satırdan tam sandbox sonucu çıkarmayın.

systemd-analyze security servis ayarlarını değerlendirmeye yardımcı olur. Üretilen puan, uygulama kodunun güvenlik incelemesi veya saldırı testi değildir. Araç kendi denetlediği mekanizmaları değerlendirir; uygulama içi kontrolleri ve bütün süreçler arası yetki ilişkilerini kapsamaz. Bu nedenle puanı iyileştirmek tek başarı ölçütü olmamalıdır. Gerekli işlevin sürmesi ve istenmeyen erişimin reddedilmesi birlikte gösterilmelidir.

Pilot kabulü ve geri dönüş

Üretimden ayrı bir örnekte tek değişiklikle başlayın. Hizmetin açılışı, zararsız veri yazması, yeniden başlaması ve günlük üretmesi için olumlu senaryolar hazırlayın. Ardından ilgisiz bir test dizinine yazmanın reddedildiğini kontrollü biçimde gözlemleyin. Gerçek sistem dosyasını bozarak test yapmayın. Hata kaydında servis kimliği, test yolu ve beklenen sonuç yeterli olsun; özel uygulama içeriğini eklemeyin.

Geri dönüşte yalnız bu çalışma için eklenen değişiklik parçasını kaldırın veya önceki onaylı sürümünü geri alın. Diğer yönetim politikalarını topluca sıfırlamayın. Yapılandırmanın yeniden okunmasıyla çalışan sürecin yeni kısıtlarla başlaması farklı aşamalar olabilir; bakım planını buna göre uygulayın. Temiz başlangıçtan sonra işlev kabulünü yineleyin. Bu yazı bir cihaz üzerinde yürütülmüş sıkılaştırma raporu değil, sürüm uyumlu ve geri alınabilir inceleme planıdır.

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: systemd sandbox pilotu — Temsili unit adı gerçek servisle değiştirilmeli; servis bağımlılıkları ve gerekli yazma yolları biliniyor olmalı.

1. Servisin gerçek yazma alanlarını bulun
2. Dar drop-in hazırlayın
3. Config ve dosya erişimini doğrulayın
4. Gerçek işlev ve reddi sınayın
5. Yalnız yeni drop-in farkını geri alın

1. Servisin gerçek yazma alanlarını bulun

Linux systemd örneğinde var olan uygulama, servis kullanıcısı, çalışma dizini ve gereken veri/log/cache yollarını kaydedin.

systemctl cat batuhanyazici-uygulama.service
systemctl show batuhanyazici-uygulama.service -p User -p WorkingDirectory -p StateDirectory
systemd-analyze security batuhanyazici-uygulama.service

2. Dar drop-in hazırlayın

Aşağıdaki örnek /etc/systemd/system/batuhanyazici-uygulama.service.d/override.conf içeriğidir. Mevcut User/ExecStart değiştirilmez. StateDirectory uygulamanın gerçekten kullandığı yolla eşleşmeli; bu örnek cihaz/kamera kullanan her uygulamaya aynen uygun değildir.

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectSystem=strict
ProtectHome=yes
StateDirectory=batuhanyazici-app
ReadWritePaths=/var/lib/batuhanyazici-app

3. Config ve dosya erişimini doğrulayın

systemctl edit ile mevcut override’ın yedeğini alarak tek farkı ekleyin. Makinenizdeki systemd sürümünün desteklemediği direktifi sessizce kabul edilmiş saymayın.

sudo systemd-analyze verify /etc/systemd/system/batuhanyazici-uygulama.service
sudo systemctl daemon-reload

4. Gerçek işlev ve reddi sınayın

Bakım penceresinde restart sonrası uygulamanın kendi veri yoluna yazabilmesini, korunması gereken başka yola yazamamasını kendi sentetik kabulüyle doğrulayın. Sandbox puanı tek başına işlev kanıtı değildir.

sudo systemctl restart batuhanyazici-uygulama.service
systemctl status batuhanyazici-uygulama.service --no-pager
journalctl -u batuhanyazici-uygulama.service --since "5 minutes ago" --no-pager

5. Yalnız yeni drop-in farkını geri alın

Önceki override içeriğini geri yükleyip daemon-reload ve restart kabulünü tekrarlayın. systemctl revert bütün yerel değişiklikleri kaldırabileceği için genel geri dönüş olarak kullanılmaz.

Beklenen sonuç: Hizmet yalnız gereken alanlara erişirken gerçek işlevi çalışır.

Sonuç farklıysa: Yeni ret kaydında tüm sandbox’ı kapatmadan eksik yol/cihaz bağımlılığını belirleyin.

Geri dönüş: Yalnız yeni drop-in değişikliğini önceki onaylı sürüme geri alın.