Politika uyumluluğu

Bu makalede, Android'in platform OTA'larıyla ilgili politika uyumluluğu sorunlarını nasıl ele aldığı açıklanmaktadır. Bu sorunlarda yeni platform SELinux ayarları eski tedarikçi SELinux ayarlarından farklı olabilir.

Üçlülere dayalı SELinux politika tasarımı, platform ve tedarikçi politikası arasında ikili bir ayrım göz önünde bulundurur; tedarikçi bölümleri platform < vendor < oem gibi bağımlılıklar oluşturursa şema daha karmaşık hale gelir.

Android 8.0 ve sonraki sürümlerde SELinux genel politikası özel ve herkese açık bileşenlere ayrılmıştır. Herkese açık bileşenler, politikadan ve platform sürümünde kullanılabileceği garanti edilen ilişkili altyapıdan oluşur. Bu politika, tedarikçi firmaların tedarikçi firma politikası dosyası oluşturmasını sağlamak için tedarikçi firma politikası yazarlarına gösterilir. Bu dosya, platform tarafından sağlanan politikayla birleştirildiğinde cihaz için tam işlevli bir politika oluşturur.

  • Sürüm oluşturma için dışa aktarılan herkese açık platform politikası özellikler olarak yazılır.
  • Politika yazmanın kolaylaştırılması için dışa aktarılan türler, politika oluşturma sürecinin bir parçası olarak sürümlü özelliklere dönüştürülür. Herkese açık türler, tedarikçi bağlam dosyaları tarafından sağlanan etiketleme kararlarında da doğrudan kullanılabilir.

Android, platform politikasında dışa aktarılan somut türler ile her platform sürümü için ilgili sürümlü özellikler arasında bir eşleme sağlar. Bu sayede, nesneler bir türle etiketlendiğinde önceki bir sürümdeki platform herkese açık politikası tarafından garanti edilen davranışın ihlal edilmemesi sağlanır. Bu eşleme, her platform sürümü için güncel bir eşleme dosyası tutularak sürdürülür. Bu dosya, herkese açık politikaya aktarılan her tür için özellik üyeliği bilgilerini tutar.

Nesne sahipliği ve etiketleme

Android 8.0 ve sonraki sürümlerde politika özelleştirilirken platform ve tedarikçi politikasının ayrı kalması için her nesnenin sahipliği açıkça tanımlanmalıdır. Örneğin, tedarikçi /dev/foo etiketini atar ve platform daha sonra bir OTA'da /dev/foo etiketini atarsa tanımlanmamış bir davranış ortaya çıkar. SELinux için bu durum, etiketleme çakışması olarak kendini gösterir. Cihaz düğümünde yalnızca en son uygulanan etikete yönlendiren tek bir etiket bulunabilir. Sonuç olarak:

  • Başarısız bir şekilde uygulanan etikete erişimi olan işlemler kaynağa erişimi kaybeder.
  • Yanlış cihaz düğümü oluşturulduğu için dosyaya erişim sağlayan işlemler bozulabilir.

Sistem özellikleri, sistemde (ve SELinux etiketlemede) tanımlanmamış davranışlara neden olabilecek ad çakışmaları da oluşturabilir. Mülkler, hizmetler, işlemler, dosyalar ve soketler dahil olmak üzere SELinux etiketi olan tüm nesnelerde platform ve tedarikçi etiketleri çakışabilir. Bu tür sorunları önlemek için bu nesnelerin sahipliğini açıkça tanımlayın.

Etiket çakışmasına ek olarak SELinux türü/özellik adları da çakışabilir. Tür/özellik adı çakışması her zaman politika derleyici hatasına neden olur.

Tür/özellik adlandırma alanı

SELinux, aynı tür/özelliğin birden fazla kez beyan edilmesine izin vermez. Yinelenen beyanlar içeren politikalar derlenemez. Tür ve özellik adı çakışmalarını önlemek için tüm tedarikçi beyanları vendor_ ile başlayan bir ad alanında olmalıdır. 

type foo, domain; → type vendor_foo, domain;

Sistem mülkü ve süreç etiketleme sahipliği

Etiket çakışmalarını önlemenin en iyi yolu, mülk ad alanlarını kullanmaktır. Platform mülklerini kolayca tanımlamak ve dışa aktarılan platform mülklerinin adını değiştirirken veya eklerken ad çakışmalarını önlemek için tüm tedarikçi mülklerinin kendi ön eklerine sahip olduğundan emin olun:

Tesis türü Kabul edilen ön ekler
kontrol özellikleri ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
read-writable vendor.
salt okunur ro.vendor.
ro.boot.
ro.hardware.
kalıcı persist.vendor.

Tedarikçiler ro.boot.* (kernel cmdline'den gelir) ve ro.hardware.* (donanımla ilgili açık bir özellik) özelliklerini kullanmaya devam edebilir.

init rc dosyalarındaki tüm tedarikçi firma hizmetlerinde, sistem dışı bölümlerdeki init rc dosyalarındaki hizmetler için vendor. olmalıdır. Tedarikçi mülkleri için SELinux etiketlerine benzer kurallar uygulanır (tedarikçi mülkleri için vendor_).

Dosya sahipliği

Platform ve tedarikçi politikası genellikle tüm dosya sistemleri için etiketler sağladığından, dosya çakışmalarını önlemek zordur. Tür adlandırmanın aksine, dosyaların çoğu çekirdek tarafından oluşturulduğundan dosyaların ad alanını ayırmak pratik değildir. Bu çakışmaları önlemek için bu bölümdeki dosya sistemleri için adlandırma yönergelerini uygulayın. Android 8.0 için bunlar teknik yaptırım içermeyen önerilerdir. Bu öneriler gelecekte Satıcı Testi Paketi (VTS) tarafından zorunlu kılınacaktır.

Sistem (/system)

Yalnızca sistem resmi, file_contexts, service_contexts vb. aracılığıyla /system bileşenleri için etiket sağlamalıdır. /system bileşenleri için etiketler /vendor politikasına eklenirse yalnızca çerçeveyle OTA güncellemesi yapılamayabilir.

Tedarikçi firma (/vendor)

AOSP SELinux politikası, platformun etkileşimde bulunduğu vendor bölümünün bölümlerini zaten etiketler. Bu, platform işlemlerinin vendor bölümünün bölümleriyle iletişim kurabilmesi ve/veya bu bölümlere erişebilmesi için SELinux kurallarının yazılmasını sağlar. Örnekler:

/vendor yolu Platform tarafından sağlanan etiket Etikete bağlı platform işlemleri
/vendor(/.*)? vendor_file Çerçevedeki tüm HAL istemcileri, ueventd vb.
/vendor/framework(/.*)? vendor_framework_file dex2oat, appdomain vb.
/vendor/app(/.*)? vendor_app_file dex2oat, installd, idmap vb.
/vendor/overlay(/.*) vendor_overlay_file system_server, zygote, idmap vb.

Sonuç olarak, vendor bölümünde ek dosyalar etiketlenirken belirli kurallara uyulmalıdır (neverallows aracılığıyla zorunlu kılınmıştır):

  • vendor_file , vendor bölümündeki tüm dosyalar için varsayılan etiket olmalıdır. Platform politikası, aktarma HAL uygulamalarında erişmek için bunu gerektirir.
  • Satıcı SEPolicy aracılığıyla vendor bölümüne eklenen tüm yeni exec_types öğelerinin vendor_file_type özelliği olmalıdır. Bu, neverallows aracılığıyla zorunlu kılınmıştır.
  • Gelecekteki platform/çerçeve güncellemeleriyle çakışmaları önlemek için vendor bölümünde exec_types dışındaki dosyaları etiketlemekten kaçının.
  • AOSP tarafından tanımlanan aynı işlem HAL'leri için tüm kitaplık bağımlılıkları same_process_hal_file. olarak etiketlenmelidir

Procfs (/proc)

/proc içindeki dosyalar yalnızca genfscon etiketi kullanılarak etiketlenebilir. Android 7.0'da hem platform hem de tedarikçi politikası, procfs içindeki dosyaları etiketlemek için genfscon'i kullandı.

Öneri: Yalnızca platform politikası etiketleri /proc. vendor işlemlerinin, /proc içindeki şu anda varsayılan etiketle (proc) etiketlenmiş dosyalara erişmesi gerekiyorsa tedarikçi politikası bunları açıkça etiketlememeli, bunun yerine tedarikçi alanları için kurallar eklemek üzere genel proc türünü kullanmalıdır. Bu sayede platform güncellemeleri, procfs üzerinden sunulan gelecekteki çekirdek arayüzlerini barındırabilir ve gerektiğinde bunları açıkça etiketleyebilir.

Debugfs (/sys/kernel/debug)

Debugfs hem file_contexts hem de genfscon içinde etiketlenebilir. Android 7.0 ile Android 10 arasında hem platform hem de tedarikçi etiketi debugfs olur.

Android 11'de debugfs, üretim cihazlarına erişilemez veya bu cihazlara monte edilemez. Cihaz üreticileri debugfs'yi kaldırmalıdır.

Tracefs (/sys/kernel/debug/tracing)

Tracefs hem file_contexts hem de genfscon içinde etiketlenebilir. Android 7.0'da yalnızca platform etiketleri gösterilirtracefs.

Öneri: tracefs yalnızca platform tarafından etiketlenebilir.

Sysfs (/sys)

/sys içindeki dosyalar hem file_contexts hem de genfscon kullanılarak etiketlenebilir. Android 7.0'da hem platform hem de tedarikçi firma, sysfs içindeki dosyaları etiketlemek için genfscon kullanır.

Öneri: Platform, cihaza özel olmayan sysfs düğümlerini etiketleyebilir. Aksi takdirde, dosyaları yalnızca tedarikçi firma etiketleyebilir.

tmpfs (/dev)

/dev klasöründeki dosyalar file_contexts klasöründe etiketlenebilir. Android 7.0'da hem platform hem de tedarikçi etiketi dosyaları buradadır.

Öneri: Tedarikçi yalnızca /dev/vendor biçimindeki dosyaları (örneğin, /dev/vendor/foo, /dev/vendor/socket/bar) etiketleyebilir.

Rootfs (/)

/ klasöründeki dosyalar file_contexts klasöründe etiketlenebilir. Android 7.0'da hem platform hem de tedarikçi firma etiketi dosyaları buradadır.

Öneri: / içindeki dosyaları yalnızca sistem etiketleyebilir.

Veriler (/data)

Veriler, file_contexts ve seapp_contexts kombinasyonuyla etiketlenir.

Öneri: /data/vendor dışında tedarikçi firma etiketlemesine izin vermeyin. Yalnızca platform, /data'ün diğer bölümlerini etiketleyebilir.

Genfs etiketi sürümü

202504 tedarikçi API düzeyinden itibaren, system/sepolicy/compat/plat_sepolicy_genfs_{ver}.cil içinde genfscon ile atanan daha yeni SELinux etiketleri eski tedarikçi bölümlerinde isteğe bağlıdır. Bu sayede eski tedarikçi firma bölümleri mevcut SEPolicy uygulamalarını koruyabilir. Bu, /vendor/etc/selinux/genfs_labels_version.txt içinde depolanan Makefile değişkeni BOARD_GENFS_LABELS_VERSION tarafından kontrol edilir.

Örnek:

  • Tedarikçi API düzeyi 202404'te /sys/class/udc düğümü varsayılan olarak sysfs olarak etiketlenir.
  • Tedarikçi API düzeyi 202504'ten itibaren /sys/class/udc, sysfs_udc olarak etiketlenir.

Ancak /sys/class/udc, API düzeyi 202404'ü kullanan tedarikçi firma bölümleri tarafından varsayılan sysfs etiketiyle veya tedarikçi firmaya özgü bir etiketle kullanılıyor olabilir. /sys/class/udc'ü koşulsuz olarak sysfs_udc olarak etiketlemek bu tedarikçi firma bölümleriyle uyumluluğu bozabilir. BOARD_GENFS_LABELS_VERSION işaretlendiğinde platform, eski tedarikçi firma bölümlerinde önceki etiketleri ve izinleri kullanmaya devam eder.

BOARD_GENFS_LABELS_VERSION, tedarikçi API seviyesinden büyük veya eşit olabilir. Örneğin, API düzeyi 202404 kullanan tedarikçi firma bölümleri, 202504'te kullanıma sunulan yeni etiketleri kullanmak için BOARD_GENFS_LABELS_VERSION değerini 202504 olarak ayarlayabilir. 202504'e özgü genfs etiketlerinin listesini inceleyin.

Platform, genfscon düğümlerini etiketlerken eski tedarikçi firma bölümlerini dikkate almalı ve gerektiğinde uyumluluk için yedek mekanizmalar uygulamalıdır. Platform, genfs etiketi sürümünü sorgulamak için yalnızca platform kitaplıklarını kullanabilir.

Uyumluluk özellikleri

SELinux politikası, belirli nesne sınıfları ve izinler için kaynak ve hedef türleri arasındaki bir etkileşimdir. SELinux politikasından etkilenen her nesnenin (işlemler, dosyalar vb.) yalnızca bir türü olabilir ancak bu türün birden fazla özelliği olabilir.

Politika çoğunlukla mevcut türlerle ilgili olarak yazılır: 

allow source_type target_type:target_class permission(s);

Bu, politikanın tüm türleri göz önünde bulundurularak yazılmış olmasından kaynaklanır. Ancak tedarikçi politikası ve platform politikası belirli türleri kullanıyorsa ve belirli bir nesnenin etiketi bu politikalardan yalnızca birinde değişirse diğerinde, daha önce güvenilen erişimi kazanan veya kaybeden politika bulunabilir. Örnek: 

File_contexts:
/sys/A   u:object_r:sysfs:s0
Platform: allow p_domain sysfs:class perm;
Vendor: allow v_domain sysfs:class perm;

Şu şekilde değiştirilebilir: 

File_contexts:
/sys/A   u:object_r:sysfs_A:s0

Tedarikçi firma politikası aynı kalsa da yeni sysfs_A türü için politika olmadığından v_domain erişimi kaybeder.

Bir politikayı özellikler açısından tanımlayarak temel nesneye hem platform hem de tedarikçi kodu için politikaya karşılık gelen bir özelliğe sahip bir tür atayabiliriz. Somut türlerin hiçbir zaman kullanılmadığı etkili bir özellik politikası oluşturmak için tüm türler için bu işlem yapılabilir. Uygulamada bu, yalnızca platform ile tedarikçi arasında örtüşen politika bölümleri için gereklidir. Bu bölümler, tedarikçi politikasının bir parçası olarak oluşturulan platform herkese açık politikası olarak tanımlanır ve sağlanır.

Herkese açık politikayı sürümlü özellikler olarak tanımlamak, iki politika uyumluluğu hedefini karşılar:

  • Tedarikçi kodunu platform güncellemesinden sonra çalışmaya devam ettirin. Tedarikçi koduna dayanan nesnelere karşılık gelen nesneler için somut türlere özellik ekleyerek erişimi koruyarak elde edilir.
  • Politikanın desteğini sonlandırma imkanı. Politika gruplarının, karşılık gelen sürüm artık desteklenmediği anda kaldırılabilecek özelliklere net bir şekilde ayrılmasıyla elde edilir. Eski politikanın tedarikçi politikasında hâlâ mevcut olduğunu ve yükseltme yapıldığında/yapıldığında otomatik olarak kaldırılacağını bilerek platformda geliştirmeye devam edilebilir.

Politika yazılabilirliği

Politika geliştirme için belirli sürüm değişiklikleri hakkında bilgi sahibi olma zorunluluğunu ortadan kaldırmak amacıyla Android 8.0, platformda herkese açık politika türleri ile bunların özellikleri arasında bir eşleme içerir. foo türü, foo_vN özelliğiyle eşlenir. Burada N, hedeflenen sürümdür. vN, PLATFORM_SEPOLICY_VERSION derleme değişkenine karşılık gelir ve MM.NN biçimindedir. Burada MM, platform SDK numarasına karşılık gelir ve NN, platform güvenlik politikasına özel bir sürümdür.

Herkese açık politikadaki özellikler sürümlere sahip değildir. Bunun yerine, platform ve tedarikçi politikasının iki bölüm arasındaki arayüzü sabit tutmak için derleyebileceği bir API olarak bulunur. Hem platform hem de tedarikçi firma politika yazarları, politikaları şu anda yazıldığı şekilde yazmaya devam edebilir.

allow source_foo target_bar:class perm; olarak dışa aktarılan platform herkese açık politikası, tedarikçi politikasının bir parçası olarak dahil edilir. Derleme sırasında (ilgili sürümü içerir) cihazın tedarikçi bölümüne gidecek politikaya dönüştürülür (dönüştürülmüş Ortak Ara Dil (CIL) ile gösterilir): 

 (allow source_foo_vN target_bar_vN (class (perm)))

Tedarikçi politikası hiçbir zaman platformdan önce olmadığından önceki sürümlerle ilgili endişelenmenize gerek yoktur. Ancak platform politikasının, tedarikçi politikasının ne kadar geriye gittiğini bilmesi, türlerine özellikler eklemesi ve sürüm özellikli özelliklere karşılık gelen politikayı ayarlaması gerekir.

Politika karşılaştırmaları

Her türün sonuna _vN ekleyerek otomatik olarak özellik oluşturmak, özellik türlerinin sürüm farklılıkları arasında eşlenmemesi durumunda hiçbir işe yaramaz. Android, özellikler için sürümler ve türlerin bu özelliklerle eşlenmesi arasında bir eşleme sağlar. Bu işlem, yukarıda belirtilen eşleme dosyalarında (CIL) aşağıdaki gibi ifadelerle yapılır: 

(typeattributeset foo_vN (foo))

Platform yükseltmeleri

Aşağıdaki bölümde, platform yükseltmeleriyle ilgili senaryolar ayrıntılı olarak açıklanmıştır.

Aynı türler

Bu senaryo, bir nesne politika sürümlerindeki etiketleri değiştirmediğinde ortaya çıkar. Bu durum, kaynak ve hedef türler için aynıdır ve tüm sürümlerde binder_device olarak etiketlenen /dev/binder ile görülebilir. Dönüştürülmüş politikada şu şekilde gösterilir: 

binder_device_v1 … binder_device_vN

v1 → v2 yükseltme işleminde platform politikası şunları içermelidir: 

type binder_device; -> (type binder_device) (in CIL)

1. sürüm eşleme dosyasında (CIL): 

(typeattributeset binder_device_v1 (binder_device))

v2 eşleme dosyasında (CIL): 

(typeattributeset binder_device_v2 (binder_device))

v1 tedarikçi politikasında (CIL): 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute binder_device_v2)
(allow binder_device_v2 …)
Yeni türler

Bu senaryo, platform yeni bir tür eklediğinde ortaya çıkar. Bu durum, yeni özellikler eklenirken veya politika sıkılaştırma sırasında gerçekleşebilir.

  • Yeni özellik Tür, daha önce var olmayan bir nesneyi (yeni bir hizmet işlemi gibi) etiketliyorsa tedarikçi kodu daha önce bu nesneyle doğrudan etkileşime geçmediğinden ilgili bir politika yoktur. Türe karşılık gelen yeni özellik, önceki sürümde bir özelliğe sahip değildir. Bu nedenle, eşleme dosyasında bu sürümü hedefleyen bir girişe gerek yoktur.
  • Politikayı sağlamlaştırma. Tür, politika sertleştirmesini temsil ettiğinde yeni tür özelliği, öncekine karşılık gelen bir özellik zincirine geri bağlanmalıdır (/sys/A'ün sysfs'ten sysfs_A'ye değiştiği önceki örneğe benzer). Tedarikçi kodu, sysfs'e erişimi sağlayan bir kurala dayanır ve bu kuralı yeni türün bir özelliği olarak eklemesi gerekir.

v1 → v2 yükseltme işleminde platform politikası şunları içermelidir: 

type sysfs_A; -> (type sysfs_A) (in CIL)
type sysfs; (type sysfs) (in CIL)

1. sürüm eşleme dosyasında (CIL): 

(typeattributeset sysfs_v1 (sysfs sysfs_A))

v2 eşleme dosyasında (CIL): 

(typeattributeset sysfs_v2 (sysfs))
(typeattributeset sysfs_A_v2 (sysfs_A))

v1 tedarikçi politikasında (CIL): 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Kaldırılan türler

Bu (nadir) durum, bir tür kaldırıldığında ortaya çıkar. Bu durum, temel nesne aşağıdaki durumlarda kaldırıldığında ortaya çıkabilir:

  • Kalır ancak farklı bir etiket alır.
  • Platform tarafından kaldırılır.

Politika gevşetme sırasında bir tür kaldırılır ve bu türle etiketlenen nesneye farklı, mevcut bir etiket verilir. Bu, özellik eşlemelerinin birleştirilmesini gösterir: Tedarikçi kodu, temel nesneye eskiden sahip olduğu özellikle erişmeye devam edebilmelidir ancak sistemin geri kalanı artık yeni özelliğiyle nesneye erişebilmelidir.

Geçiş yapılan özellik yeniyse yeniden etiketleme işlemi, yeni tür durumundakiyle aynıdır. Bununla birlikte, mevcut bir etiket kullanıldığında eski özelliğin yeni türü eklenir. Bu da bu türle etiketlenen diğer nesnelerin yeni olarak erişilebilir olmasına neden olur. Platform temel olarak bunu yapar ve uyumluluğu korumak için kabul edilebilir bir takas olarak kabul edilir. 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Örnek 1. Sürüm: Türleri daraltma (sysfs_A kaldırılıyor)

v1 → v2 yükseltme işleminde platform politikası şunları içermelidir: 

type sysfs; (type sysfs) (in CIL)

1. sürüm eşleme dosyasında (CIL): 

(typeattributeset sysfs_v1 (sysfs))
(type sysfs_A) # in case vendors used the sysfs_A label on objects
(typeattributeset sysfs_A_v1 (sysfs sysfs_A))

v2 eşleme dosyasında (CIL): 

(typeattributeset sysfs_v2 (sysfs))

v1 tedarikçi politikasında (CIL): 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Örnek 2 Sürümü: Tamamen kaldırma (foo türü)

v1 → v2 yükseltme işleminde platform politikası şunları içermelidir: 

# nothing - we got rid of the type

1. sürüm eşleme dosyasında (CIL): 

(type foo) #needed in case vendors used the foo label on objects
(typeattributeset foo_v1 (foo))

v2 eşleme dosyasında (CIL): 

# nothing - get rid of it

v1 tedarikçi politikasında (CIL): 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Yeni sınıf/izinler

Bu senaryo, platform yükseltmesi sırasında önceki sürümlerde bulunmayan yeni politika bileşenleri kullanıma sunulduğunda ortaya çıkar. Örneğin, Android; ekleme, bulma ve listeleme izinlerini oluşturan servicemanager nesne yöneticisini eklediğinde, servicemanager'e kaydolmak isteyen tedarikçi daemon'ları mevcut olmayan izinlere ihtiyaç duyuyordu. Android 8.0'da yalnızca platform politikası yeni sınıflar ve izinler ekleyebilir.

Tedarikçi firma politikası uyarınca oluşturulmuş veya genişletilmiş tüm alanların yeni sınıfı sorunsuz bir şekilde kullanmasına izin vermek için platform politikasının aşağıdakine benzer bir kural içermesi gerekir: 

allow {domain -coredomain} *:new_class perm;

Hatta tedarikçi firma görüntüsünün erişebildiğinden emin olmak için tüm arayüz türlerine (herkese açık politika) erişim izni veren bir politika gerekebilir. Bu durum, kabul edilemez bir güvenlik politikasıyla sonuçlanırsa (servicemanager değişikliklerinde olduğu gibi) tedarikçi yükseltmesi zorunlu kılınabilir.

Kaldırılan sınıf/izinler

Bu senaryo, bir nesne yöneticisi (ZygoteConnection nesne yöneticisi gibi) kaldırıldığında ortaya çıkar ve soruna neden olmaz. Sağlayıcı sürümü artık kullanmayana kadar nesne yöneticisi sınıfı ve izinleri politikada tanımlanmaya devam edebilir. Bu işlem, tanımları ilgili eşleme dosyasına ekleyerek yapılır.

Yeni/yeniden etiketlenmiş türler için tedarikçi özelleştirmesi

Yeni satıcı türleri, yeni süreçleri, ikili dosyaları, cihazları, alt sistemleri ve depolanan verileri tanımlamak için gerekli olduğundan satıcı politikası geliştirmenin merkezinde yer alır. Bu nedenle, tedarikçi firma tarafından tanımlanan türlerin oluşturulmasına izin verilmesi zorunludur.

Tedarikçi firma politikası her zaman cihazdaki en eski politika olduğundan, tüm tedarikçi firma türlerini politikadaki özelliklere otomatik olarak dönüştürmeye gerek yoktur. Platform, satıcı politikasında etiketlenen hiçbir şeye güvenmez çünkü bu politika hakkında bilgi sahibi değildir. Ancak platform, bu türlerle etiketlenen nesnelerle etkileşimde bulunmak için kullandığı özellikleri ve herkese açık türleri (ör. domain, sysfs_type vb.) sağlar. Platformun bu nesnelerle doğru şekilde etkileşim kurmaya devam etmesi için özelliklerin ve türlerin uygun şekilde uygulanması gerekir. Ayrıca, özelleştirilebilir alanlara (init gibi) belirli kurallar eklenmesi gerekebilir.

Android 9 için özellik değişiklikleri

Android 9'a yükseltilen cihazlar aşağıdaki özellikleri kullanabilir ancak Android 9 ile kullanıma sunulan cihazlar bu özellikleri kullanamaz.

Politikayı ihlal eden kullanıcıların özellikleri

Android 9, alanla ilgili aşağıdaki özellikleri içerir:

  • data_between_core_and_vendor_violators. vendor ile coredomains arasındaki yollarda dosya paylaşma şartını ihlal eden tüm alanlar için özellik. Platform ve tedarikçi firma işlemleri, iletişim kurmak için disk üzerindeki dosyaları kullanmamalıdır (istikrarsız ABI). Öneri:
    • Tedarikçi firma kodunda /data/vendor kullanılmalıdır.
    • Sistemde /data/vendor kullanılmamalıdır.
  • system_executes_vendor_violators. Tedarikçi firma ikili dosyalarını çalıştırmama şartını ihlal eden tüm sistem alanları (init ve shell domains hariç) için özellik. Tedarikçi firma ikili dosyalarının yürütülmesi kararsız API'ye sahip. Platform, tedarikçi firma ikililerini doğrudan yürütmemelidir. Öneri:
    • Tedarikçi firma ikililerine yönelik bu tür platform bağımlılıkları, HIDL HAL'lerinin arkasında olmalıdır.

      VEYA

    • Tedarikçi firma ikili programlarına erişmesi gereken coredomains, tedarikçi firma bölümüne taşınmalı ve böylece coredomain olmaktan çıkmalıdır.

Güvenilmeyen özellikler

İsteğe bağlı kod barındıran güvenilmeyen uygulamaların, bu tür uygulamalardan erişmek için yeterince güvenli kabul edilenler dışında HwBinder hizmetlerine erişimi olmamalıdır (aşağıdaki güvenli hizmetlere bakın). Bunun başlıca iki nedeni vardır:

  1. HIDL şu anda arayan UID bilgilerini göstermediğinden HwBinder sunucuları istemci kimlik doğrulaması gerçekleştirmez. HIDL bu tür verileri gösterse bile birçok HwBinder hizmeti, uygulamaların altında bir seviyede çalışır (HAL'ler gibi) veya yetkilendirme için uygulama kimliğine güvenmemelidir. Bu nedenle, güvenli olması için varsayılan varsayım, her HwBinder hizmetinin tüm müşterilerini, hizmet tarafından sunulan işlemleri gerçekleştirmek için eşit derecede yetkili olarak ele almasıdır.
  2. HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi), system/core bileşenlerine kıyasla daha yüksek güvenlik sorunu görülme oranına sahip kodlar içerir ve yığının alt katmanlarına (donanıma kadar) erişebilir. Bu nedenle Android güvenlik modelini atlama fırsatları artar.

Güvenli hizmetler

Güvenli hizmetler şunlardır:

  • same_process_hwservice. Bu hizmetler (tanım gereği) istemcinin işleminde çalışır ve bu nedenle, işlemin çalıştığı istemci alanıyla aynı erişime sahiptir.
  • coredomain_hwservice. Bu hizmetler, 2. nedenle ilişkili riskler oluşturmaz.
  • hal_configstore_ISurfaceFlingerConfigs. Bu hizmet, özellikle herhangi bir alan tarafından kullanılmak için tasarlanmıştır.
  • hal_graphics_allocator_hwservice. Bu işlemler, uygulamaların erişmesine izin verilen surfaceflinger Binder hizmeti tarafından da sunulur.
  • hal_omx_hwservice. Bu, uygulamaların erişmesine izin verilen mediacodec Binder hizmetinin HwBinder sürümüdür.
  • hal_codec2_hwservice. Bu, hal_omx_hwservice'un daha yeni bir sürümüdür.

Kullanılabilir özellikler

Güvenli olarak kabul edilmeyen tüm hwservices öğelerinde untrusted_app_visible_hwservice özelliği bulunur. İlgili HAL sunucularında untrusted_app_visible_halserver özelliği bulunur. Android 9 ile kullanıma sunulan cihazlar untrusted özelliğini KULLANMAMALIDIR.

Öneri:

  • Güvenilmeyen uygulamalar, bunun yerine tedarikçi HIDL HAL ile konuşan bir sistem hizmetiyle iletişim kurmalıdır. Örneğin, uygulamalar binderservicedomain ile konuşabilir, ardından mediaserver (binderservicedomain olan) hal_graphics_allocator ile konuşur.

    VEYA

  • vendor HAL'lerine doğrudan erişmesi gereken uygulamaların kendi tedarikçi firma tarafından tanımlanmış sepolicy alanları olmalıdır.

Dosya özelliği testleri

Android 9, belirli konumlardaki tüm dosyaların uygun özelliklere sahip olmasını sağlayan derleme zamanı testleri içerir (ör. sysfs içindeki tüm dosyaların gerekli sysfs_type özelliğine sahip olması).

Platform-kamu politikası

Platform herkese açık politikası, 1. ve 2. sürümdeki platform politikalarının birliğini korumak yerine Android 8.0 mimari modeline uygunluğun temelini oluşturur. Tedarikçi firmalar, kullanılabilir türleri ve özellikleri ve bu tür ve özelliklerle ilgili kuralları içeren platform politikasının bir alt kümesine tabidir. Bu alt küme daha sonra tedarikçi politikasının bir parçası olur (yani vendor_sepolicy.cil).

Tür ve kurallar, tedarikçi firma tarafından oluşturulan politikaya otomatik olarak attribute_vN olarak çevrilir. Böylece, platform tarafından sağlanan tüm türler sürümlü özellikler olur (ancak özellikler sürümlü olmaz). Tedarikçi firma politikasının çalışmaya devam etmesini ve belirli bir sürüm için sağlanan kuralların dahil edilmesini sağlamak amacıyla platform, sağladığı somut türleri uygun özelliklerle eşlemekten sorumludur. Platformun herkese açık politikası ile tedarikçi politikasının birleşimi, bağımsız platform ve tedarikçi derlemelerine izin verme hedefine yönelik Android 8.0 mimari modelini karşılar.

Özellik zincirleriyle eşleme

Politika sürümleriyle eşlemek için özellikler kullanıldığında bir tür, bir özellik veya birden fazla özellikle eşlenir. Bu sayede, türle etiketlenen nesnelere önceki türlerine karşılık gelen özellikler aracılığıyla erişilebilir.

Sürüm bilgilerini politika yazarından gizleme hedefi, sürümlendirilmiş özellikleri otomatik olarak oluşturmak ve uygun türlere atamak anlamına gelir. Statik türlerde bu işlem basittir: type_foo, type_foo_v1 ile eşlenir.

sysfs → sysfs_A veya mediaserver → audioserver gibi bir nesne etiketi değişikliği için bu eşlemeyi oluşturmak basit bir işlem değildir (yukarıdaki örneklerde açıklanmaktadır). Platform politikası yöneticileri, nesnelerin geçiş noktalarında eşlemenin nasıl oluşturulacağını belirlemelidir. Bu, nesneler ile atanan etiketleri arasındaki ilişkiyi anlama ve bu ilişkinin ne zaman gerçekleştiğini belirlemeyi gerektirir. Geriye dönük uyumluluk için bu karmaşıklığın platform tarafında yönetilmesi gerekir. Bu, güncelleme yapabilecek tek bölümdür.

Sürüm önizlemeleri

Android platformu, basitlik sağlamak için yeni bir sürüm dalı oluşturulduğunda bir sepolicy sürümü yayınlar. Yukarıda açıklandığı gibi, sürüm numarası PLATFORM_SEPOLICY_VERSION içinde yer alır ve MM.nn biçimindedir. Burada MM, SDK değerine karşılık gelir ve nn, /platform/system/sepolicy. içinde tutulan özel bir değerdir. Örneğin, Kitkat için 19.0, Lollipop için 21.0, Lollipop-MR1 için 22.0, Marshmallow için 23.0, Nougat için 24.0, Nougat-MR1 için 25.0, Oreo için 26.0, Oreo-MR1 için 27.0 ve Android 9 için 28.0. Önceki sürümler her zaman tam sayı değildir. Örneğin, bir sürümde MR yükseltmesi system/sepolicy/public'te uyumsuz bir değişiklik yapılmasını gerektiriyorsa ancak API yükseltmesi gerektirmiyorsa bu sepolicy sürümü vN.1 olabilir. Geliştirme dalında bulunan sürüm, gönderim cihazlarında hiçbir zaman kullanılmaması gereken bir 10000.0 sürümüdür.

Android, yükseltme yaparken en eski sürümü kullanımdan kaldırabilir. Bir sürümün desteğinin ne zaman sonlandırılacağı konusunda bilgi edinmek için Android, bu Android sürümünü çalıştıran ve hâlâ önemli platform güncellemeleri alan tedarikçi firma politikalarına sahip cihazların sayısını toplayabilir. Sayı belirli bir eşiğin altındaysa bu sürümün desteği sonlandırılır.

Birden fazla özelliğin performans üzerindeki etkisi

https://github.com/SELinuxProject/cil/issues/9 adresinde açıklandığı gibi, bir türe atanan çok sayıda özellik, politika önbelleği kaçırması durumunda performans sorunlarına neden olur.

Bunun Android'de bir sorun olduğu doğrulandı. Bu nedenle, politika derleyicisi tarafından politikaya eklenen özelliklerin yanı sıra kullanılmayan özelliklerin kaldırılması için Android 8.0'da değişiklikler yapıldı. Bu değişiklikler, performanstaki gerilemelerin çözülmesini sağladı.

system_ext herkese açık ve ürün herkese açık politikası

Android 11'den itibaren system_ext ve product bölümlerinin, belirlenen herkese açık türlerini tedarikçi firma bölümüne aktarmasına izin verilir. Platformun herkese açık politikası gibi tedarikçi de sürümlü özelliklere otomatik olarak çevrilen türleri ve kuralları kullanır. Örneğin, type yerine type_N kullanılır. Burada N, tedarikçi bölümünün oluşturulduğu platformun sürümüdür.

system_ext ve product bölümleri aynı platform sürümüne (N) dayalı olduğunda derleme sistemi, type ile type_N arasındaki kimlik eşlemelerini içeren system_ext/etc/selinux/mapping/N.cil ve product/etc/selinux/mapping/N.cil için temel eşleme dosyaları oluşturur. Tedarikçi firma, sürümlü özellik type_N ile type'e erişebilir.

Yalnızca system_ext ve product bölümlerinin güncellenmesi durumunda (ör. N'den N+1'a (veya daha yeni bir sürüme) güncellenmesi) tedarikçi N sürümünde kalırken system_ext ve product bölümlerinin türlerine erişimi kaybedebilir. Kesintileri önlemek için system_ext ve product bölümlerinde, somut türlerden type_N özelliklerine eşleme dosyaları sağlanmalıdır. N tedarikçisini N+1 (veya sonraki sürümler) system_ext ve product bölümleriyle destekleyecekse her iş ortağı, eşleme dosyalarını korumaktan sorumludur.

Bunun için iş ortaklarının:

  1. Oluşturulan temel eşleme dosyalarını N system_ext ve product bölümlerinden kaynak ağaçlarına kopyalayın.
  2. Eşleme dosyalarını gerektiği gibi düzeltin.
  3. N+1 (veya sonraki sürümler) system_ext ve product bölümlerine eşleme dosyalarını yükleyin.

Örneğin, N system_ext adlı bir kaynağın foo_type adlı herkese açık bir türü olduğunu varsayalım. Bu durumda, N system_ext bölümündeki system_ext/etc/selinux/mapping/N.cil şöyle görünür: 

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

bar_type, N+1 system_ext'e eklenirse ve bar_type, N tedarikçi firma için foo_type ile eşlenecekse N.cil, 

(typeattributeset foo_type_N (foo_type))

to 

(typeattributeset foo_type_N (foo_type bar_type))

ve ardından N+1 system_ext'in bölümüne yüklenir. N tedarikçi firma, N+1system_ext'in foo_type ve bar_type dosyalarına erişmeye devam edebilir.

SELinux bağlamları etiketleme

Sistem, platform ve tedarikçi sepolitikası arasındaki ayrımı desteklemek için SELinux bağlam dosyalarını ayrı tutmak amacıyla farklı şekilde oluşturur.

Dosya bağlamları

Android 8.0'da file_contexts için aşağıdaki değişiklikler yapıldı:

  • Açılış sırasında cihazda ek derleme yükü oluşmasını önlemek için file_contexts ikili biçimde mevcut değildir. Bunun yerine, {property, service}_contexts gibi okunabilir, normal ifade metin dosyalarıdır (7.0 öncesi gibi).
  • file_contexts iki dosya arasında bölünür:
    • plat_file_contexts
      • /vendor bölümünün, sepolicy dosyalarının düzgün şekilde çalışması için tam olarak etiketlenmesi gereken bölümleri etiketlemek dışında cihaza özgü etiketleri olmayan Android platformu file_context.
      • Cihazdaki /system/etc/selinux/plat_file_contexts bölümündeki system bölümünde bulunmalı ve başlangıçta init tarafından file_context tedarikçi firmayla birlikte yüklenmelidir.
    • vendor_file_contexts
      • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan file_contexts birleştirilerek oluşturulan cihaza özel file_context.
      • vendor bölümündeki /vendor/etc/selinux/vendor_file_contexts konumuna yüklenmeli ve file_context platformuyla birlikte başlangıçta init tarafından yüklenmelidir.

Mülk bağlamları

Android 8.0'da property_contexts iki dosya arasında bölünür:

  • plat_property_contexts
    • Cihaza özel etiketi olmayan Android platformu property_context.
    • /system/etc/selinux/plat_property_contexts adresinde system bölümünde bulunmalı ve başlangıçta init tarafından property_contexts tedarikçi firmayla birlikte yüklenmelidir.
  • vendor_property_contexts
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan property_contexts birleştirilerek oluşturulan cihaza özel property_context.
    • /vendor/etc/selinux/vendor_property_contexts'da vendor bölümünde bulunmalı ve başlangıçta init tarafından platformla birlikte property_context yüklenmelidir

Hizmet bağlamları

Android 8.0'da service_contexts aşağıdaki dosyalar arasında bölünür:

  • plat_service_contexts
    • servicemanager için Android platformuna özgü service_context. service_context öğesinde cihaza özgü etiket yoktur.
    • /system/etc/selinux/plat_service_contexts adresinde system bölümünde bulunmalı ve başlangıçta servicemanager tarafından service_contexts tedarikçi firmayla birlikte yüklenmelidir.
  • vendor_service_contexts
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan service_contexts birleştirilerek oluşturulan cihaza özel service_context.
    • /vendor/etc/selinux/vendor_service_contexts'ta vendor bölümünde bulunmalı ve başlangıçta servicemanager tarafından service_contexts platformuyla birlikte yüklenmelidir.
    • servicemanager, önyükleme sırasında bu dosyayı aramasına rağmen, tam uyumlu bir TREBLE cihazda vendor_service_contexts BULUNMAMALIDIR. Bunun nedeni, vendor ve system süreçleri arasındaki tüm etkileşimin hwservicemanager/hwbinder üzerinden GİTMESİ GEREKTİR.
  • plat_hwservice_contexts
    • Cihazlara özgü etiketi olmayan hwservicemanager için Android platformu hwservice_context.
    • /system/etc/selinux/plat_hwservice_contexts'da system bölümünde bulunmalı ve başlangıçta hwservicemanager tarafından vendor_hwservice_contexts ile birlikte yüklenmelidir.
  • vendor_hwservice_contexts
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan hwservice_contexts birleştirilerek oluşturulan cihaza özel hwservice_context.
    • /vendor/etc/selinux/vendor_hwservice_contexts'da vendor bölümünde bulunmalı ve başlangıçta hwservicemanager tarafından plat_service_contexts ile birlikte yüklenmelidir.
  • vndservice_contexts
    • Cihazın Boardconfig.mk bölümündeki BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan vndservice_contexts birleştirilerek oluşturulan vndservicemanager için cihaza özel service_context.
    • Bu dosya, /vendor/etc/selinux/vndservice_contexts konumundaki vendor bölümünde olmalı ve başlangıçta vndservicemanager tarafından yüklenmelidir.

Seapp bağlamları

Android 8.0'da seapp_contexts iki dosya arasında bölünür:

  • plat_seapp_contexts
    • Cihaza özgü değişiklik içermeyen Android platformu seapp_context.
    • /system/etc/selinux/plat_seapp_contexts. bölümündeki system bölümünde olmalıdır
  • vendor_seapp_contexts
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan seapp_contexts birleştirilerek oluşturulan seapp_context platformuna özel uzantı.
    • /vendor/etc/selinux/vendor_seapp_contexts adresinde vendor bölümünde olmalıdır.

MAC izinleri

Android 8.0'da mac_permissions.xml iki dosya arasında bölünür:

  • Platform mac_permissions.xml
    • Cihaza özgü değişiklik içermeyen Android platformu mac_permissions.xml.
    • /system/etc/selinux/. bölümündeki system bölümünde olmalıdır
  • Platform dışı mac_permissions.xml
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaretlenen dizinlerde bulunan mac_permissions.xml kaynaklı mac_permissions.xml platformuna özel uzantı.
    • /vendor/etc/selinux/. bölümündeki vendor bölümünde olmalıdır