27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Uygulama Korumalı Alanı
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Android platformu, uygulama kaynaklarını tanımlamak ve izole etmek için Linux'un kullanıcıya dayalı korumasından yararlanır. Bu sayede uygulamalar birbirinden izole edilir ve hem uygulamalar hem de sistem kötü amaçlı uygulamalardan korunur. Android bunu yapmak için her Android uygulamasına benzersiz bir kullanıcı kimliği (UID) atar ve uygulamayı kendi işleminde çalıştırır.
Android, çekirdek düzeyinde bir uygulama korumalı alanı oluşturmak için UID'yi kullanır. Çekirdek, uygulamalara atanan kullanıcı ve grup kimlikleri gibi standart Linux araçları aracılığıyla uygulamalar ile sistem arasındaki güvenliği işlem düzeyinde zorlar. Varsayılan olarak uygulamalar birbirleriyle etkileşime geçemez ve işletim sistemine sınırlı erişime sahiptir. A uygulaması, B uygulamasının verilerini okumak veya telefon araması yapmak gibi kötü amaçlı bir işlem yapmaya çalışırsa uygun varsayılan kullanıcı ayrıcalıklarına sahip olmadığı için bu işlem yapması engellenir. Korumalı alan basit, denetlenebilirdir ve on yıllardır kullanılan UNIX tarzı kullanıcı ayırma işlemlerine ve dosya izinlerine dayanır.
Uygulama Korumalı Alanı çekirdekte bulunduğundan bu güvenlik modeli hem yerel koda hem de işletim sistemi uygulamalarına uygulanır. İşletim sistemi kitaplıkları, uygulama çerçevesi, uygulama çalışma zamanı ve tüm uygulamalar gibi çekirdeğin üzerindeki tüm yazılımlar, uygulama korumalı alanında çalışır. Bazı platformlarda geliştiriciler belirli bir geliştirme çerçevesi, API grubu veya dil ile sınırlıdır. Android'de, güvenliğin uygulanması için bir uygulamanın nasıl yazılabileceğiyle ilgili herhangi bir kısıtlama yoktur. Bu açıdan yerel kod, yorumlanmış kod kadar korumalı bir alandadır.
Korumalar
Genellikle, düzgün şekilde yapılandırılmış bir cihazda Uygulama Korumalı Alanı'ndan çıkmak için Linux çekirdeğinin güvenliğinin ihlal edilmesi gerekir. Ancak diğer güvenlik özelliklerine benzer şekilde, uygulama korumalı alanını zorunlu kılan bireysel korumalar saldırılara karşı bağışık değildir. Bu nedenle, tek bir güvenlik açığının işletim sisteminin veya diğer uygulamaların güvenliğini ihlal etmesini önlemek için kapsamlı savunma önemlidir.
Android, uygulama korumalı alanını zorunlu kılmak için çeşitli korumalardan yararlanır. Bu yaptırımlar zaman içinde kullanıma sunuldu ve orijinal UID tabanlı isteğe bağlı erişim denetimi (DAC) korumalı alanını önemli ölçüde güçlendirdi. Önceki Android sürümleri aşağıdaki korumaları içeriyordu:
- Android 5.0'de SELinux, sistem ile uygulamalar arasında zorunlu erişim denetimi (MAC) ayrımı sağlıyordu. Ancak tüm üçüncü taraf uygulamaları aynı SELinux bağlamında çalıştığından uygulama içi izolasyon öncelikle UID DAC tarafından zorunlu kılınıyordu.
- Android 6.0'ta SELinux korumalı alanı, uygulamaları fiziksel kullanıcı başına sınırda izole edecek şekilde genişletildi. Ayrıca Android, uygulama verileri için daha güvenli varsayılan değerler de belirledi:
targetSdkVersion >= 24 içeren uygulamalarda, uygulamanın ana dizinindeki varsayılan DAC izinleri 751'den 700'e değiştirildi. Bu, gizli uygulama verileri için daha güvenli bir varsayılan ayar sağladı (uygulamalar bu varsayılan ayarları geçersiz kılabilse de).
- Android 8.0'da tüm uygulamalar, uygulamaların kullanmasına izin verilen sistem çağrılarını sınırlayan bir
seccomp-bpf
filtresiyle çalışacak şekilde ayarlandı. Böylece uygulama/çekirdek sınırı güçlendirildi.
- Android 9'da
targetSdkVersion >=
28 içeren ayrıcalıklı olmayan tüm uygulamalar, uygulama başına MAC sağlayarak ayrı SELinux korumalı alanlarında çalışmalıdır. Bu koruma, uygulama ayırımını iyileştirir, güvenli varsayılan değerlerin geçersiz kılınmasını önler ve (en önemlisi) uygulamaların verilerini dünya genelinde erişilebilir hale getirmesini engeller.
- Android 10'da uygulamalar, dosya sisteminin sınırlı bir ham görünümüne sahiptir ve /sdcard/DCIM gibi yollara doğrudan erişemez. Ancak uygulamalar, Context.getExternalFilesDir() gibi geçerli yöntemler tarafından döndürülen pakete özgü yollarına tam ham erişim elde eder.
Dosya paylaşma kuralları
Uygulama verilerini herkese açık olarak ayarlamak kötü bir güvenlik uygulamasıdır. Erişim herkese verilir ve erişimi yalnızca amaçlanan alıcılarla sınırlamak mümkün değildir. Bu uygulama, bilgi açıklama sızıntılarına ve kafa karıştırıcı yardımcı güvenlik açıklarına yol açmıştır. Ayrıca, hassas verileri olan uygulamaları (e-posta istemcileri gibi) hedefleyen kötü amaçlı yazılımlar için favori bir hedeftir. Android 9 ve sonraki sürümlerde, targetSdkVersion>=28 izni olan uygulamalarda bu şekilde dosya paylaşımına açıkça izin verilmez.
Uygulama verilerini dünya genelinde erişilebilir hale getirmek yerine, dosya paylaşırken aşağıdaki yönergeleri kullanın:
- Uygulamanızın başka bir uygulamayla dosya paylaşması gerekiyorsa
bir içerik sağlayıcı kullanın. İçerik sağlayıcılar, verileri herkese açık UNIX izinlerinin birçok olumsuz yönünü ortadan kaldırarak uygun ayrıntı düzeyinde paylaşır (ayrıntılar için
İçerik sağlayıcılarla ilgili temel bilgiler başlıklı makaleyi inceleyin).
- Uygulamanızda herkese açık olması gereken dosyalar (ör. fotoğraflar) varsa bu dosyalar medyaya özgü olmalı (yalnızca fotoğraflar, videolar ve ses dosyaları) ve
MediaStore sınıfı kullanılarak depolanmalıdır. (Medya öğesi ekleme hakkında daha fazla bilgi için
Paylaşılan depolama alanından medya dosyalarına erişme başlıklı makaleyi inceleyin.)
Depolama çalışma zamanındaki izni, MediaStore aracılığıyla güçlü şekilde yazılmış koleksiyonlara erişimi kontrol eder.
PDF'ler ve MediaStore.Downloads sınıfı gibi zayıf türülendirilmiş dosyalara erişmek için uygulamaların ACTION_OPEN_DOCUMENT intent'i gibi intent'leri kullanması gerekir.
Android 10 davranışını etkinleştirmek için requestLegacyExternalStorage manifest özelliğini kullanın ve uygulama izinleriyle ilgili en iyi uygulamaları uygulayın.
- Android 9 ve önceki sürümleri hedefleyen uygulamalar için manifest işaretinin varsayılan değeri
true'tür.
- Android 10'u hedefleyen uygulamalar için varsayılan değer false (yanlış) değerini alır. Android 10'u hedefleyen uygulamalarda filtrelenmiş depolama görünümünü geçici olarak devre dışı bırakmak için manifest işaretinin değerini
true olarak ayarlayın.
- Yükleyici, kısıtlanmış izinleri kullanarak korumalı olmayan depolama için izin verilen uygulamaları izin verilenler listesine ekler. İzin verilenler listesine eklenmeyen uygulamalar korumalı alana alınır.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 2025-07-27 UTC."],[],[],null,["# Application Sandbox\n\nThe Android platform takes advantage of the Linux user-based protection to\nidentify and isolate app resources. This isolates apps from each other and\nprotects apps and the system from malicious apps. To do this, Android assigns a\nunique user ID (UID) to each Android app and runs it in its own\nprocess.\n\nAndroid uses the UID to set up a kernel-level Application Sandbox. The\nkernel enforces security between apps and the system at the process level\nthrough standard Linux facilities such as user and group IDs that are assigned\nto apps. By default, apps can't interact with each other and have limited\naccess to the OS. If app A tries to do something malicious, such as read\napp B's data or dial the phone without permission, it's prevented from\ndoing so because it doesn't have the appropriate default user privileges. The\nsandbox is simple, auditable, and based on decades-old UNIX-style user\nseparation of processes and file permissions.\n\nBecause the Application Sandbox is in the kernel, this security model\nextends to both native code and OS apps. All of the software above the\nkernel, such as OS libraries, app framework, app runtime, and\nall apps, run within the Application Sandbox. On some platforms,\ndevelopers are constrained to a specific development framework, set of APIs, or\nlanguage. On Android, there are no restrictions on how an app can be\nwritten that are required to enforce security; in this respect, native code is\nas sandboxed as interpreted code.\n\nProtections\n-----------\n\n\nGenerally, to break out of the Application Sandbox in a properly configured\ndevice, one must compromise the security of the Linux kernel. However, similar\nto other security features, individual protections enforcing the app\nsandbox are not invulnerable, so defense-in-depth is important to prevent\nsingle vulnerabilities from leading to compromise of the OS or other apps.\n\n\nAndroid relies on a number of protections to enforce the app\nsandbox. These enforcements have been introduced over time and have\nsignificantly strengthened the original UID-based discretionary access control\n(DAC) sandbox. Previous Android releases included the following\nprotections:\n\n- In Android 5.0, SELinux provided mandatory access control (MAC) separation between the system and apps. However, all third-party apps ran within the same SELinux context so inter-app isolation was primarily enforced by UID DAC.\n- In Android 6.0, the SELinux sandbox was extended to isolate apps across the per-physical-user boundary. In addition, Android also set safer defaults for app data: For apps with `targetSdkVersion \u003e= 24`, default DAC permissions on an app's home dir changed from 751 to 700. This provided safer default for private app data (although apps can override these defaults).\n- In Android 8.0, all apps were set to run with a `seccomp-bpf` filter that limited the syscalls that apps were allowed to use, thus strengthening the app/kernel boundary.\n- In Android 9 all nonprivileged apps with `targetSdkVersion \u003e=\n 28` must run in individual SELinux sandboxes, providing MAC on a per-app basis. This protection improves app separation, prevents overriding safe defaults, and (most significantly) prevents apps from making their data world accessible.\n- In Android 10 apps have a limited raw view of the filesystem, with no direct access to paths like /sdcard/DCIM. However, apps retain full raw access to their package-specific paths, as returned by any applicable methods, such as [Context.getExternalFilesDir()](https://developer.android.com/reference/android/content/Context.html#getExternalFilesDir(jav%20a.lang.String)).\n\nGuidelines for sharing files\n----------------------------\n\nSetting app data as world accessible is a poor security practice. Access\nis granted to everyone and it's not possible to limit access to only the intended\nrecipient(s). This practice has led to information disclosure leaks and confused\ndeputy vulnerabilities, and is a favorite target for malware that targets apps\nwith sensitive data (such as email clients). In Android 9 and higher, sharing\nfiles this way is explicitly disallowed for apps with\n`targetSdkVersion\u003e=28`.\n\n\nInstead of making app data world-accessible, use the following guidelines\nwhen sharing files:\n\n- If your app needs to share files with another app, use a [content provider](https://developer.android.com/guide/topics/providers/content-provider-basics.html). Content providers share data with the proper granularity and without the many downsides of world-accessible UNIX permissions (for details, refer to [Content provider basics](https://developer.android.com/guide/topics/providers/content-provider-basics.html)).\n- If your app has files that genuinely should be accessible to the world (such as photos), they must be media-specific (photos, videos, and audio files only) and stored using the [MediaStore](https://developer.android.com/reference/android/provider/MediaStore) class. (For more details on how to add a media item, see [Access media files from shared storage](https://developer.android.com/training/data-storage/shared/media#add-item).)\n\nThe **Storage** runtime permission controls access\nto strongly-typed collections through **MediaStore** .\nFor accessing weakly typed files such as PDFs and the [MediaStore.Downloads](https://developer.android.com/reference/android/provider/MediaStore.Downloads) class, apps must use\nintents like the [`ACTION_OPEN_DOCUMENT`](https://developer.android.com/reference/android/content/Intent.html#ACTION_OPEN_DOCUMENT) intent.\n\nTo enable Android 10 behavior, use the\n[requestLegacyExternalStorage](https://developer.android.com/training/data-storage/files/external-scoped#opt-out-of-%20filtered-view) manifest\nattribute, and follow [App permissions best practices](https://developer.android.com/training/permissions/usage-notes).\n\n- The manifest flag default value is `true` for apps targeting Android 9 and lower.\n- The default value is false for apps targeting Android 10. To temporarily opt out of the filtered storage view in apps targeting Android 10, set the manifest flag's value to `true`.\n- Using restricted permissions, the installer allowlists apps permitted for nonsandboxed storage. Nonallowlisted apps are sandboxed."]]
