iOS Sandboxing ve IPC (Inter-Process Communication): Uygulama Yalıtımı ve XPC Güvenliği: Maliyet, süre, standartlar ve yasal/mühendislik sınırları

Bölüm 1: Bu Nedir ve Neden Hayati Önem Taşır?

iOS Sandboxing, Apple’ın mobil işletim sisteminde zorunlu erişim kontrolü (MAC – Mandatory Access Control) politikasıyla uyguladığı, süreç tabanlı zorunlu yalıtım mimarisidir. Her uygulama, kendine ait benzersiz bir evrensel benzersiz tanımlayıcı (UUID) ve rastgele üretilmiş bir ev dizini (Container) ile donatılır; bu dizin dışındaki dosya sistemine, donanım kaynaklarına veya diğer süreçlerin bellek alanlarına doğrudan erişim sandboxd daemon’u ve çekirdek seviyesindeki Sandbox.kext uzantısı tarafından engellenir. IPC (Inter-Process Communication) ise bu yalıtım duvarında kontrollü delikler açmak için tasarlanmış, mesaj tabanlı, yetki temelli bir iletişim protokolüdür. XPC (Cross-Process Communication), Mach portları üzerine inşa edilmiş, launchd tarafından yönetilen ve kod imzalama (Code Signing) ile entegre olan Apple’ın sahipli, yüksek performanslı IPC çerçevesidir. Bu çalışma; sandbox逃逸 (escape) riskleri, XPC servislerinin yüzey saldırı alanları (attack surface), entitlement (hak claim) yönetimi ve sıfır güven (Zero Trust) mimarisine uygunluk açısından mühendislik maliyetlerini, sertifikasyon süreçlerini ve yasal uyumluluk (GDPR, KVKK, CCPA) sınırlarını ontolojik bir çerçevede analiz eder.

Bölüm 2: Perde Arkası: Sistem Nasıl Çalışıyor?

Sandbox mekanizması, XNU çekirdeğinin MACF (Mandatory Access Control Framework) kancaları üzerinden seatbelt profilleri ile çalışır. Uygulama başlatıldığında launchd, yürütülebilir dosyanın CodeDirectory hash’ini doğrular, entitlements.plist içindeki com.apple.security.app-sandbox anahtarını okur ve süreç için bir sandbox profili (.sb dosyası derlenmiş haliyle) yükler. Bu profil, file-read*, file-write*, network-*, process-exec gibi işlemleri kural tabanlı (regular expression/path prefix) filtreler. IPC tarafında XPC, Mach portları (message queues) kullanarak sıralı, güvenilir, iki yönlü mesaj geçişi sağlar. XPC Connection (xpc_connection_create_mach_service), server tarafında launchd.plist ile tanımlanan bir Mach hizmet adı (reverse DNS formatında) dinlerken, client tarafında bu isimle bağlantı kurar. Güvenlik, xpc_connection_set_event_handler içinde gelen xpc_dictionary_t mesajının audit_token (pid, uid, gid, ASID) ve kod imzalama bilgileri (sec_code_check_validity) ile doğrulanmasıyla sağlanır. Bu mimari, “Least Privilege” (En Az Ayrıcalık) ilkesini zorunlu kılar; bir XPC servisi sadece tanımlandığı entitlement’ları kullanabilir, ana uygulamanın yetkilerini miras almaz.

Bölüm 3: Bilim Dünyası ve Uzmanlar Nasıl İnceliyor?

Geliştirme ve denetim süreçleri; Apple Platform Security Guide, NIST SP 800-53 (SC-3, SC-7, AC-4, AC-6 kontrolleri), ISO/IEC 27001:2022 Annex A.8 (Bilgi Güvenliği Kontrolleri) ve Common Criteria (CC) EAL 4+ sertifikasyon hedefleriyle eşleştirilir. Statik analizde Clang Static Analyzer, sandbox-exec komut satırı aracı ile profil testleri ve codesign --verify --deep --strict ile imza zinciri doğrulaması yapılır. Dinamik analizde dtrace/Instruments (System Call tracing), xpcspy veya frida ile runtime XPC mesaj manipülasyonu (fuzzing) gerçekleştirilir. Ağ trafiği için TLS 1.3 (RFC 8446) zorunluluğu ve App Transport Security (ATS) uyumluluğu test edilir. Yasal uyumlulukte; KVKK Madde 12 (Güvenlik Tedbirleri), GDPR Madde 25 (Tasarım ve Varsayılan Olarak Veri Koruması) ve CCPA §1798.150 (Makul Güvenlik Prosedürleri) referans alınır. Süreç yönetiminde Secure SDLC (Microsoft SDL / OWASP SAMM Maturity Level 3) modeli uygulanır; threat modeling için STRIDE metodolojisi (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege) XPC endpoint’leri baz alılarak yürütülür.

Bölüm 4: Önemli Parametreler ve Karşılaştırma Rehberi

Bölüm 5: Günlük Hayatta ve Doğada Nerede Karşımıza Çıkar?

Kritik bir senaryo, finansal teknoloji (FinTech) uygulamalarında “Secure Enclave” anahtarlarının XPC üzerinden bir LaunchDaemon (Root ayrıcalıklı) ile yönetilmesidir. Uygulama (Client), kullanıcı biyometrik onayı (FaceID/TouchID) sonrası SecKeyCreateSignature isteğini, com.company.app.keymanager Mach servisine gönderir. Server, audit_token doğrulaması yapar, Client’in code signing identifier ve team ID eşleşmesini kontrol eder (sec_code_check_validity + SecRequirementCreateWithString), ardından Secure Enclave’den (SEP) anahtar kullanım yetkisi (ACL) ile imzalama yapar. Bu tasarım, ana uygulama belleğinin tehlikeye atılması (RCE) durumunda bile kök anahtarların (Root Keys) sızmamasını sağlar. Başka bir alan, MDM (Mobile Device Management) ajanlarında NetworkExtension framework’ü üzerinden paket denetleme (Packet Inspection) yaparken, sandbox dışı kernel uzantısı (System Extension / DriverKit) ile XPC üzerinden politika eşitlemesidir. NEFilterProvider süreci, sandboxed ana uygulamadan xpc_connection_send_message_with_reply_sync ile filtre kurallarını alır. Bu mimari, Apple’ın “User Space First” politikası (Kernel Extension’ların Kext’ten DriverKit/User Space’e taşınması) ile uyumludur ve kernel panic riskini azaltır.

Bölüm 6: Karşılaşılan Zorluklar ve Pratik Çözümler

Birincil operasyonel darboğaz, Entitlement Yükseltme (Privilege Escalation via Entitlement) riskidir. Geliştiriciler kolaylık sağlamak adına com.apple.security.files.user-selected.read-write (PowerBox) yerine com.apple.security.files.downloads.read-write gibi geniş kapsamlı entitlement’lar talep eder; bu da App Store Reddi (Guideline 2.5.1) veya sıfır gün exploit’te yan etki alanını genişletir. Çözüm: NSFileProvider veya UIDocumentPickerViewController ile kullanıcı yönlendirmeli erişim (User Intent) zorunlu kılınmalıdır. İkinci risk, XPC Mesaj Doğrulama Eksikliği (Insufficient Message Validation). Server tarafında gelen xpc_dictionary_t içindeki xpc_data_t boyut kontrolü yapılmadan memcpy/malloc edilirse Heap Overflow (CVE-2021-30807 tarzı) oluşur. Çözüm: xpc_dictionary_get_value -> xpc_get_type -> xpc_data_get_length -> Sınır Kontrolü (Max Payload Size) -> Güvenli Kopyalama zinciri uygulanmalıdır. Üçüncü zorluk, Sandbox Profil Hata Ayıklama Zorluğu. sandboxd logları (/var/log/sandbox.log veya Console.app -> subsystem: com.apple.sandbox) production’da kullanıcı cihazında erişilemez. Çözüm: Geliştirme aşamasında SANDBOX_LOGGING=1 ortam değişkeni ve os_log entegrasyonu ile yapılandırılmış loglama (Structured Logging) yapılmalı, CI/CD pipeline’ında sandbox-exec -f profile.sb -- /path/to/binary ile otomatize regression testleri koşturulmalıdır.

Bölüm 7: Gelecek Perspektifi ve Yeni Gelişmeler

iOS 17/18 ve macOS Sonoma/Sequoia ile gelen Lockdown Mode (Kilitlenme Modu), XPC servislerini ve sandbox profillerini “Paranoid” profiline çeker; com.apple.security.get-task-allow (debugging), JIT derleme, karmaşık yazı tipleri işleme ve geleneksel mach_msg tabanlı bazı IPC yollarını devre dışı bırakır. DriverKit (User-Space Driver Framework), kernel uzantılarını (Kexts) tamamen user-space’e taşıyarak sandboxing’in çekirdek seviyesine kadar genişletilmesini sağladı; artık donanım sürücüleri de XPC ile iletişim kurmak zorundadır. Swift Concurrency (async/await) ve Distributed Actors, XPC’nin callback tabanlı (xpc_connection_set_event_handler) karmaşık durum makinesini, async sequence ve structured concurrency ile değiştirmeye başladı; bu, xpc_connection_send_message_with_reply için withCheckedContinuation wrapper’ları yazmayı gerektiriyor. Gelecek 5-10 yıl için; CHERI (Capability Hardware Enhanced RISC Instructions) mimarisi (ARM Morello / Apple Silicon gelecek nesilleri) donanım seviyesinde bellek güvenliği (spatial/temporal memory safety) sağlayacak; bu da sandbox escape için gerekli “gadget” zincirlerini (ROP/JOP) donanımda engelleyecek. Private Cloud Compute (PCC) mimarisi, cihazdaki sandbox’ın bulut uzantısı olarak, attestation (kanıtlanabilir güven) ile şifreli hesaplama yapacak; bu da IPC’nin ağ sınırını aşarak “Remote XPC” kavramını getirecek. Yasal alanda; EU DMA (Digital Markets Act) “Gatekeeper” yükümlülükleri, Apple’a alternatif App Store’lara ve yan yüklemeye (sideloading) izin vermeyi zorunlu kılıyor; bu da sandbox profillerinin “App Store” dışı kaynaklar için (platform profili benzeri) dinamik ve kullanıcı onaylı gevşetilmesini gerektirecek.

Bölüm 8: Merak Edilen Sorular ve Cevaplar

Soru 1: App Store dağıtımı için bir uygulamaya com.apple.security.get-task-allow entitlement’ı eklenirse ne olur?

Cevap: Uygulama App Store Connect incelemesinde otomatik olarak reddedilir (Guideline 2.5.1 / 2.3.1). Bu entitlement, hata ayıklayıcının (lldb/dtrace) sürece bağlanmasına izin verir ve üretim ortamında “Hardened Runtime” politikasıyla çelişir. Sadece geliştirme (Development) provisioning profili ile test cihazlarına yüklenen binary’lerde kullanılmalıdır.

Soru 2: XPC servisi (LaunchDaemon) root ayrıcalıklarıyla çalışıyorsa, client uygulamadan gelen isteği nasıl yetkilendirmelidir?

Cevap: Sadece audit_token (PID/UID) kontrolü yetersizdir (PID reuse saldırısı riski). Zorunlu olarak SecCodeCopyGuestWithAttributes -> SecCodeCheckValidity -> SecRequirementCreateWithString (örn: identifier "com.company.app" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6]) zinciri ile Kod İmzalama Tabanlı Yetkilendirme (Code Signing Based Authorization) yapılmalıdır. Bu, binary’nin değiştirilmediğini ve Apple tarafından imzalandığını garanti altına alır.

Soru 3: Sandbox içinden sysctl komutları (örn: hw.memsize) okunabilir mi?

Cevap: Evet, salt okunur (read-only) sistem sysctl düğümlerine sandbox profili sysctl-read kuralı ile (veya varsayılan profilde) erişilebilir. Ancak sysctl-write (örn: kern.maxfiles değiştirme) kesinlikle engellenir. sysctlbyname API’si sandbox içinde güvenli bir şekilde çalışır.

Soru 4: İki farklı Team ID’ye sahip uygulamalar (App Groups olmadan) XPC ile nasıl iletişim kurabilir?

Cevap: Doğrudan xpc_connection_create_mach_service ile kuramazlar. Mach port ad alanı (bootstrap namespace) kullanıcı başına ve güvenlik oturumu (session) başına izole edilmiştir. Çapraz Team ID iletişimi için; App Groups (com.apple.security.application-groups) paylaşılan container dosya sistemi üzerinden dosya tabanlı sinyalizasyon (file coordination) veya URL Scheme / Universal Links ile süreçler arası geçiş (process launch) yapılır. Alternatif olarak, ortak bir sunucu (Cloud/Backend) aracılığıyla mesaj kuyruğu (Pub/Sub) modeli kullanılır.

Soru 5: hardened-runtime bayrağı olmadan XPC servisi güvenli mi?

Cevap: Hayır. hardened-runtime (veya codesign --options runtime); Library Validation (DYLD_INSERT_LIBRARIES engelleme), JIT yazma/yürütme engelleme (MAP_JIT), bellek koruma bypass engelleme (mprotect kısıtlamaları) ve DYLD environment variable temizliği gibi kritik çalışma zamanı korumalarını aktif eder. Bu bayrak olmadan XPC servisine kötü niyetli bir dinamik kütüphane (dylib) enjekte edilerek mesajlar manipüle edilebilir veya servis işlevselliği ele geçirilebilir.

Soru 6: Sandbox Escape (Sandbox Kaçışı) bir CVE olarak raporlandığında geliştiricinin sorumluluğu nedir?

Cevap: Geliştirici, kendi uygulama kodundaki mantık hatalarından (örn: XPC mesaj validasyon eksikliği, path traversal) kaynaklı escape’ler için sorumludur ve derhal yama (hotfix) dağıtmalıdır. Ancak çekirdek (XNU/kernel) veya sandboxd daemon’undaki sıfır gün (zero-day) kernel exploit’lerinden (CVE-2024-XXXX tarzı) kaynaklı escape’ler Apple’ın sorumluluğundadır; geliştirici bu riski azaltmak için “Defense in Depth” (Derin Savunma) prensibiyle veri şifreleme (Data Protection Class: NSFileProtectionCompleteUnlessOpen) ve anahtar yönetimini Secure Enclave’e taşımakla yükümlüdür.

Bölüm 9: Bilmeniz Gereken Temel Terimler

Entitlement (Hak Talebi / Yetki Beyannamesi): Uygulamanın Info.plist veya imza içinde yer alan, sandbox tarafından yorumlanan ve belirli sistem kaynaklarına (Kamera, Konum, Ağ, Dosya Sistemi, IPC) erişim izni veren anahtar-değer çiftleri. codesign -d --entitlements :- <app> ile görüntülenir.

Mach Port (Mach Bağlantı Noktası): XNU çekirdeğinde süreçler arası iletişimin (IPC) atomik birimi. Mesaj kuyruğu (message queue) davranışı sergiler; mach_msg sistem çağrısı ile veri (veri + port hakları/out-of-line memory) taşınır. XPC, bu portları soyutlar.

Launchd (Process ID 1): macOS/iOS’ün init sistemi ve servis yöneticisi. XPC servislerini (LaunchAgent/LaunchDaemon) launchd.plist dosyaları üzerinden başlatır, yönetir ve Mach portlarını (bootstrap namespace) kaydeder. xpc_connection_create_mach_service aslında launchd’ye kayıtlı bir port arar.

Seatbelt (Sandbox Profili Çekirdek Bileşeni): XNU çekirdeği içindeki (Sandbox.kext), MACF kancaları aracılığıyla sistem çağrılarını (open, execve, bind, connect) kesiştirip sandbox kurallarına (.sb profilleri) göre izin/red veren zorunlu erişim kontrol modülü.

Code Signing Requirement (Kod İmzalama Gereksinimi / Designated Requirement): Bir kod parçasının (binary, framework, script) güvenilirliğini doğrulamak için kullanılan mantıksal ifade (örn: identifier "com.apple.xpc" and anchor apple). SecRequirementCreateWithString ile derlenir ve SecCodeCheckValidity ile çalışma zamanında zorunlu kılınır.

Hardened Runtime (Sertleştirilmiş Çalışma Zamanı): codesign --options runtime ile aktif edilen; JIT engelleme, Library Validation, DYLD temizliği, bellek sayfası yazma/yürütme (W^X) zorunluluğu gibi exploit azaltma (mitigation) teknolojilerinin toplamı.

XPC Dictionary (XPC Sözlüğü): XPC mesajlarının temel veri yapısı; xpc_object_t türünde, anahtar-değer (key-value) tutar, serileştirme (serialization) ve dosya tanıtıcısı (file descriptor) geçirme (passing rights) yeteneğine sahiptir.

Bölüm 10: Özet ve Çıkarılması Gereken Dersler

iOS Sandboxing ve XPC mimarisi, modern mobil güvenliğin “Altın Standardı” konumundadır; ancak bu mimari “Güvenli Varsayılanlar” (Secure Defaults) sunarken, geliştiriciye “Least Privilege” (En Az Ayrıcalık) disiplini zorunlu kılar. Analizlerimiz; sandbox escape riskinin büyük kısmının çekirdek hatalarından ziyade, uygulama katmanındaki XPC arayüz tasarım hatalarından (girdi doğrulama eksikliği, yetkilendirme bypass, entitlement aşırı talebi) kaynaklandığını ortaya koymaktadır. Stratejik yol haritası şu dört pedale dayanmalıdır: 1) Shift-Left Security: CI/CD’ye sandbox-exec profil testleri, xpcspy fuzzing entegrasyonu ve codesign --verify --deep otomasyonu eklenmeli. 2) Zero Trust IPC: Her XPC mesajı “kötü niyetli” varsayımıyla (Assume Breach) doğrulanmalı; audit_token + Code Signing Requirement + Payload Schema Validation (Protocol Buffers / Swift Codable + @available kontrolü) üçlüsü uygulanmalı. 3) Entitlement Minimalizmi: Yıllık “Entitlement Denetimi” (Entitlement Audit) yapılarak kullanılmayan/geniş kapsamlı haklar iptal edilmeli, com.apple.security.files.user-selected.* tercih edilmeli. 4) Yasal Uyumluluk Otomasyonu: KVKK/GDPR “Tasarımla Gizlilik” (PbD) kanıtları için sandbox profil versiyonlama, XPC veri akış haritaları (Data Flow Diagrams) ve DPIA (Veri Koruma Etki Değerlendirmesi) belgeleri canlı tutulmalı. Apple’ın DMA sürecinde yan yüklemeye (sideloading) izin vermesiyle gelecek 24 ay içinde “Alternatif Dağıtım Kanalları” için yeni sandbox profilleri (örn: container-notarized) ortaya çıkacak; mühendislik ekipleri bu geçiş için DriverKit/System Extensions ve App Attest / DeviceCheck tabanlı uzaktan doğrulama (Remote Attestation) altyapısını şimdiden kurgulamalıdır. Bu yaklaşımlar; marka itibarını koruyacak, cezai riskleri minimize edecek ve “Güvenilir Hesaplama” (Confidential Computing) çağının mobil ucunda rekabet avantajı sağlayacaktır.