Series · 4 partsmacOS Security BoundariesPart 3 · You are here
- 1Uygulama Sandbox'taydı. XPC Sınırı Hâlâ Yetkilendirme İstiyordu
- 2İzin Verildi. Veri Kullanımı Hâlâ Politika Gerektiriyordu: macOS TCC
- 3Helper Kayıtlıydı. Yaşam Döngüsü Uygulamadan Uzun SürdüYou are here
- 4Olay Görünürdü. Tespitin Hâlâ Bağlama İhtiyacı Vardı: macOS Endpoint Security
60 saniyede macOS helper yaşam döngüsü
Görünür bir macOS uygulaması kapatıldığında bile onun login item’ı, launch agent’ı veya launch daemon’ı arka planda çalışmaya devam edebilir. Bu davranış meşru olabilir: Bir bulut senkronizasyon istemcisi arka plan işlerine, bir güvenlik ürünü sistem uzantısına (system extension), bir güncelleyici (updater) ise dar yetkili bir servise ihtiyaç duyabilir. Buradaki güvenlik sınırı bir helper’ın varlığı değildir. Asıl sınır; onu kimin paketlediği, kimin kaydettiği, kimin onayladığı, nerede çalıştığı, hangi girdileri kabul ettiği, nasıl güncellendiği ve nasıl sonlandırıldığı arasındaki ilişkidir.
Modern Service Management API’leri, bir uygulamanın imzalı uygulama paketi (bundle) içinde tutulan yardımcı yürütülebilir dosyaları (helper executables) yönetmesini sağlar. Apple’ın SMAppService dokümantasyonu login item, launch agent ve launch daemon bileşenlerini birbirinden ayırır; kayıt (registration), kaydı silme (unregistration) ve durum sorgulama imkanı tanır. Kayıt yapılması, servisin o servis türüne özgü kurallara ve onaylara tabi olarak başlatılabileceği anlamına gelir. Ancak her IPC istemcisinin yetkilendirildiği veya çalışma zamanı etkisinin kullanıcının beklentisiyle örtüştüğü anlamına gelmez.
Sızma testinin soracağı asıl faydalı soru şudur:
Uygulama penceresi, kullanıcı oturumu, sürüm, hesap veya ürünün kendisi artık aktif olmadığında hangi yetki hayatta kalmaya devam eder?
Bunu yanıtlamak bir Login Items ekran görüntüsünü değil; kişisel bir Mac’in arka plan servislerinin dökümünü de değil; yaşam döngüsü kanıtlarını gerektirir.
Paketleme, kayıt, onay ve çalıştırma ayrı durumlardır
Kulağa benzer gelen şu dört ifade tamamen farklı güvenlik anlamlarına sahiptir:
- Paketlenmiş (Packaged): Bir helper çalıştırılabilir dosyası ve property list (
.plist), imzalı bir uygulama paketinin içinde mevcuttur. - Kayıtlı (Registered): Uygulama, Service Management’tan helper’ı başlatılabilir kılmasını talep etmiştir.
- Onaylanmış (Approved): Kullanıcı veya sistem yöneticisi ilgili arka plan veya sistem düzeyindeki ögeye izin vermiştir.
- Çalışıyor (Running):
launchd, belirli bir etki alanında (domain), kullanıcı bağlamında (UID) ve oturumda bir süreç başlatmıştır.
Apple, macOS 13 ve sonrasında SMAppService’in uygulama paketine gömülü login item’lar, launch agent’lar ve launch daemon’lar için resmi denetim mekanizması olduğunu belirtir. Detaylar farklılık gösterir: Bir login item hemen ve sonraki oturum açılışlarında başlayabilir. Kayıtlı bir launch agent kullanıcının oturumunda bootstrap edilebilir. Bir launch daemon ise yönetici onayı verilene kadar bootstrap edilmez ve sonraki sistem açılışlarında geri gelebilir. Kayıt dokümantasyonu, kaydın kullanıcı onayına tabi olduğunu açıkça vurgular.
Bu geçişler değerlendirme sırasında bir durum makinesine (state machine) dönüştürülmelidir:
Tüm bilgisayardan değil, teslim edilen paketten başlayın
Gizliliğe saygılı bir inceleme, yetkilendirilmiş tek bir ürünü envanterler. Denetçinin kendi Mac’inde yüklü olan tüm kişisel login item’larını, ajanları, daemon’ları veya süreçleri listelemez.
İncelenen uygulama için şunları kaydedin:
- Her bir helper dosyası ve bundle içindeki göreli konumu;
- Kapsayıcı uygulamanın imzası ve her bir helper’ın kendi designated requirement tanımı;
- Servis plist dosyasının adı, etiketi (label), program yolu, argümanları ve başlatma koşulları;
- Login item, user agent, system daemon veya system extension rolü;
- İncelenen ürün için geçerli kayıt ve onay durumu;
- Launch domain, UID, oturum erişilebilirliği, sandbox durumu ve entitlement’lar;
- XPC veya diğer mesajlaşma arayüzleri ve peer gereksinimleri;
- Güncelleme, geri alma (rollback), kaldırma (uninstall) ve artık dosya temizleme yolları.
Salt okunur inceleme müşteri tarafından sağlanan ürün dosyasıyla başlayabilir:
find CustomerApp.app/Contents/Library -maxdepth 3 \
\( -name 'LaunchAgents' -o -name 'LaunchDaemons' -o -name 'LoginItems' \) -print
codesign -dvvv --entitlements :- CustomerApp.app
plutil -p CustomerApp.app/Contents/Library/LaunchAgents/com.example.agent.plistİmza incelemesini gerçek helper dosyası için tekrarlayın. Helper kimliğini asla ana uygulamanın pazarlama adından veya yalnızca Team ID’sinden yola çıkarak varsaymayın. Doğru şekilde imzalanmış iki bileşen tamamen farklı tanımlayıcılara, entitlement’lara, sandbox durumlarına ve güncelleme davranışlarına sahip olabilir.
Apple’ın migrasyon rehberliği, desteklenen helper kaynaklarının ve property list dosyalarının imzalı uygulama paketi içinde tutulmasını önerir. Bu durum değiştirilebilir kurulum materyalini azaltır; ancak servis yapılandırmasını veya çalışma zamanı arayüzünü doğrulama ihtiyacını ortadan kaldırmaz.
Başlatma alanlarını (launch domains) ve yetkiyi açıkça modelleyin
Bir login item, launch agent ve launch daemon birbirinin yerine geçebilen sıradan kalıcılık (persistence) etiketleri değildir:
| Bileşen | Tipik ömür | Bağlam | Kritik güvenlik sorusu |
|---|---|---|---|
| Login item | Oturum açma ve kullanıcı oturumu | Oturum açmış kullanıcı | Görünür özelliğin her oturum açılışında başlaması gerçekten gerekiyor mu? |
| Launch agent | Kullanıcı oturumu, talep anında veya kalıcı | Kullanıcı bazlı launch domain | Aynı oturumdaki hangi istemciler arayüzüne erişebilir? |
| Launch daemon | Sistem açılışı veya talep anında | Sistem domain’i, çoğunlukla root | Hangi kimliği doğrulanmış istemci istekleri sistem etkisine dönüştürebilir? |
| System extension | Sistem tarafından yönetilen yaşam döngüsü | Kısıtlanmış uzantı bağlamı | Hangi entitlement, onay, olay kaynağı ve kapsayıcı uygulama onu yönetiyor? |
| Bundled XPC service | Genellikle istemciye bağlı | Ayrı süreç | Süreç ayrımı aynı zamanda peer ve metod yetkilendirmesini zorunlu kılıyor mu? |
Yalnızca RunAtLoad değerine bakıp bir risk puanı atamak yerine, geçerli property list semantiğini kaydedin. Talep üzerine çalışan servisler, genel bir Mach servisi onları sürekli uyandırıyorsa pratikte yine kalıcıdır. Düzgün bir şekilde sonlanan bir süreç, bir arıza sonrasında sistem tarafından yeniden başlatılabilir. Tersine, diskte var olan ancak devre dışı bırakılmış ve erişilemeyen bir daemon, aktif bir güvenlik etkisi kanıtlamaz.
Yetki grafiği şu bağlantıyı kurmalıdır: Başlatma tetikleyicisi → Runtime süjesi → Çağrılabilir arayüz → Sistem etkisi. Erişilebilir bir metodu olmayan bir root etiketi tek başına bulgu değildir; geniş gizlilik erişimine ve kimlik doğrulaması yapmayan bir arayüze sahip bir kullanıcı ajanı (user agent) çok daha ağır sonuçlar doğurabilir.
Kayıt olmak, XPC çağrıcısını yetkilendirmez
Service Management servisin nasıl ve ne zaman başlatılabileceğine karar verir. XPC ise süreçlerin nasıl mesajlaşacağını belirler. Alıcı taraf; peer kimlik doğrulamasını, işlem yetkilendirmesini, girdi doğrulamasını ve etki kontrolünü bizzat yapmak zorundadır.
Çağrılabilen her metod için şu soruları sorun:
- Bağlanan sürecin karşılaması gereken kod imzalama gereksinimi (code requirement) nedir?
- Bu kimliğin mevcut ürün ve kullanıcı durumunda bu metodu çağırmasına izin veriliyor mu?
- Hangi argümanlar çağrıcı tarafından seçilmektedir?
- Servis nihai dosyaları ve nesneleri kendi bağlamında güvenli bir şekilde çözümlüyor mu?
- Daha düşük yetkiye sahip bir istemci, daha yüksek yetkili bir etki talep edebilir mi?
- Hangi denetim kaydı istek, karar, sonuç ve gerçek etkiyi birbirinden ayırır?
İlk bölümde kullanılan sentetik XPC laboratuvarı, bir sistem daemon’ına dokunmadan bu sınırı açıkça ortaya koyar. Geçici bir kullanıcı alanı servisi, farklı imzalanmış iki istemciden aynı zararsız girdiyi kabul etti. Sunucu beklenen imza tanımlayıcısını kabul edip metod çalıştırılmadan önce uyumsuz olanı reddetti; ardından servis sistemden kaldırıldı. Bu bir test yapı taşıdır; üçüncü taraf bir ürünün zafiyet içerdiğinin kanıtı değildir.
Güncelleme ve geri alma kimlik geçişleridir
Bir güncelleme; kapsayıcı uygulamayı, helper dosyasını, servis plist’ini, protokol sürümünü ve kod imzalama gereksinimini aynı anda değiştirebilir. Bu süreci bir güvenlik migrasyonu olarak test edin.
Kritik test senaryoları şunları içerir:
- Eski uygulama ile eski helper;
- Yeni uygulama ile yeni helper;
- Hâlâ çalışan eski helper ile karşılaşan yeni uygulama;
- Bundle değişimi ile servis geçişi arasında kesintiye uğrayan güncelleme;
- Daha eski bir protokole veya imza gereksinimine geri dönme (rollback);
- Uygulamanın kayıttan sonra başka bir dosya yoluna taşınması;
- Migrasyon sırasında helper çökmesi;
- Yükseltme sırasında arka plan izninin iptal edilmesi veya devre dışı bırakılması.
Kurtarılamaz bir sistem durumu yaratmadan güvenli şekilde hata verin (fail-closed). Yeni bir istemci, geride kalan rastgele bir süreçle konuşabilmek uğruna peer doğrulama gereksinimini sessizce gevşetmemelidir. Eski bir helper doğrulayamadığı yeni işlemleri kabul etmemelidir. Güncelleyici hem kaynak hem de hedef dosyaları doğrulamalı ve net bir geri alma sınırı tanımlamalıdır.
XPC protokolünü sürümleyin ve desteklenmeyen kombinasyonları açıkça reddedin. Yüksek etkili işlemleri, aynı geliştirici tarafından imzalanmış herhangi bir binary’yi kabul etmek yerine, o anda yüklü olan ürün durumuna bağlayın. Geliştirici kimliği genellikle metod yetkilendirmesi için gereğinden fazla geniştir; designated requirement hedeflenen ürünü ve izin verilen migrasyon pencerelerini açıkça belirtmelidir.
Kaldırma (Uninstall) bir güvenlik özelliğidir
Görünür .app dosyasını Çöp Sepeti’ne atmak, her helper’ın durduğunun veya arkada bıraktığı durumun silindiğinin kanıtı değildir. Ürün; servislerin kaydını silen, arka plan işlerini durduran, kimlik bilgilerini geçersiz kılan ve verileri kullanıcının tercihine göre temizleyen resmi bir kaldırma yoluna sahip olmalıdır.
Kaldırma işlemini dört katmanda doğrulayın:
- Kayıt: Service Management ürünün helper’ının artık kayıtlı olmadığını raporlar;
- Çalışma zamanı: Tanımlı servis yeniden başlatılamaz ve IPC adına ulaşılamaz;
- Artık dosyalar: Ürüne ait helper dosyaları ve yapılandırmalar belgelendiği şekilde kaldırılmıştır;
- Yetki: Token’lar, bookmark’lar, ayrıcalıklı onaylar, kuyruklar ve uzak kayıtlar artık hiçbir etki yaratmaz.
Geniş kapsamlı bir launchctl veya dosya sistemi dökümünü kanıt saymayın. Doğrudan ürün etiketini veya test domain’i tanımlayıcısını sorgulayın. Bu hem daha güvenilirdir hem de cihaz sahibinin gizliliğine saygılıdır.
Kanıt matrisi
| İddia | Pozitif kanıt | Negatif kontrol | Neler kanıtlanmamış kalır |
|---|---|---|---|
| Helper beyan edildiği gibi paketlenmiştir | Bundle içi yol, çalıştırılabilir dosya imzası, plist hash’i | Değiştirilmiş kopya imza doğrulamasını geçemez | Başka bir Mac’teki çalışma zamanı onayı |
| Kayıt hedeflenen servisi oluşturur | Kesin SMAppService durumu ve adlandırılmış servis yanıtı | Kaydı silinmiş durum başlatılamaz | İncelemeye sunulmayan eski yükleyici (installer) yolları |
| Runtime kimliği tasarımla örtüşür | Tanımlı launch domain, UID, entitlement’lar, protokol sürümü | Yanlış oturum veya yanlış peer reddedilir | Tüm kurumsal yönetim kombinasyonları |
| Yüksek yetkili metodlar arayanı doğrular | Onaylanmış kod gereksinimi sentetik tek bir etkiye ulaşır | Uyumsuz imza tanımlayıcısı metod gövdesinden önce reddedilir | Aynı geliştiricinin gelecekteki bilinmeyen imzalı ürünleri |
| Güncelleme sınırı korur | Eskiden yeniye ve kesintiye uğrayan güncelleme senaryoları tanımlıdır | Desteklenmeyen istemci/helper çifti güvenle kapanır | Kapsam dışındaki üretici güncelleme altyapısı |
| Kaldırma işlemi kalıcılığı tamamen siler | Servis kaydı silinir, yeniden başlayamaz, ürün durumu temizlenir | Yeniden başlatma veya oturum açma göstergeyi yeniden üretmez | Belgelenmiş politika gereği kasıtlı tutulan veriler |
Kanıtlar yapılandırma, gözlem ve etkiyi birbirinden ayırmalıdır. Bir property list istenen yapılandırmayı gösterir. Bir süreç listesi tek bir andaki gözlemi gösterir. Sınırlandırılmış bir test ise belirli bir istemcinin belirli bir sonuca neden olup olamayacağını kanıtlar. Bunların hiçbiri tek başına tüm yaşam döngüsünü kanıtlamaya yetmez.
İyileştirme öncelikleri
Çoğu bulgu için başarısız olan en dar geçişi onarın:
- Desteklendiği durumlarda değişken yükleyici betikleri yerine güncel Service Management modelini kullanın;
- Helper dosyalarını imzalı paket içinde tutun ve her çalıştırılabilir dosyanın kimliğini ayrı ayrı doğrulayın;
- Kayıt talebini alakasız bir kurulum gürültüsü olarak değil, arka plan özelliğinin mantığı kullanıcıya açıklandığı anda yapın;
- XPC peer’larını dar bir kod gereksinimi ile doğrulayın ve her metodu bağımsız olarak yetkilendirin;
- Daemon işlemlerini en aza indirin; rastgele komutlar yerine dosya tanıtıcıları (handles) veya yapılandırılmış niyetler aktarın;
- Protokolleri sürümleyin ve güvensiz eski/yeni kombinasyonlarını reddedin;
- Devre dışı bırakılmış, reddedilmiş ve çökmüş durumları kullanıcıyı zorlayan kayıt döngülerine sokmadan görünür kılın;
- Yaşam döngüsü kararlarını ürün kapsamındaki tanımlayıcılarla ve kişisel içerik barındırmadan günlüğe kaydedin;
- Eksiksiz bir kayıt silme ve temizleme davranışı sağlayın, ardından bunu oturum açma ve yeniden başlatma senaryolarında regresyon testine tabi tutun.
Kalıcılık (persistence) otomatik olarak kötü amaçlı değildir; kullanıcı onayı da tek başına yeterli bir güvenlik garantisi değildir. Yüksek kaliteli bir macOS ürünü, helper bileşeninin amacını, yetkisini, mevcut durumunu ve sistemden nasıl kaldırılacağını görünür uygulamanın kendisi kadar şeffaf hale getirir.
Kaynaklar
- Apple Geliştirici Dokümantasyonu, Service Management
- Apple Geliştirici Dokümantasyonu,
SMAppService - Apple Geliştirici Dokümantasyonu,
register() - Apple Geliştirici Dokümantasyonu, Updating helper executables from earlier versions of macOS
- Apple Geliştirici Dokümantasyonu, Updating your app package installer to use the new Service Management API
- Apple Geliştirici Dokümantasyonu, XPC
Bu çalışma, kaynakları gözden geçirilmiş bir değerlendirme metodolojisidir. Yerel örneğinde geçici bir kullanıcı alanı servisi ve sentetik girdiler kullanılmıştır; kişisel bir Mac’in arka plan ögelerini listelemez veya üçüncü taraf bir kalıcılık zafiyeti iddia etmez.
Bu teknik not ne kadar güncel?
En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.
Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.