Uygulama Sandbox'taydı. XPC Sınırı Hâlâ Yetkilendirme İstiyordu

Series · 4 partsmacOS Security BoundariesPart 1 · You are here

1. 1Uygulama Sandbox'taydı. XPC Sınırı Hâlâ Yetkilendirme İstiyorduYou are here
2. 2İzin Verildi. Veri Kullanımı Hâlâ Politika Gerektiriyordu: macOS TCC
3. 3Helper Kayıtlıydı. Yaşam Döngüsü Uygulamadan Uzun Sürdü
4. 4Olay Görünürdü. Tespitin Hâlâ Bağlama İhtiyacı Vardı: macOS Endpoint Security

60 saniyede macOS sınırları

Bir macOS uygulaması nadiren tek bir izin kümesine sahip tek bir süreçten ibarettir. Görünür uygulama sandbox altına alınmış, noter onayından geçmiş (notarized), imzalanmış ve Hardened Runtime ile korunuyor olabilir. Ancak paketinin (bundle) içinde bir XPC servisi, login item, launch agent, launch daemon, sistem uzantısı (system extension), komut satırı aracı veya paylaşımlı bir konteyner de bulunabilir. Bu bileşenlerin her biri farklı bir kimlik, yaşam döngüsü, sandbox profili, entitlement kümesi ve kullanıcı veya sistem kaynaklarına farklı erişim haklarıyla çalışabilir.

Bu mimari genellikle iyi bir güvenlik mühendisliğinin sonucudur. Ayrıcalıklı veya arızalanmaya açık işler kullanıcı arayüzü sürecinden çıkarılıp dar bir arayüz arkasına taşınabilir. Ancak süreçlerin birbirinden ayrılması, tek başına bir yetkilendirme (authorization) yaratmaz.

İsteği alan servisin şu kararları hâlâ vermesi gerekir:

• Hangi süreç bağlandı?
• Bu süreç hangi kod imzalama (code-signing) kimliğini karşılıyor?
• Arayan istemcinin bu işlemi çağırmasına izin var mı?
• Argümanlar, arayanın kontrol etmesine izin verilen kaynakları mı belirtiyor?
• Talep edilen eylem dosya yolu, sahiplik, durum ve kullanıcı onayı kurallarını koruyor mu?
• Görünür uygulama kapandıktan sonra hangi yetki ve kalıcılık (persistence) hayatta kalıyor?

Temel soru “uygulama sandbox’ta mı?” değildir:

Güvenilmeyen uygulama niyeti nerede bir dosyaya, sürece, ayarlara, kimlik bilgisine veya sistem düzeyinde bir etkiye dönüşüyor?

İşte bu dönüşüm noktası, macOS yetki sınırının tam olarak kendisidir.

Farklı soruları yanıtlayan yedi koruma katmanı

macOS birden fazla güvenlik mekanizmasını katmanlar halinde sunar. Bunlar birbirini güçlendirir; ancak birbirinin eş anlamlısı değildirler.

Mekanizma	Yanıtladığı temel soru	Neyi kanıtlamaz
Kod imzalama	Bu çalıştırılabilir dosya hangi imzalı kod kimliğini karşılıyor?	Kodun güvenli olduğunu veya bu çağrıcının her işlem için yetkili olduğunu
Noter onayı ve Gatekeeper	Dağıtılan yazılım platform dağıtım ve başlatma kontrollerini geçti mi?	Çalışma zamanı iş mantığının ve yerel IPC yetkilendirmesinin doğru olduğunu
Hardened Runtime	Hangi süreç bütünlüğü korumaları ve istisnaları geçerlidir?	Dosyaların, servislerin veya XPC metodlarının uygulama politikasını uyguladığını
App Sandbox	Bu çalıştırılabilir dosya ele geçirilirse hangi kaynaklara erişebilir?	Paketteki başka bir bileşenin aynı sandbox veya yetkiye sahip olduğunu
TCC ve kullanıcı onayı	Kullanıcı veya yönetici korunan verilere/servislere erişim izni verdi mi?	Sürecin bu erişimi yalnızca hedeflenen iş akışı için kullandığını
XPC ve Service Management	Ayrı süreçler nasıl başlatılır ve birbirine nasıl bağlanır?	Dinleyicinin (listener) peer’ı doğruladığını veya her etkiyi yetkilendirdiğini
SIP ve platform korumaları	Hangi sistem konumları ve süreçleri işletim sistemi koruması altındadır?	Üçüncü taraf uygulama verilerinin, helper’ların ve protokollerin doğru olduğunu

Apple, App Sandbox’ı bir uygulamayı beyan ettiği yeteneklerle sınırlayan kernel düzeyinde zorunlu kılınan bir erişim kontrol teknolojisi olarak tanımlar. Amacı sınırlamadır (containment): Ele geçirilmiş bir kodun verebileceği zararı azaltır. App Sandbox dokümantasyonu, sandbox altındaki bir uygulamanın tasarımı gerektirdiğinde ayrı yapılandırılmış araçları ve servisleri kullanabileceğini açıkça belirtir.

Hardened Runtime, süreç bütünlüğünü kod enjeksiyonu, kütüphane yükleme ve bellek alanı manipülasyonu sınıflarına karşı korur. İstisnalar çalıştırılabilir dosyalar üzerindeki entitlement’lar ile ifade edilir. Dosya, gizlilik, IPC ve iş yetkilendirmesinden tamamen farklı bir sınırdır.

Bu ayrım yaygın bir raporlama hatasını önler: Platform korumalarını, varlıkları her saldırı yolunu kapatıyormuş gibi listelemek. Nitelikli bir inceleme, her kontrolün gerçekte neyi kısıtladığını kaydeder; ardından bileşenler arasında geçiş yapan yetkiyi arar.

Uygulama paketi çalıştırılabilir dosyaların bir grafiğidir

Apple’ın güncel XPC dokümantasyonu, üç kritik servis türünü tanımlar:

• Paket içi XPC servisi (bundled XPC service): İstemci başına bir süreçtir ve istemcinin yaşam döngüsünü takip eder;
• Launch agent: Oturum açmış kullanıcı için çalışır ve o kullanıcı oturumu içinde iletişim kurabilir;
• Launch daemon: Sistem genelindedir, oturum açılmadan önce başlayabilir ve root olarak çalışır.

Bunlar tamamen farklı güvenlik modelleridir. Aynı geliştirici tarafından imzalanmış iki binary bile farklı entitlement’lara ve erişim haklarına sahip olabilir. Yalnızca ana uygulamanın imzasını çıkaran bir inceleme, en kritik sistem etkisini yaratabilecek bileşenleri tamamen gözden kaçırır.

Bileşen ve yetki envanteriyle başlayın

Bir arayüzü test etmeden önce, uygulama paketini ve onunla ilişkili her kalıcı bileşeni envanterleyin. Müşteri tarafından sağlanan bir test Mac’inde, salt okunur inceleme standart platform araçlarıyla başlayabilir:

APP_PATH="/Applications/Example.app"

codesign -dvvv --entitlements :- "$APP_PATH"
find "$APP_PATH/Contents" -maxdepth 4 -type d \
  \( -name "XPCServices" -o -name "LoginItems" -o -name "LaunchAgents" \
  -o -name "LaunchDaemons" -o -name "SystemExtensions" \) -print

İmza ve entitlement denetimini yalnızca dış bundle için değil, her bir Mach-O çalıştırılabilir dosyası için tekrarlayın. Designated requirement, Team ID, imza tanımlayıcısı (signing identifier), Hardened Runtime durumu, sandbox entitlement’ı, App Groups, Keychain grupları, gizliliğe duyarlı entitlement’lar, runtime istisnaları ve kısıtlanmış framework entitlement’larını kaydedin.

Ardından bileşenin beyan edilen rolünü inceleyin:

plutil -p "$APP_PATH/Contents/Info.plist"
otool -L "$APP_PATH/Contents/MacOS/Example"

Başlatma ögeleri için ilgili property list’i, yürütülebilir dosya konumunu, etiketi, argümanları, çalışma dizinini, ortam değişkenlerini, kullanıcı bağlamını ve kayıt durumunu saklayın. macOS 13 ve sonrasında Service Management, uygulama paketinden login item, launch agent ve launch daemon bileşenlerini kaydetmek için resmi modeli sağlar. Bir helper’ın Contents/Library dizininde bulunması paketlemeyi ifade eder; servis yapılandırması ve çalışma zamanı kimliği ise yetkiyi tanımlar.

Kullanışlı bir envanter her çalıştırılabilir dosya için bir satır içerir:

Alan	Soru
Bundle içi yol	Bu çalıştırılabilir dosya nerede paketleniyor ve güncelleniyor?
Kod gereksinimi	Hangi imza tanımlayıcısını ve Team ID’yi karşılıyor?
Runtime kimliği	Hangi UID, oturum ve launch domain içinde çalışıyor?
Sandbox ve entitlement’lar	Bu çalıştırılabilir dosya için hangi platform kısıtlamaları ve istisnalar geçerli?
Kalıcılık (Persistence)	Uygulamaya bağlı, oturuma bağlı, talep üzerine mi yoksa sistem genelinde mi?
IPC isimleri ve arayüzler	Hangi XPC, Mach, soket, Apple Event, URL veya dosya arayüzleri ona ulaşıyor?
Kabul edilen arayanlar	Alıcı, peer kimliğini ve yetkilendirmesini nasıl belirliyor?
Ayrıcalıklı işlemler	Hangi dosyaları, süreçleri, ayarları, kimlik bilgilerini veya aygıtları etkileyebilir?
Girdi sahipliği	Hangi yollar, tanımlayıcılar, bookmark’lar, handle’lar çağrıcıdan geliyor?
Kanıt ve belirsizlik	Her özelliği ne kanıtlıyor ve ne varsayım olarak kalıyor?

Çıktı bir yetki grafiğidir. Kullanışlı çağrılabilir bir operasyonu olmayan bir root süreci; Full Disk Access iznine ve geniş bir mesajlaşma arayüzüne sahip bir kullanıcı sürecinden daha düşük riskli olabilir. UID yalnızca bir boyuttur, risk skorunun kendisi değildir.

Entitlement’lar yetenektir, iş yetkilendirmesi değildir

Entitlement’lar macOS’a bir çalıştırılabilir dosyanın hangi korunan yeteneği talep edebileceğini veya hangi istisnanın geçerli olduğunu söyler. Bu çalıştırılabilir dosyayı arayan her istemcinin o yeteneği alması gerektiğini söylemez.

Bir helper’ın korunan bir yapılandırma dosyasını güncelleyebildiğini varsayalım. İmzası ve entitlement’ı doğru olabilir. Sistem onu tam olarak tasarlandığı gibi başlatabilir. Helper yine de şu kararları vermek zorundadır:

1. Bu bağlantı onaylanmış bir istemci kimliğinden mi geliyor?
2. Bu istemcinin şu anda bu işlemi talep etmesine izin var mı?
3. Kullanıcı veya yönetici bu iş eylemini onaylıyor mu?
4. Başvurulan tüm yollar ve nesneler beklenen süjeye mi ait?
5. Helper nihai kaynağı güvenli bir şekilde açıp doğrulayacak mı?
6. Ortaya çıkan etki sınırlandırılmış, günlüğe kaydedilmiş ve geri alınabilir mi?

Entitlement “bu çalıştırılabilir dosya bu işlemi deneyebilir mi?” sorusunu yanıtlar. Servis metodu ise “bu arayan istemci bu spesifik etkiye neden olabilir mi?” sorusunu yanıtlar.

TCC ve sandbox sonuçlarının ayrı tutulmasının nedeni de budur. Kullanıcı onayı bir sürece korunan verilere erişim hakkı verebilir. App Sandbox dosya sistemi veya aygıt erişimini kısıtlayabilir. Ancak bu mekanizmaların hiçbiri bir XPC isteğinin anlamsal içeriğini otomatik olarak doğrulamaz veya zaten yetkilendirilmiş bir sürecin geniş kapsamlı bir operasyonu kötüye kullanmasını engellemez.

Önce peer’ı doğrulayın, sonra işlemi yetkilendirin

XPC istemci ve servise yapılandırılmış bir iletişim kanalı sağlar. Servis hâlâ bir çağrıcı politikasına ihtiyaç duyar. Bir süreç adı, PID, bundle yolu veya istemciden gelen bir tanımlayıcı kalıcı bir kod kimliği değildir.

Modern platform API’leri, bir XPC dinleyicisinin veya bağlantısının kod imzalama gereksinimlerini zorunlu kılmasını sağlar. Apple; xpc_listener_set_peer_requirement fonksiyonunun gelen iletileri bir eş kod imzalama gereksinimine karşı kontrol ettiğini ve bunu karşılamayan istekleri düşürdüğünü belirtir. Foundation kütüphanesindeki setCodeSigningRequirement metodu, NSXPCConnection için karşılık gelen eş gereksinim denetimini sunar. Bu doğrulama yapı taşlarını incelemek ve politika kararlarını gözlemlemek için interaktif macOS Code Requirement & Entitlement Evaluator aracını kullanabilirsiniz.

Peer kimliği ilk kapıdır; nihai güvenlik politikası değildir:

Sağlam bir karar zinciri şunları içerir:

1. Peer gereksinimi: Yalnızca belirlenmiş istemci kimliklerini ve beklenen imzalama ekibini kabul edin.
2. Bağlantı bağlamı: Kabul edilen bağlantıyı sunucu tarafından gözlemlenen değişmez bir kimliğe bağlayın.
3. Metod beyaz listesi (allowlist): Genel bir komut, yol veya selector yerine dar operasyonlar sunun.
4. Hak değerlendirmesi: Bu çağrıcının ve kullanıcı bağlamının bu işlemi talep edip edemeyeceğine karar verin.
5. Tiplendirilmiş argümanlar: Belirsiz tipleri, beklenmeyen anahtarları, aşırı boyutları ve geçersiz durumları reddedin.
6. Kaynak bağlama: Yalnızca metinsel yollara güvenmeden çağrıcı kontrollü referansları onaylanmış kaynaklara çözümleyin.
7. Etki kontrolü: Gerçek dosya, süreç, ayar veya sistem durumunun tam olarak hedeflendiği gibi değiştiğini teyit edin.
8. Denetim ve iptal: Çağrıcı kimliğini, işlemi, hedefi, sonucu ve politika kararını saklayın; uygulama, hesap veya yapılandırma değiştiğinde yetkileri geçersiz kılın.

Güvenlik niteliği zincirin tamamına aittir. Yalnızca tek bir kapıyı güçlendirmek, aynı etkinin başka bir arayüzden erişilebilir kalmasına neden olabilir.

Yol dizeleri (path strings) isteklerdir, kaynak değil

Ayrıcalıklı helper’lar sıklıkla dosya yolları alır; çünkü görünür uygulama bir dosya seçmiş, bir yedekleme oluşturmuş, bir güncelleme indirmiş veya bir yapılandırma değişikliği talep etmiştir. Servis, bu metin dizisini çağrıcının nihai nesneye sahip olduğunun kanıtı olarak görmemelidir.

Doğrulama ile kullanım arasında dosya sistemi durumu değişebilir (TOCTOU). Göreli yollar, sembolik linkler (symlinks), alias’lar, bağlama noktaları (mounts), hard link’ler ve dizin değiştirmeleri metinsel bir yolun neye çözümleneceğini değiştirebilir. Kullanışlı bir inceleme şunları sorar:

• Her yol bileşenini kim oluşturdu?
• Üst dizinlerin sahibi kimdir ve onları hangi süreç değiştirebilir?
• Doğrulama ve kullanım aynı açık nesneye mi (fd) hitap ediyor?
• Hedef, onaylanmış bir konteynerin veya ürün dizininin dışına taşabilir mi?
• Helper linkleri takip ediyor mu veya sahiplik ve izinleri değiştiriyor mu?
• Geçici dosyalar güvenli bir şekilde mi oluşturuluyor?
• Arşiv açma, güncelleme hazırlama veya geri yükleme işlemleri sabit bir hedefi koruyor mu?
• Kullanıcı onayıyla seçilen bir dosya, sonraki işlemler için genel geçer bir yeteneğe dönüşüyor mu?

En güvenli arayüz, işlemin ihtiyaç duyduğu en dar kaynak temsilini taşır. “Bu komutu çalıştır” veya “bu baytları bu rastgele yola yaz” yetkisi veren bir helper, kendi yetki modelini doğrudan çağrıcıya devretmiştir.

Mac’i bir hedefe dönüştürmeden sınırı değerlendirin

Bir ürün incelemesinde müşteriye ait özel bir test Mac’i, tek kullanımlık test hesapları, sentetik dosyalar ve geri alınabilir bir operasyon kümesi kullanılmalıdır. Statik ve gözlemsel kanıtlarla başlayın. Dinamik testler her seferinde tek bir değişkeni değiştirmelidir.

Test boyutu	Pozitif kontrol	Negatif kontrol
Peer kimliği	Onaylı imzalı test istemcisi bağlanır	Onaysız test istemcisi veya eşleşmeyen gereksinim reddedilir
Metod	Onaylı istemci belgelenmiş bir işlemi çağırır	Aynı istemci kullanılamayan veya yetkisiz bir işlemi çağırır
Kullanıcı hakkı	Yetkili test kullanıcısı izin verilen bir yönetimsel görevi yapar	Standart test kullanıcısı etki oluşmadan önce ret yanıtı alır
Kaynak sahipliği	Helper sentetik bir ürün dosyasını değiştirir	Onaylı kök dizin dışındaki çağrıcı kontrollü yol reddedilir
İş akışı durumu	Kayıtlı bileşen güncel bir işlemi yürütür	Kaldırılmış, devre dışı veya bayat bileşen eski yetkisini koruyamaz
Etki	Tam olarak beklenen bir değişiklik gerçekleşir ve loglanır	Reddedilen istek hiçbir dosya, süreç, ayar veya izin değişikliği yapmaz

Bir test gerçek kullanıcı verilerine, başka bir hesaba, prodüksiyon kimlik bilgilerine veya ürünün sahibi olmadığı bir sistem bileşenine dokunursa derhal durun. Sırf bir hipotezi göstermeyi kolaylaştırmak uğruna SIP’i devre dışı bırakmayın, TCC pencerelerini zorla atlamayın veya imzasız helper’lar yüklemeyin. Kanıt bir platform korumasını değiştirmeyi gerektiriyorsa testi yeniden çerçeveleyin veya laboratuvara özel açık bir karar alın.

Kurgusal bir XPC yetki incelemesi

HarborSync adlı bir ürünün sandbox altındaki bir grafik uygulamaya ve küçük bir yedekleme/geri yükleme işlemi kümesini yürüten bir launch daemon’a sahip olduğunu varsayalım. Daemon root olarak çalışır ve istekleri XPC üzerinden alır. Müşteri tek kullanımlık bir Mac, iki imzalı test istemcisi, sentetik yedekleme verisi ve ürüne ait bir hedef dizin sağlar.

1. Denetçi; arayüzü, paket içi XPC bileşenini, launch daemon’ı, güncelleyiciyi ve login item’ı envanterler. Her çalıştırılabilir dosya kendi imza, entitlement, UID, kalıcılık ve arayüz kaydını alır.
2. Grafik arayüz sandbox altındadır ve kullanıcı tarafından seçilen veriler için security-scoped erişim kullanır. Launch daemon’ın arayüzün kısıtlamalarını devraldığı varsayılmaz; root yetkisi ve XPC dinleyicisi ayrı haritalandırılır.
3. Onaylı istemciden sentetik ürün dizinine normal bir geri yükleme başarılı olur. Oluşturulan dosya, sahiplik, dosya modu, denetim olayı ve zaman damgası pozitif kontrolü kurar.
4. Aynı geliştirme ekibinden ikinci bir imzalı test istemcisi, dinleyicinin designated requirement şartını karşılamaz. İsteği geri yükleme metodu çalıştırılmadan önce reddedilir. Tek başına Team ID üyeliği ürünün çağrıcı politikası değildir.
5. Onaylı istemci, ürüne ait kök dizinin dışında bir geri yükleme talep eder. Daemon nihai hedefi çözümledikten sonra kaynağı reddeder. Hiçbir dosya veya geçici artık oluşmaz.
6. Müşteri sistem ayarlarından daemon’ın yetkisini kaldırır. Mevcut istemciler gizli ve uzun ömürlü bir yeteneği korumak yerine işlemi kaybeder.
7. Ancak temizleme (cleanup) metodunda kritik bir hata bulunur: Doğru peer’ı kabul eder; fakat silme işlemini aktif kullanıcının yedekleme kümesine bağlı olmayan, çağrıcı tarafından sağlanan bir yedekleme tanımlayıcısı üzerinden yetkilendirir. Sentetik laboratuvarda Kullanıcı A, Kullanıcı B’nin test yedeğinin silinmesini talep edebilmektedir.
8. Test, sınırı kanıtlayan tek bir geri alınabilir kayıttan sonra durdurulur. Bulgu bir sandbox kaçışı veya macOS platform arızası olarak değil; kimliği doğrulanmış bir XPC metodunun içindeki eksik nesne yetkilendirmesi olarak raporlanır.

Bu ayrım kritiktir. Uygulama sandbox altındaydı. Servis beklenen imzalı istemciyi kabul etti. Eksik olan karar yine yerel iş yetkilendirmesiydi: Bu kullanıcının hangi yedekleme nesnesini etkilemesine izin verildiği.

Kanıt matrisi

Gözlem veya sonuç	Neyi destekler	Neyi kanıtlayamaz	Gereken sonraki adım
Ana uygulama App Sandbox entitlement’ına sahip	Ana çalıştırılabilir dosya App Sandbox’a girer	Helper sandbox durumunu, TCC durumunu veya metod güvenliğini	Her çalıştırılabilir dosyayı ve çalışma bileşenini inceleyin
Paket noter onaylı ve Gatekeeper tarafından kabul ediliyor	Dağıtım ve başlatma kontrolleri başarılı	Mantık, IPC, güncelleme veya yetkilendirme açığı bulunmadığını	Çalışma zamanı sınırlarını ve ayrıcalıklı etkileri haritalandırın
Hardened Runtime etkindir	Varsayılan çalışma zamanı bütünlük kısıtlamaları geçerlidir	Hangi istisna entitlement’larının bileşeni zayıflattığını	Dosyaya özel bayrakları ve entitlement’ları inceleyin
XPC servisi uygulama içinde paketlenmiştir	Ayrı bir süreç ve arayüz ürünün parçasıdır	Peer gereksinimlerini, metod yetkisini veya girdi sahipliğini	Dinleyici politikasını ve operasyon kataloğunu çıkarın
Launch daemon root olarak çalışıyor	Bileşen sistem düzeyinde çalıştırma bağlamına sahiptir	Erişilebilirliği, sömürülebilir operasyonu veya çağrıcı yetkisini	Her arayüzü ve ortaya çıkan etkiyi haritalandırın
Dinleyici bir imzalama gereksinimi uyguluyor	Peer’ların bir kod kimliği politikasını karşılaması gerekir	Kabul edilen her peer’ın her metodu çağırabileceğini	İşlem ve nesne yetkilendirmesini test edin
İstemci PID’si veya süreç adı kontrol ediliyor	Geçici bir süreç özniteliği politikayı etkiler	Kararlı kod kimliğini veya yaşam döngüsü değişimlerine direnci	Mümkün olan yerlerde platform destekli kod gereksinimiyle değiştirin
Yol kullanılmadan önce kanonikleştiriliyor	Metinsel tek bir normalizasyon adımı gerçekleşmiştir	Nihai nesne kimliğini, link güvenliğini veya TOCTOU tutarlılığını	İşlemi çözümlenmiş onaylı bir kaynağa bağlayın
Yetkisiz istek hata dönüyor	Bir istek yolu ret bildirdi	Yan etkilerin, kısmi yazmaların veya kuyruğa giren işlerin yokluğunu	Dosya sistemi, süreç, yapılandırma ve denetim durumunu doğrulayın
Sentetik yasak etki gerçekleşmiyor	Test edilen negatif kontrol belirtilen kuralı korudu	Tüm çağrıcıları, metodları, kaynakları veya sürümleri	Körlemesine mesaj mutasyonu yerine yetki ve etkiye göre genişletin

Savunuculara ve geliştiricilere teslim edilecek çıktılar

Faydalı çıktı bir entitlement dökümü değildir; bileşen-etki modelidir:

Çalıştırılabilir dosya envanteri. Her uygulama, helper, XPC servisi, login item, agent, daemon, uzantı ve araç için kod gereksinimi, entitlement’lar, UID, launch domain, kalıcılık ve güncelleme ilişkisi.

Yetki haritası. Her bileşenin etkileyebileceği dosyalar, süreçler, kimlik bilgileri, korunan veriler, sistem ayarları, aygıtlar ve güvenlik olayları.

Arayüz kataloğu. XPC dinleyici adları, kamusal metodlar, argüman şemaları, hata davranışları, bağlantı ömrü, peer gereksinimleri ve alternatif arayüzler.

Karar matrisi. Kabul edilen istemci kimlikleri, metod hakları, kullanıcı bağlamı, kaynak sahipliği, iş akışı durumu, beklenen etkiler ve engellenen kontroller.

Yaşam döngüsü sonuçları. Kurulum, kayıt, yükseltme, devre dışı bırakma, çıkış, kullanıcı değiştirme, kaldırma ve bayat istemci davranışları. Kalıcı yetkinin görünür bir sahibi ve tanımlı bir iptal yolu olmalıdır.

İyileştirme sözleşmesi. Alıcı tarafında eklenecek veya daraltılacak tam karar, bileşen sahibi, minimum kod gereksinimi, izin verilen metodlar ve kaynaklar, etki düzeyinde loglama ve hem hedeflenen başarıyı hem de hedeflenen reddi kanıtlayan bir yeniden test planı.

Konu kontrol listeleriyle değil, yetkiyle başlar

macOS Güvenliği tutarlı bir rota izler:

1. App Sandbox ve XPC yetkisi: Bir sürecin diğerinden daha güçlü bir etki yaratmasını istediği yer.
2. TCC ve onay sınırları: Kullanıcı onaylı erişimin nasıl kalıcı bir uygulama yeteneğine dönüştüğü.
3. Başlatma servisleri ve kalıcılık: Login item’ların, agent’ların, daemon’ların ve güncellemelerin yaşam döngüsü boyunca nasıl hayatta kaldığı.
4. Endpoint Security ve gözlemlenebilirlik: Savunucuların süreç, dosya, mount ve yetkilendirme olayları hakkında telemetriyi engelleme ile karıştırmadan neleri kanıtlayabileceği.

Platform halihazırda güçlü yapı taşları sunar: imzalama gereksinimleri, entitlement’lar, sandbox’lar, Hardened Runtime, kullanıcı onayı, Service Management ve yapılandırılmış IPC. Güvenlik incelemesi, ürünün bu yapı taşlarını hedeflenen yetki modeline dönüştürüp dönüştürmediğini sorgular.

Uygulama penceresi yalnızca görünen bileşendir. Asıl sınır; belirli bir çağrıcı, metod, kaynak ve durumun gerçek bir sistem etkisine dönüştüğü andır.

MITRE ATT&CK eşleştirmesi

Taktik	Teknik ID	Teknik Adı	Doğrulama sinyali
Execution	T1559.003	Inter-Process Communication: XPC Services	launchctl print gui/$UID/<service> bağlantı denetimi
Privilege Escalation	T1548	Abuse Elevation Control Mechanism	Alıcı helper’a karşı arayanın kod gereksinimini denetleyin
Defense Evasion	T1553.001	Subvert Trust Controls: Code Signing	Eş codesign -dvvv ve Team ID sınırını kontrol edin

Kaynaklar ve güncellik

Bu teknik not ne kadar güncel?

Kontrol edilen kaynaklar29 Ağustos 2026

En son kaynak incelemesi, içerik güncellemesi veya yayın tarihi gösterilmektedir.

İnceleme DurumuKamuya açık kaynaklar incelendi

Birincil kamu kayıtları kontrol edildi. Ortama özgü davranış, ayrıca yeniden üretilmedikçe iddianın dışındadır.

Birincil referanslar

• developer.apple.com · protecting-u…th-app-sandbox ↗
• developer.apple.com · hardened-runtime ↗
• developer.apple.com · xpc ↗
• developer.apple.com · xpc_listener…er_requirement ↗
• developer.apple.com · setcodesigni…equirement(_:) ↗
• developer.apple.com · servicemanagement ↗
• support.apple.com · web ↗
• theevilbit.github.io · secure_coding_xpc_part5 ↗
• knight.sc · audit-tokens-explained ↗