Politika Uyumluluğu

Bu makale, Android'in, yeni platform SELinux ayarlarının eski satıcı SELinux ayarlarından farklı olabileceği platform OTA'ları ile politika uyumluluğu sorunlarını nasıl ele aldığını açıklamaktadır.

Tiz tabanlı SELinux politika tasarımı, platform ve satıcı politikası arasındaki ikili ayrımı dikkate alır; satıcı 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 global politikası özel ve genel bileşenlere bölünmüştür. Genel bileşenler, bir platform sürümü için kullanılabilir olması garanti edilen ilke ve ilişkili altyapıdan oluşur. Bu politika, satıcıların, platform tarafından sağlanan ilkeyle birleştirildiğinde bir cihaz için tam işlevli bir ilkeyle sonuçlanan bir satıcı ilke dosyası oluşturmasını sağlamak için satıcı ilkesi yazarlarına sunulacaktır.

• Versiyon oluşturma için, dışa aktarılan platform-genel politikası nitelikler olarak yazılacaktır.
• İlke yazma kolaylığı için, dışa aktarılan türler, ilke oluşturma sürecinin bir parçası olarak sürümlü özniteliklere dönüştürülecektir. Genel türler, doğrudan satıcı bağlam dosyaları tarafından sağlanan etiketleme kararlarında da kullanılabilir.

Android, platform ilkesinde dışa aktarılan somut türler ile her platform sürümü için karşılık gelen sürümlü öznitelikler arasında bir eşleme sağlar . Bu, nesneler bir türle etiketlendiğinde, önceki bir sürümde platform-kamu politikası tarafından garanti edilen davranışı bozmamasını sağlar. Bu eşleme, kamu politikasında dışa aktarılan her tür için öznitelik üyelik bilgilerini tutan her platform sürümü için bir eşleme dosyasını güncel tutarak korunur.

Nesne sahipliği ve etiketleme

Android 8.0 ve sonraki sürümlerde politikayı özelleştirirken, platform ve satıcı politikasını ayrı tutmak için her bir nesne için sahiplik açıkça tanımlanmalıdır. Örneğin, sağlayıcı /dev/foo etiketlerse ve platform daha sonra bir sonraki OTA'da /dev/foo etiketlerse, tanımsız davranış olacaktır. SELinux için bu, etiketleme çakışması olarak kendini gösterir. Cihaz düğümü, en son hangi etiketin uygulandığını çözen yalnızca tek bir etikete sahip olabilir. Sonuç olarak:

• Başarısız bir şekilde uygulanan etikete erişmesi gereken işlemler, kaynağa erişimi kaybeder.
• Dosyaya erişim sağlayan işlemler, yanlış aygıt düğümü oluşturulduğundan bozulabilir.

Sistem özellikleri ayrıca, sistemde tanımsız davranışa neden olabilecek adlandırma çarpışmaları potansiyeline de sahiptir (ayrıca SELinux etiketlemesi için). Özellikler, hizmetler, işlemler, dosyalar ve soketler dahil olmak üzere bir SELinux etiketine sahip herhangi bir nesne için platform ve satıcı etiketleri arasında çakışmalar meydana gelebilir. Bu sorunları önlemek için, bu nesnelerin sahipliğini açıkça tanımlayın.

Etiket çakışmalarına ek olarak, SELinux türü/öznitelik adları da çakışabilir. Tür/öznitelik adı çakışması her zaman bir ilke derleyici hatasına neden olur.

Tür/öznitelik ad aralığı

SELinux, aynı türde/öznitelikte birden çok bildirime izin vermez. Yinelenen bildirimlere sahip politika derlemede başarısız olur. Tür ve öznitelik adı çakışmalarını önlemek için, tüm satıcı bildirimleri np_ ile başlayarak ad alanına yerleştirilmelidir.

type foo, domain; → type np_foo, domain;

Sistem özelliği ve süreç etiketleme sahipliği

Etiketleme çakışmalarından kaçınmak en iyi şekilde özellik ad alanları kullanılarak çözülür. Platform özelliklerini kolayca tanımlamak ve dışa aktarılan platform özelliklerini yeniden adlandırırken veya eklerken ad çakışmalarını önlemek için tüm satıcı özelliklerinin kendi ön eklerine sahip olduğundan emin olun:

Satıcılar ro.boot.* (çekirdek cmdline'ından gelir) ve ro.hardware.* (donanımla ilgili bariz bir özellik) kullanmaya devam edebilir.

init rc dosyalarındaki tüm satıcı hizmetleri vendor. sistem dışı bölümlerin init rc dosyalarındaki hizmetler için. Benzer kurallar satıcı özellikleri için SELinux etiketlerine uygulanır (satıcı özellikleri için vendor_ ).

Dosya sahipliği

Hem platform hem de satıcı politikası genel olarak tüm dosya sistemleri için etiketler sağladığından, dosyalar için çakışmaları önlemek zordur. Tür adlandırmanın aksine, dosyaların ad alanı, çoğu çekirdek tarafından oluşturulduğundan pratik değildir. Bu çarpışmaları önlemek için bu bölümdeki dosya sistemleri için adlandırma kılavuzunu izleyin. Android 8.0 için bunlar, teknik yaptırımı olmayan önerilerdir. Gelecekte, bu öneriler Vendor Test Suite (VTS) tarafından uygulanacaktır.

Sistem (/sistem)

Yalnızca sistem görüntüsü, file_contexts , service_contexts vb. yoluyla /system bileşenleri için etiketler sağlamalıdır. /vendor ilkesinde /system bileşenleri için etiketler eklenirse, yalnızca çerçeve OTA güncellemesi mümkün olmayabilir.

Satıcı (/satıcı)

AOSP SELinux politikası, platformun etkileşime girdiği vendor bölümünün bölümlerini zaten etiketler; bu, platform işlemleri için vendor bölümünün konuşabilmesi ve/veya bölümlerine erişebilmesi için SELinux kurallarının yazılmasını sağlar. Örnekler:

Sonuç olarak, vendor bölümündeki ek dosyaları etiketlerken belirli kurallara uyulmalıdır ( neverallows aracılığıyla uygulanır):

• vendor_file vendor bölümündeki tüm dosyalar için varsayılan etiket olmalıdır. Platform ilkesi, doğrudan geçişli HAL uygulamalarına erişmek için bunu gerektirir.
• Satıcı SEPolicy aracılığıyla vendor bölümüne eklenen tüm yeni exec_types , vendor_file_type özniteliğine sahip olmalıdır. Bu, Neverallows aracılığıyla uygulanı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.

İşlemler (/işlem)

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

Öneri: Yalnızca platform politikası etiketleri /proc . vendor işlemlerinin, şu anda varsayılan etiketle ( proc ) etiketlenmiş /proc içindeki dosyalara erişmesi gerekiyorsa, satıcı ilkesi bunları açıkça etiketlememeli ve bunun yerine satıcı etki alanlarına kurallar eklemek için genel proc türünü kullanmalıdır. Bu, platform güncellemelerinin procfs aracılığıyla ortaya çıkan gelecekteki çekirdek arabirimlerini barındırmasına ve gerektiğinde bunları açıkça etiketlemesine olanak tanır.

Hata ayıklamalar (/sys/kernel/debug)

Debugfs hem file_contexts hem de genfscon içinde etiketlenebilir. Android 7.0'dan Android 10'a, hem platform hem de satıcı etiketi debugfs .

Android 11'de debugfs erişilemez veya üretim cihazlarına bağlanamaz. Cihaz üreticileri debugfs kaldırmalıdır.

İzler (/sys/kernel/debug/tracing)

Tracefs hem file_contexts hem de genfscon içinde etiketlenebilir. Android 7.0'da yalnızca platform tracefs olarak etiketlenir.

Öneri: tracefs yalnızca platform etiketleyebilir.

Sysf'ler (/sys)

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

Öneri: Platform, cihaza özel olmayan sysfs düğümlerini etiketleyebilir. Aksi takdirde, yalnızca satıcı dosyaları etiketleyebilir.

tmpfs (/dev)

/dev içindeki dosyalar file_contexts içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiketi dosyaları burada.

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

Kökler (/)

/ içindeki dosyalar file_contexts içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiketi dosyaları burada.

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

Veri (/veri)

Veriler, file_contexts ve seapp_contexts kombinasyonuyla etiketlenir.

Öneri: /data/vendor dışında satıcı etiketlemesine izin vermeyin. /data öğesinin diğer bölümlerini yalnızca platform etiketleyebilir.

Uyumluluk özellikleri

SELinux ilkesi, belirli nesne sınıfları ve izinleri 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ürler açısından yazılır:

allow source_type target_type:target_class permission(s);

Bu işe yarar, çünkü politika her türden bilgiyle yazılmıştır. Ancak satıcı ilkesi ve platform ilkesi belirli türler kullanıyorsa ve belirli bir nesnenin etiketi bu ilkelerden yalnızca birinde değişirse, diğeri daha önce güvenilen erişim kazanmış veya kaybetmiş bir ilke içerebilir. Örneğin:

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

Satıcı politikası aynı kalsa da v_domain , yeni sysfs_A türü için politika olmaması nedeniyle erişimi kaybeder.

Nitelikler açısından bir ilke tanımlayarak, temel nesneye hem platform hem de satıcı kodu için ilkeye karşılık gelen bir özniteliği olan bir tür verebiliriz. Bu, somut türlerin asla kullanılmadığı bir öznitelik politikasını etkili bir şekilde oluşturmak için tüm türler için yapılabilir. Pratikte bu, yalnızca satıcı politikasının bir parçası olarak oluşturulan platform genel politikası olarak tanımlanan ve sağlanan, platform ve tedarikçi firma arasında çakışan politika bölümleri için gereklidir.

Kamu politikasını sürümlü nitelikler olarak tanımlamak, iki politika uyumluluğu hedefini karşılar:

• Satıcı kodunun platform güncellemesinden sonra çalışmaya devam etmesini sağlayın . Erişimi koruyarak satıcı kodunun dayandığı nesnelere karşılık gelen somut türlere öznitelikler ekleyerek elde edilir.
• İlkeyi kullanımdan kaldırma yeteneği . İlke kümelerinin, karşılık geldikleri sürüm artık desteklenmediğinde kaldırılabilecek özniteliklere net bir şekilde tanımlanmasıyla elde edilir. Eski ilkenin satıcı ilkesinde hala mevcut olduğunu ve yükseltildiğinde/yükseltilirse otomatik olarak kaldırılacağını bilerek, geliştirme platformda devam edebilir.

Politika yazılabilirliği

Politika geliştirme için belirli sürüm değişiklikleri hakkında bilgi gerektirmeme hedefine ulaşmak için Android 8.0, platform-kamu politikası türleri ve öznitelikleri arasında bir eşleme içerir. foo türü, foo_v N özniteliğiyle eşlenir; burada N hedeflenen sürümdür. vN , PLATFORM_SEPOLICY_VERSION yapı değişkenine karşılık gelir ve MM.NN biçimindedir; burada MM , platform SDK numarasına karşılık gelir ve NN , platforma özel politikaya özgü bir sürümdür.

Kamu politikasındaki öznitelikler sürümlendirilmez, bunun yerine iki bölüm arasındaki arabirimi sabit tutmak için platformun ve satıcı ilkesinin oluşturulabileceği bir API olarak bulunur. Hem platform hem de satıcı politikası yazarları, bugün yazıldığı gibi politika yazmaya devam edebilir.

Platform-kamu politikası, allow source_foo target_bar: class perm ; satıcı politikasının bir parçası olarak dahil edilmiştir. Derleme sırasında (karşılık gelen sürümü içerir), cihazın satıcı kısmına gidecek ilkeye dönüştürülür (dönüştürülmüş Ortak Ara Dil'de (CIL) gösterilir):

 (allow source_foo_vN target_bar_vN (class (perm)))

Satıcı politikası hiçbir zaman platformun ilerisinde olmadığı için önceki sürümlerle ilgilenmemelidir. Bununla birlikte, platform politikasının satıcı politikasının ne kadar geriye gittiğini bilmesi, türlerine öznitelikleri dahil etmesi ve sürümlü özniteliklere karşılık gelen politikayı ayarlaması gerekir.

Politika farklılıkları

Her türün sonuna _v N ekleyerek öznitelikleri otomatik olarak oluşturmak, öznitelikleri sürüm farkları genelinde türlere eşlemeden hiçbir şey yapmaz. Android, nitelikler için sürümler arasında bir eşleme ve bu özniteliklere türlerin bir eşlemesini sağlar. Bu, (CIL) gibi ifadelerle yukarıda belirtilen eşleme dosyalarında yapılır:

(typeattributeset foo_vN (foo))

Platform yükseltmeleri

Aşağıdaki bölüm, platform yükseltmeleri için senaryoların ayrıntılarını vermektedir.

Aynı tipler

Bu senaryo, bir nesne ilke sürümlerinde etiketleri değiştirmediğinde oluşur. Bu, kaynak ve hedef türleri 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 temsil edilir:

binder_device_v1 … binder_device_vN

v1 → v2 yükseltirken, platform politikası şunları içermelidir:

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

v1 eşleme dosyasında (CIL):

(typeattributeset binder_device_v1 (binder_device))

v2 eşleme dosyasında (CIL):

(typeattributeset binder_device_v2 (binder_device))

v1 satıcı politikasında (CIL):

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

v2 satıcı politikasında (CIL):

(typeattribute binder_device_v2)
(allow binder_device_v2 …)

Yeni tipler

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

• Yeni özellik Tür, daha önce var olmayan bir nesneyi (yeni bir hizmet süreci gibi) etiketlerken, satıcı kodu daha önce onunla doğrudan etkileşime girmemiştir, bu nedenle karşılık gelen bir ilke yoktur. Türe karşılık gelen yeni öznitelik, önceki sürümde bir özniteliğe sahip değildir ve bu nedenle, bu sürümü hedefleyen eşleme dosyasında bir girişe ihtiyaç duymaz.
• Politika sertleştirme Tür, ilke sağlamlaştırmayı temsil ettiğinde, yeni tür özniteliği öncekine karşılık gelen bir öznitelikler zincirine geri bağlanmalıdır ( /sys/A sysfs sysfs_A değiştirildiği önceki örneğe benzer). Satıcı kodu, sysfs erişim sağlayan bir kurala dayanır ve bu kuralı yeni türün bir özniteliği olarak içermesi gerekir.

v1 → v2 yükseltirken, platform politikası şunları içermelidir:

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

v1 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 satıcı politikasında (CIL):

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 satıcı politikasında (CIL):

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Kaldırılan türler

Bu (nadir) senaryo, bir tür kaldırıldığında oluşur ve bu durum, temeldeki nesne şu durumlarda gerçekleşebilir:

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

İlke gevşetme sırasında, bir tür kaldırılır ve bu türle etiketlenen nesneye farklı, zaten var olan bir etiket verilir. Bu, öznitelik eşlemelerinin birleştirilmesini temsil eder: Satıcı kodu, temel alınan nesneye eskiden sahip olduğu öznitelik aracılığıyla hala erişebilmelidir, ancak sistemin geri kalanı artık ona yeni özniteliğiyle erişebilmelidir.

Değiştirildiği öznitelik yeniyse, yeniden etiketleme, yeni tip durumundaki ile aynıdır, ancak mevcut bir etiket kullanıldığında, eski öznitelik yeni türün eklenmesi, diğer nesnelerin de bu türle etiketlenmesine neden olur. yeni erişilebilir olmak. Bu, esasen platform tarafından yapılan şeydir ve uyumluluğu sürdürmek için kabul edilebilir bir takas olarak kabul edilir.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Örnek Versiyon 1: Çöken tipler (sysfs_A kaldırılıyor)

v1 → v2 yükseltirken, platform politikası şunları içermelidir:

type sysfs; (type sysfs) (in CIL)

v1 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 satıcı politikasında (CIL):

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

v2 satıcı politikasında (CIL):

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

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

v1 → v2 yükseltirken, platform politikası şunları içermelidir:

# nothing - we got rid of the type

v1 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 satıcı politikasında (CIL):

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

v2 satıcı politikasında (CIL):

(typeattribute sysfs_v2)
(allow sysfs_v2 …)

Yeni sınıf/izinler

Bu senaryo, bir platform yükseltmesi önceki sürümlerde bulunmayan yeni ilke bileşenlerini tanıttığında oluşur. Örneğin Android, ekleme, bulma ve listeleme izinlerini oluşturan servicemanager nesne yöneticisini eklediğinde, servicemanager kaydolmak isteyen satıcı arka plan programları, mevcut olmayan izinlere ihtiyaç duyuyordu. Android 8.0'da yalnızca platform ilkesi yeni sınıflar ve izinler ekleyebilir.

Tedarikçi politikası tarafından oluşturulmuş veya genişletilmiş olabilecek tüm etki alanlarının yeni sınıfı engelleme olmadan 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;

Bu, satıcı imajının erişim kazandığından emin olmak için tüm arayüz (kamu politikası) türleri için erişime izin veren politika gerektirebilir. Bu, kabul edilemez bir güvenlik politikasıyla sonuçlanırsa (servis yöneticisi değişikliklerinde olabileceği gibi), bir satıcı yükseltmesi potansiyel olarak zorlanabilir.

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

Bu senaryo, bir nesne yöneticisi kaldırıldığında ( ZygoteConnection nesne yöneticisi gibi) oluşur ve sorunlara neden olmamalıdır. Nesne yöneticisi sınıfı ve izinler, satıcı sürümü artık onu kullanmayana kadar ilkede tanımlı kalabilir. Bu, karşılık gelen eşleme dosyasına tanımları ekleyerek yapılır.

Yeni/yeniden etiketlenmiş türler için satıcı özelleştirmesi

Yeni satıcı türleri, yeni süreçleri, ikili dosyaları, aygıtları, alt sistemleri ve depolanan verileri açıklamak için gerekli olduğundan, satıcı politikası geliştirmenin merkezinde yer alır. Bu nedenle, satıcı tanımlı türlerin oluşturulmasına izin verilmesi zorunludur.

Satıcı politikası her zaman cihazdaki en eski politika olduğundan, tüm satıcı türlerini politikadaki özniteliklere otomatik olarak dönüştürmeye gerek yoktur. Platform, tedarikçi politikasında etiketlenmiş herhangi bir şeye güvenmez çünkü platformun bu konuda bilgisi yoktur; ancak platform, bu türlerle etiketlenmiş nesnelerle (örneğin, domain , sysfs_type , vb.) etkileşim kurmak için kullandığı öznitelikleri ve genel türleri sağlayacaktır. Platformun bu nesnelerle doğru bir şekilde etkileşime devam etmesi için nitelikler ve türler uygun şekilde uygulanmalı ve özelleştirilebilir etki alanlarına ( init gibi) belirli kurallar eklenmelidir.

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

Android 9'a yükseltme yapan cihazlar aşağıdaki öznitelikleri kullanabilir, ancak Android 9 ile başlayan cihazlar kullanmamalıdır.

İhlal eden özellikleri

Android 9, alanla ilgili şu özellikleri içerir:

• data_between_core_and_vendor_violators . vendor ve coredomains arasında yol yoluyla dosya paylaşmama gerekliliğini ihlal eden tüm etki alanları için öznitelik. Platform ve satıcı işlemleri, iletişim kurmak için diskteki dosyaları kullanmamalıdır (kararsız ABI). Öneri:
  • Satıcı kodu /data/vendor kullanmalıdır.
  • Sistem /data/vendor kullanmamalıdır.
• system_executes_vendor_violators . Satıcı ikili dosyalarını yürütmeme gerekliliğini ihlal eden tüm sistem etki alanları ( init ve shell domains hariç) için öznitelik. Satıcı ikili dosyalarının yürütülmesinde kararsız API var. Platform, satıcı ikili dosyalarını doğrudan yürütmemelidir. Öneri:
  • Satıcı ikili dosyalarındaki bu tür platform bağımlılıkları, HIDL HAL'lerin arkasında olmalıdır.

    VEYA

  • satıcı ikili dosyalarına erişmesi gereken coredomains , satıcı bölümüne taşınmalı ve böylece coredomain olmaktan çıkmalıdır.

güvenilmeyen özellikler

Rastgele kod barındıran güvenilmeyen uygulamaların, bu tür uygulamalardan erişim 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 iki ana nedeni:

1. HwBinder sunucuları, istemci kimlik doğrulaması gerçekleştirmez çünkü HIDL şu anda arayanın UID bilgilerini göstermez. HIDL bu tür verileri ifşa etmiş olsa bile, birçok HwBinder hizmeti, uygulamaların (HAL'ler gibi) altında çalışır veya yetkilendirme için uygulama kimliğine güvenmemelidir. Bu nedenle, güvende olmak için, varsayılan varsayım, her HwBinder hizmetinin, hizmet tarafından sunulan işlemleri gerçekleştirmek için tüm istemcilerine eşit derecede yetkili muamelesi yapmasıdır.
2. HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi) system/core bileşenlerinden daha yüksek güvenlik sorunları görülme oranına sahip kod içerir ve yığının alt katmanlarına (donanıma kadar) erişime sahiptir, böylece Android güvenlik modelini atlama fırsatlarını artırır .

Güvenli hizmetler

Güvenli hizmetler şunları içerir:

• same_process_hwservice . Bu hizmetler (tanım gereği), istemci sürecinde çalışır ve bu nedenle, işlemin çalıştığı istemci etki alanıyla aynı erişime sahiptir.
• coredomain_hwservice . Bu hizmetler, 2. nedenle ilişkili riskler oluşturmaz.
• hal_configstore_ISurfaceFlingerConfigs . Bu hizmet, herhangi bir etki alanı tarafından kullanılmak üzere özel olarak tasarlanmıştır.
• hal_graphics_allocator_hwservice . Bu işlemler, uygulamaların erişmesine izin verilen surfaceflinger Binder hizmeti tarafından da sunulmaktadır.
• 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 daha yeni bir sürümüdür.

Kullanılabilir özellikler

Güvenli kabul edilmeyen tüm hwservices untrusted_app_visible_hwservice özniteliğine sahiptir. Karşılık gelen HAL sunucuları untrusted_app_visible_halserver özniteliğine sahiptir. Android 9 ile başlatılan cihazlar untrusted öznitelikleri KULLANMAMALIDIR.

Öneri:

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

  VEYA

• vendor HAL'lerine doğrudan erişime ihtiyaç duyan uygulamaların kendi tedarikçi firma tanımlı sepolicy etki alanı olmalıdır.

Dosya özelliği testleri

Android 9, belirli konumlardaki tüm dosyaların uygun özniteliklere sahip olmasını sağlayan derleme zamanı testleri içerir (örneğin, sysfs tüm dosyalar gerekli sysfs_type özniteliğine sahiptir).

Platform-kamu politikası

Platform-kamu politikası, yalnızca v1 ve v2'den platform politikalarının birliğini sürdürmeden Android 8.0 mimari modeline uymanın özüdür. Satıcılar, daha sonra satıcı politikasının bir parçası haline gelen kullanılabilir türler ve öznitelikler ve bu türler ve özniteliklere ilişkin kurallar içeren bir platform ilkesi alt kümesine tabi tutulur (örn. vendor_sepolicy.cil ).

Türler ve kurallar, satıcı tarafından oluşturulan ilkede otomatik olarak attribute_v N çevrilir, öyle ki platform tarafından sağlanan tüm türler sürümlü öznitelikler olur (ancak öznitelikler sürümlü değildir). Platform, satıcı politikasının işlemeye devam etmesini ve belirli bir sürüm için sağlanan kuralların dahil edilmesini sağlamak için sağladığı somut türleri uygun niteliklerle eşleştirmekten sorumludur. Platform-kamu politikası ve satıcı politikasının birleşimi, Android 8.0 mimarisi modelinin bağımsız platform ve satıcı yapılarına izin verme hedefini karşılar.

Öznitelik zincirlerine eşleme

İlke sürümleriyle eşlemek için öznitelikleri kullanırken, bir tür, bir öznitelik veya birden çok öznitelikle eşleşir ve bu türle etiketlenen nesnelerin, önceki türlerine karşılık gelen öznitelikler aracılığıyla erişilebilir olmasını sağlar.

Sürüm bilgisini ilke yazarından gizleme hedefini sürdürmek, sürümlü öznitelikleri otomatik olarak oluşturmak ve bunları uygun türlere atamak anlamına gelir. Genel statik tür durumunda, bu 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şlemenin oluşturulması önemsiz değildir (ve yukarıdaki örneklerde açıklanmıştır). Platform ilkesi koruyucuları, nesneler ve atanan etiketleri arasındaki ilişkiyi anlamayı ve bunun ne zaman olacağını belirlemeyi gerektiren, nesneler için geçiş noktalarında eşlemenin nasıl oluşturulacağını belirlemelidir. Geriye dönük uyumluluk için, bu karmaşıklığın, yukarı yönlü olabilecek tek bölüm olan platform tarafında yönetilmesi gerekir.

Sürüm yükseltmeleri

Basitlik için, Android platformu yeni bir sürüm dalı kesildiğinde bir sepolicy sürümü yayınlar. Yukarıda açıklandığı gibi, sürüm numarası PLATFORM_SEPOLICY_VERSION içinde bulunur ve MM.nn biçimindedir; burada MM SDK değerine karşılık gelir ve nn /platform/system/sepolicy. Ö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 . her zaman tam sayılar Örneğin, bir sürüme yönelik bir MR yükseltmesi system/sepolicy/public uyumsuz bir değişiklik gerektiriyorsa ancak bir API yükseltmesi gerektirmiyorsa, o zaman bu sepolicy sürümü şöyle olabilir: vN.1 . Bir geliştirme şubesinde bulunan sürüm, nakliye cihazlarında asla kullanılmaması gereken bir 10000.0 sürümüdür.

Yükseltme sırasında Android en eski sürümü kullanımdan kaldırabilir. Android, bir sürümün ne zaman kullanımdan kaldırılacağına ilişkin giriş için, o Android sürümünü çalıştıran ve hâlâ büyük platform güncellemeleri alan satıcı politikalarına sahip cihazların sayısını toplayabilir. Sayı belirli bir eşiğin altındaysa, bu sürüm kullanımdan kaldırılmıştır.

Birden fazla özelliğin performans etkisi

https://github.com/SELinuxProject/cil/issues/9 içinde açıklandığı gibi, bir türe atanan çok sayıda öznitelik, bir ilke önbelleğinin kaybolması durumunda performans sorunlarına yol açar.

Bunun Android'de bir sorun olduğu onaylandı, bu nedenle politika derleyicisi tarafından politikaya eklenen öznitelikleri ve kullanılmayan öznitelikleri kaldırmak için Android 8.0'da değişiklikler yapıldı . Bu değişiklikler performans gerilemelerini çözdü.

System_ext genel ve ürün genel politikası

Android 11'den başlayarak, system_ext ve ürün bölümlerinin belirlenmiş genel türlerini satıcı bölümüne aktarmalarına izin verilir. Platform kamu politikası gibi satıcı, otomatik olarak sürümlü özniteliklere çevrilen türleri ve kuralları kullanır; örneğin, type type_ N , burada N , satıcı bölümünün oluşturulduğu platformun sürümüdür.

system_ext ve ürün bölümleri aynı N platform sürümünü temel aldığında, yapı sistemi, kimlik içeren system_ext/etc/selinux/mapping/ N .cil ve product/etc/selinux/mapping/ N .cil için temel eşleme dosyaları oluşturur. type type_ N eşlemeler. Satıcı, type_ N sürümlü özniteliğiyle type erişebilir.

Yalnızca system_ext ve ürün bölümlerinin güncellenmesi durumunda, örneğin N N+1 (veya üstü), satıcı N kalırken, satıcı system_ext ve ürün bölümleri türlerine erişimi kaybedebilir. Bozulmayı önlemek için system_ext ve ürün bölümleri, dosyaları somut türlerden type_ N özniteliklerine eşleme sağlamalıdır. N+1 (veya üstü) system_ext ve ürün bölümleri ile N satıcıyı destekleyeceklerse, her ortak eşleme dosyalarının bakımından sorumludur.

Bunu yapmak için ortakların şunları yapması beklenir:

1. Oluşturulan temel eşleme dosyalarını N system_ext ve ürün bölümlerinden kaynak ağaçlarına kopyalayın.
2. Eşleme dosyalarını gerektiği gibi değiştirin.
3. Eşleme dosyalarını N+1 (veya üstü) system_ext ve ürün bölümlerine kurun.

Örneğin, N system_ext öğesinin foo_type adında bir genel türe sahip olduğunu varsayalım. Sonra system_ext/etc/selinux/mapping/ N .cil N system_ext bölümündeki N .cil şöyle görünecektir:

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

N+1 system_ext'e bar_type eklenirse ve N satıcı için bar_type foo_type eşlenmesi gerekiyorsa, N .cil şu adresten güncellenebilir:

(typeattributeset foo_type_N (foo_type))

ile

(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+1 system_ext'in foo_type ve bar_type öğelerine erişmeye devam edebilir.

SELinux içerik etiketlemesi

Sistem, platform ve satıcı politikası arasındaki ayrımı desteklemek için, SELinux içerik dosyalarını ayrı tutmak için farklı şekilde oluşturur.

Dosya bağlamları

Android 8.0, file_contexts için aşağıdaki değişiklikleri getirdi:

• Önyükleme sırasında aygıtta ek derleme yükünden kaçınmak için, file_contexts ikili biçimde mevcut olmaktan çıkar. Bunun yerine, {property, service}_contexts (7.0 öncesi oldukları gibi) gibi okunabilir, normal ifade metin dosyalarıdır.
• file_contexts iki dosya arasında bölünmüştür:
  • plat_file_contexts
    • Sepolicy dosyalarının düzgün çalışmasını sağlamak için tam olarak etiketlenmesi gereken /vendor bölümünün etiketleme bölümleri dışında, cihaza özel etiketleri olmayan Android platformu file_context .
    • Aygıtta /system/etc/selinux/plat_file_contexts adresindeki system bölümünde bulunmalı ve başlangıçta init tarafından satıcı file_context ile birlikte yüklenmelidir.
  • vendor_file_contexts
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan file_contexts birleştirilerek cihaza özel file_context oluşturulmuştur.
    • /vendor/etc/selinux/vendor_file_contexts vendor bölümünde kurulmalı ve başlangıçta init tarafından file_context platformuyla birlikte yüklenmelidir.

Özellik bağlamları

Android 8.0'da, property_contexts iki dosya arasında bölünmüştür:

• plat_property_contexts
  • Cihaza özel etiketleri olmayan Android platformu property_context .
  • /system/etc/selinux/plat_property_contexts konumunda system bölümünde bulunmalı ve başlangıçta init tarafından satıcı property_contexts ile birlikte yüklenmelidir.
• vendor_property_contexts
  • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan property_contexts birleştirilmesiyle oluşturulan cihaza özel property_context .
  • /vendor/etc/selinux/vendor_property_contexts adresindeki vendor bölümünde bulunmalı ve başlangıçta init tarafından platform property_context ile birlikte yüklenmelidir.

Hizmet bağlamları

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

• plat_service_contexts
  • servicemanager için Android platformuna özgü service_context . service_context cihaza özgü etiketleri yoktur.
  • /system/etc/selinux/plat_service_contexts konumunda system bölümünde bulunmalı ve başlangıçta servicemanager tarafından service_contexts satıcısı ile birlikte yüklenmelidir.
• vendor_service_contexts
  • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan service_contexts birleştirilmesiyle oluşturulan cihaza özgü service_context .
  • /vendor/etc/selinux/vendor_service_contexts adresindeki 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ı arasa da, tamamen uyumlu bir TREBLE aygıtı için vendor_service_contexts mevcut OLMAMALIDIR. Bunun nedeni, vendor ve system süreçleri arasındaki tüm etkileşimin hwservicemanager / hwbinder üzerinden geçmesi GEREKİR.
• plat_hwservice_contexts
  • Cihaza özgü etiketleri olmayan hwservicemanager için Android platformu hwservice_context .
  • /system/etc/selinux/plat_hwservice_contexts adresindeki 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şaret edilen dizinlerde bulunan hwservice_contexts birleştirilerek cihaza özel hwservice_context oluşturulmuştur.
  • /vendor/etc/selinux/vendor_hwservice_contexts adresindeki vendor bölümünde bulunmalı ve başlangıçta plat_service_contexts ile birlikte hwservicemanager tarafından yüklenmelidir.
• vndservice_contexts
  • Cihazın Boardconfig.mk dosyasında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan vndservice_contexts birleştirilerek oluşturulan vndservicemanager için cihaza özel service_context .
  • Bu dosya /vendor/etc/selinux/vndservice_contexts adresindeki vendor bölümünde bulunmalı ve başlangıçta vndservicemanager tarafından yüklenmelidir.

Uygulama bağlamları

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

• plat_seapp_contexts
  • Cihaza özel değişiklikleri olmayan Android platformu seapp_context .
  • /system/etc/selinux/plat_seapp_contexts adresindeki system bölümünde bulunmalıdır /system/etc/selinux/plat_seapp_contexts.
• vendor_seapp_contexts
  • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan seapp_contexts birleştirilmesiyle oluşturulan seapp_context platformuna cihaza özgü uzantı.
  • /vendor/etc/selinux/vendor_seapp_contexts adresindeki vendor bölümünde bulunmalıdır.

MAC izinleri

Android 8.0'da mac_permissions.xml dosyası iki dosya arasında bölünmüştür:

• Platform mac_permissions.xml
  • Cihaza özel değişiklikleri olmayan Android platformu mac_permissions.xml .
  • /system/etc/selinux/ adresindeki system bölümünde bulunmalıdır /system/etc/selinux/.
• Platform Dışı mac_permissions.xml
  • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan mac_permissions.xml oluşturulmuş mac_permissions.xml platformuna yönelik cihaza özel uzantı.
  • /vendor/etc/selinux/ adresindeki vendor bölümünde bulunmalıdır /vendor/etc/selinux/.