iOS Sandboxing ve IPC (Inter-Process Communication)

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

iOS Sandboxing (Kumhavuzu), Apple’ın mobil işletim sisteminin güvenlik mimarisinin temel taşı olan, süreç (process) düzeyinde zorunlu erişim kontrolü (MAC – Mandatory Access Control) mekanizmasıdır. Bu mimari, her uygulamanın dosya sistemi, ağ, donanım ve diğer süreçlerle etkileşimini katı bir politika çerçevesinde kısıtlayarak “en az ayrıcalık” (Least Privilege) ilkesini işletim sistemi çekirdeği (XNU) seviyesinde garanti altına alır. IPC (Inter-Process Communication), bu yalıtılmış süreçler arasında güvenli, doğrulanmış ve yetkilendirilmiş veri alışverişini sağlayan protokol yığınıdır. Bu incelemenin ontolojik çerçevesi; Sandbox profilinin (.sb dosyaları), sandboxd daemon’ının karar verme mantığı, XPC (Cross-Process Communication) mesajlaşma altyapısının Mach port tabanlı tasarımı ve launchd orkestrasyonu üzerine kuruludur. Metodolojik yaklaşım; statik profil analizi, çalışma zamanı syscall izleme (dtrace/Instruments), XPC bağlantı güvenliği (Code Signing/Entitlements doğrulaması) ve saldırı yüzey analizi (Attack Surface Analysis) vektörlerini birleştirerek sistem bütünlüğü ve veri gizliliği risklerini nicelendirmeyi hedefler.

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

Sandboxing mekanizması, XNU çekirdeğinin Sandbox.kext (veya modern sürümlerde AppleMobileFileIntegrity – AMFI entegrasyonu ile kullanıcı alanı sandboxd kooperasyonu) alt sistemleri tarafından uygulanır. Her süreç başlatıldığında (execve), kod imzası (Code Signature) içindeki entitlements (haklar) ve sistem tarafından atanan container yolu (/var/mobile/Containers/Data/Application/<UUID>) ile bir Sandbox profili ilişkilendirilir. Bu profil, allow/deny kurallarıyla file-read*, file-write*, network-outbound, mach-lookup, sysctl-read gibi işlemleri denetler. IPC tarafında ise XPC, Mach portlarını (message queues) soyutlayan, serileştirme (serialization), bağlantı yönetimi ve güvenlik bağlamı (Security Context) aktarımını sağlayan yüksek seviyeli bir API’dir. XPC servisleri (XPC Service targetları), ana uygulama sürecinden ayrı bir launchd yönetiminde süreç olarak çalışır. Bağlantı kurulduğunda (xpc_connection_create), peer’in audit_token (PID, UID, GID, ASID) ve kod imzası (sec_code_copy_signing_information) çekirdek tarafından doğrulanır. Bu “Mutual Authentication” (Çift Yönlü Kimlik Doğrulama), bir sürecin meşru bir XPC servisine mi yoksa bir saldırganın sahte bir uç noktasına mı bağlandığını çalışma anında garanti altına alır.

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

iOS güvenlik mimarisi, Common Criteria (ISO/IEC 15408) EAL 4+ sertifikasyon hedefleriyle uyumlu olarak tasarlanmıştır; Sandbox politikaları Bu standartların “Access Control Policy” (FDP_ACC) ve “Information Flow Control” (FDP_IFC) sınıflarına karşılık gelir. Kod imzalama ve yetkilendirme altyapısı (Code Signing/Entitlements), X.509 PKI standardlarına dayanan Apple Root CA zinciri ile doğrulanır. IPC protokolü olan XPC, Mach IPC (Mach Kernel Interface – MKI) üzerine inşa edilmiş, xpc_object_t hiyerarşisi (Dictionary, Array, Data, UUID, FD, Error, Connection) ile tipli, boyut ön ekli (length-prefixed) bir serileştirme formatı kullanır. Ağ seviyesinde IPC yoktur (sadece yerel), ancak NSXPCConnection uzak süreçler için proxy tabanlı dağıtık nesne modeli (Distributed Objects) sunar. Güvenlik değerlendirme metodolojileri; sandbox-exec ile profil test etme, Console.app/os_log ile sandboxd reddedme logları (deny logs) analizi, codesign -d --entitlements :- ile yetki denetimi ve xpcspy/Frida ile çalışma zamanı XPC mesaj trafiği tersine mühendisliği (Reverse Engineering) kapsar. MITRE ATT&CK mobil matrisi (T1430 – Modify System Partition, T1548 – Abuse Elevation Control Mechanism) bu analizlerin tehdit modellemesi için referans alını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?

Pratikte en yaygın senaryo, ana uygulama (UI Process) ile ağır işlem yapan bir XPC Servisi (Network/Database/Crypto) arasındadır. Örneğin; bir bankacılık uygulaması, hassas kriptografik anahtarları ve PIN doğrulama mantığını com.bank.app.keymanager adlı bir XPC servisinde, com.apple.security.application-groups olmadan, tamamen yalıtılmış bir container’da barındırır. Ana uygulama NSXPCConnection üzerinden verifyPIN:completion: mesajı gönderir; servis SecKey operasyonlarını Secure Enclave (SEP) ile gerçekleştirir, sonucu döner. Bu tasarım, UI sürecinin bellek dökümünden (memory dump) anahtar malzemesinin çalınmasını engeller. Diğer kritik senaryo App Extensions (Share, Widget, Keyboard) ile ana uygulama arası IPC’dir; burada NSFileCoordinator ve NSFilePresenter protokolleri, paylaşılan App Group container’daki dosya tutarlılığını (POSIX Locks / F_SETLK) sağlar. Güvenlik odaklı bir vaka analizinde; CVE-2021-30807 (XPC Type Confusion) gibi zafiyetler, XPC mesajındaki xpc_object_t tipinin doğrulanmaması sonucu servis sürecinde kod çalıştırmaya (RCE) yol açmıştır. Modern en iyi pratik; NSXPCInterface ile protokol tanımı yaparak, setClasses:forSelector: ile beklenenden farklı sınıf gelirse bağlantıyı reddetmektir.

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

Birincil operasyonel darboğaz, Sandbox profilinin statik doğasından kaynaklanan “Over-Privileging” (Aşırı Yetkilendirme) sorunudur; geliştiriciler com.apple.security.files.user-selected.read-write gibi geniş yetkiler verirken com.apple.security.files.bookmarks.app-scope gibi daraltılmış yetkileri ihmal eder. Bu, bir XPC servisi kompromite edildiğinde tüm kullanıcı verilerinin ele geçirilmesine yol açar. İkinci risk, XPC bağlantı kimlik doğrulamasındaki “Race Condition” (TOCTOU – Time-of-Check Time-of-Use) zafiyetleridir; xpc_connection_set_event_handler ayarlanmadan önce resume edilmesi veya audit_token doğrulaması yapılmaması durumunda sahte bir istemci bağlanabilir. Çözüm: xpc_connection_set_target_uid/gid veya codesign tabanlı sec_code_check_validity ile peer doğrulaması resume öncesinde zorunlu kılınmalıdır. Üçüncü zorluk, büyük veri (blob/video) transferinde XPC mesaj boyutu limitleri ve kopyalama maliyetidir (xpc_data_create kopyalar). Çözüm: xpc_dictionary_set_fd ile mmap edilmiş dosya tanıtıcılarını (File Descriptors) SCM_RIGHTS üzerinden geçirerek sıfır kopyalı (zero-copy) paylaşım sağlamak. Dördüncü risk, launchd tarafından yönetilen XPC servislerin RunLoop bloklanması sonucu “Watchdog” timeout (genelde ~20-30sn) ile öldürülmesidir; asenkron dispatch_io / async/await kullanımı zorunludur.

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

iOS 17/macOS 14 (Sonoma) ile birlikte Swift Concurrency (async/await) XPC entegrasyonu (NSXPCConnection + withCheckedContinuation) standart hale geldi, bu da bloklama riskini azaltti. Lockdown Mode (Kilitlenme Modu), belirli XPC servislerini (örn. com.apple.mobile.installd bazen hedeflenir) ve karmaşık veri ayrıştırıcıları (Font, Image parsers) devre dışı bırakarak saldırı yüzeyini radikal şekilde küçültüyor. Donanım seviyesinde Apple Silicon (M-serisi / A-serisi) PAC (Pointer Authentication Codes) ve MTE (Memory Tagging Extension – ARMv9, A17 Pro/M3 ile geliyor), XPC mesaj işleme tamponlarında (buffer) oluşabilecek bellek bozulmalarının (Heap Overflow) sömürülmesini donanımda engelliyor. Gelecek 5-10 yılık projeksiyonda; CHERI (Capability Hardware Enhanced RISC Instructions) mimarisi benimsenirse, pointer’lar yetki (capability) taşıyacak ve Sandbox/IPC sınırları donanımda zorlanacak (CHERIOS/CHERIBSD çalışmaları). Ayrıca XPC yerine Swift Distributed Actors veya gRPC (Localhost/Unix Socket üzerinden) gibi daha standart, dil bağımsız, protokol tamponlu (Protobuf) IPC modellerinin, özellikle sunucu taraflı Swift (Swift on Server) ekosistemiyle uyum için evrilmesi bekleniyor. App Sandbox profilleri, SELinux/AppArmor benzeri bildirimsel (declarative) policy dilleri (örn. sandbox-exec Scheme tabanlı) yerine Swift tabanlı DSL (Domain Specific Language) ile tür güvenli (type-safe) hale getirilebilir.

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

Soru 1: Neden iOS’ta fork() kullanılamaz ve IPC nasıl sağlanır?

iOS, fork() sistem çağrısını güvenlik ve bellek yönetimi (Copy-on-Write karmaşası, shared state riskleri) nedenleriyle kısıtlar (POSIX_SPAWN kullanılmalıdır). IPC için Apple, Mach port tabanlı, mesaj geçirimli (message-passing), çekirdek tarafından मध्यस्थlik edilen XPC altyapısını zorunlu kılar. Bu, süreçler arası paylaşılan bellek (shared memory) yerine kontrollü mesajlaşmayı zorlayarak yalıtımı güçlendirir.

Soru 2: NSXPCConnection mı, düşük seviyeli xpc_connection_t (C API) mi kullanılmalıdır?

Çoğu durumda NSXPCConnection (veya Swift Distributed Actors) tercih edilmelidir; çünkü NSXPCInterface ile protokol tanımlama, otomatik proxy oluşturma, tipli serileştirme (NSSecureCoding), yaşam döngüsü yönetimi ve hata işleme (error handling) güvenli bir soyutlama sağlar. C API sadece performans kritik, C/C++ kod tabanı entegrasyonu veya launchd sistem daemonları yazılırken gereklidir.

Soru 3: XPC servisine gelen isteğin gönderen uygulamanın meşru olup olmadığını nasıl anlarız?

Bağlantı kurulduğunda xpc_connection_get_audit_token (veya NSXPCListenerDelegate‘de listener:shouldAcceptNewConnection:) kullanılarak peer’in audit_token_t alınır. Bu token ile sec_code_copy_guest_with_attributes / sec_code_check_validity çağrılarak kod imzası, Team Identifier, Bundle Identifier ve Entitlements doğrulanır. Sadece beklenen code signing identity sahibi süreçler kabul edilmelidir.

Soru 4: Sandbox profili (container.sb) özelleştirilebilir mi? Üçüncü parti uygulamalar kendi kuralını yazabilir mi?

Hayır. iOS’ta üçüncü parti uygulamalar için Sandbox profili Apple tarafından sabitlenmiş container profilidir ve değiştirilemez. Geliştirici sadece Entitlements.plist (.entitlements dosyası) aracılığıyla önceden tanımlanmış yetki anahtarlarını (key-value) talep edebilir. macOS’ta (App Store dışı) sandbox-exec ile özel profil yazılabilir ancak iOS’ta bu imkansızdır.

Soru 5: Büyük dosyaları (örn. 500MB video) XPC ile nasıl verimli taşırız?

XPC mesajları (xpc_data_create) veri kopyaladığı için büyük dosyalarda bellek baskısı (OOM – Out of Memory) ve performans kaybı yaratır. Doğru yöntem: Dosyayı mmap (Memory Map) edip veya open ederek File Descriptor (FD) elde etmek ve xpc_dictionary_set_fd ile SCM_RIGHTS (Unix Domain Socket ancillary data) mekanizması üzerinden karşı tarafa geçirmektir. Karşı taraf bu FD’yi read/mmap ile sıfır kopyalı erişir.

Soru 6: App Groups kullanmak Sandbox yalıtımını zayıflatır mı? Nasıl minimize edilir?

Evet, App Groups (com.apple.security.application-groups), iki uygulama/uzantı arasında paylaşılan bir dosya sistemi kökü (/var/mobile/Containers/Shared/AppGroup/<ID>) oluşturduğu için yalıtımı kırar; bir süreç kompromite edilirse diğerinin verileri okunabilir/yazılabilir. Riski minimize etmek için: 1) Sadece gerekli veriyi yazın, 2) Hassas veriyi (Keychain, Token) App Groupa koymayın (Keychain Access Groups kullanın), 3) NSFileCoordinator ile kilitleme yapın, 4) Veriyi şifreleyin (Data Protection: NSFileProtectionCompleteUnlessOpen).

Bölüm 9: Bilmeniz Gereken Temel Terimler

Entitlement (Hak/Talep): Uygulamanın kod imzası içine gömülmüş, Sandbox tarafından yorumlanan anahtar-değer çiftleri (örn. com.apple.security.network.client, aps-environment). Çalışma anında yetki genişletme mekanizmasıdır.

Mach Port: XNU çekirdeğindeki temel IPC primitifi; tek yönlü, sıralı, çekirdek tarafından yönetilen mesaj kuyruğudur. XPC, bu portları send right / receive right haklarıyla soyutlar.

XPC Service (XPC Hizmeti): Ana uygulamadan ayrı bir süreç olarak launchd tarafından başlatılan, .xpc uzantılı bundle. Kendi Sandbox container’ına ve ayrıcalıklarına sahiptir; çökmesi ana uygulamayı etkilemez (Process Isolation).

Audit Token (Denetim Jetonu): Çekirdek tarafından her süreç ve Mach port iletişimi için atanan, sahteleştirilemez kimlik yapısı (audit_token_t). PID, UID, GID, ASID (Audit Session ID) içerir; peer doğrulaması için kullanılır.

App Sandbox (Uygulama Kumhavuzu): Sürecin dosya sistemi (Container), ağ, donanım (Kamera/Mikrofon), IPC (Mach lookup) ve sistem çağrıları (syscall) erişimini kısıtlayan, çekirdek zorunlu erişim kontrolü (MAC) politikasıdır.

Hardened Runtime: Derleyici/Linker seviyesinde (LLVM/ld64) ve çalışma anında (dyld) etkinleştirilen koruma seti: Library Validation (DYLD_INSERT_LIBRARIES engelleme), RWX bellek engelleme (JIT dışında), DTrace engelleme, Invalid Signature engelleme.

SCM_RIGHTS / FD Passing: Unix Domain Socket’ler üzerinden sendmsg/recvmsg ile cmsghdr yapısı kullanılarak süreçler arası dosya tanıtıcısı (File Descriptor) transferi. XPC’in büyük veri transferi için kullandığı alt mekanizmadır.

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

iOS Sandboxing ve XPC IPC mimarisi, modern mobil güvenliğin “Altın Standardı” niteliğinde, donanım-kernel-kullanıcı alanı üçgeninde derinlemesine entegre bir savunma derinliği (Defense in Depth) sunar. Analizlerimiz; yalıtımın sadece bir dosya sistemi kısıtlaması olmadığını, Mach port hakları, kod imzalama zinciri, entitlement tabanlı yetkilendirme ve PAC/MTE gibi donanım kökenli bellek güvenliği mekanizmalarıyla birleşerek tam bir “Zero Trust” süreç modeli oluşturduğunu ortaya koymuştur. Karar vericiler ve mimarlar için stratejik yol haritası şöyledir: 1) Tasarım Aşaması: Her bileşen için “En Az Ayrıcalık” prensibiyle XPC servisi ayrıştırma (Process Separation) kararını verin; UI, Network, Crypto, Storage ayrı süreçler olmalıdır. 2) Geliştirme Aşaması: NSXPCInterface ile şematik sözleşme (Contract) tanımlayın, NSSecureCoding zorunlu kılın, Hardened Runtime ve Library Validation kapatmayın. 3) Dağıtım/Süreç: CI/CD hattına codesign --verify --deep --strict ve sandbox-exec (macOS simülasyonu için) entegre edin. 4) Operasyonel: os_log (Unified Logging) ile sandboxd reddetme loglarını ve XPC bağlantı hatalarını merkezi SIEM’e aktarın. Bu mimari, gelecekte CHERI ve bellek güvenli diller (Rust/Swift 6+ Ownership) ile birleşerek, sıfır gün (zero-day) bellek bozulması zafiyetlerinin etkisini neredeyse sıfıra indirecek seviyeye evrilecektir. Tekno Aktif ekibi ve geliştiriciler bu prensipleri benimseyerek, sadece “çalışan” değil, “saldırıya dayanıklı” (Resilient) mobil ekosistemler inşa edebilir.