Politika Uyumluluğu

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

Tiz tabanlı SELinux'un politika tasarım platformu ve satıcı politikası arasında bir ikili ayrım dikkate alır; satıcı bölümleri gibi bağımlılıklar getirirse, şema daha karmaşık hale platform < vendor < oem .

Android 8.0 ve sonraki sürümlerde, SELinux global politikası özel ve genel bileşenlere ayrılmıştır. Genel bileşenler, bir platform sürümü için kullanılabilir olması garanti edilen ilke ve ilgili altyapıdan oluşur. Bu ilke, sağlayıcıların, platform tarafından sağlanan ilkeyle birleştirildiğinde, bir cihaz için tam işlevsel bir ilkeyle sonuçlanan bir satıcı ilkesi dosyası oluşturmasını sağlamak için satıcı ilkesi yazarlarına sunulacaktır.

  • Sürüm için, ihraç platforma kamu politikası özellikler olarak yazılacaktır.
  • Politikası yazılı kolaylığı için, ihraç türden politika oluşturma sürecinin bir parçası olarak sürüm nitelikler dönüştürülecektir. Genel türler, satıcı bağlam dosyaları tarafından sağlanan etiketleme kararlarında doğrudan kullanılabilir.

Android platformu ilkesinde ihraç beton türleri ve her platformu versiyonu için gelen sürüm nitelikler arasında bir eşleme korur. Bu, nesneler bir türle etiketlendiğinde, önceki bir sürümde platform-genel ilkesi tarafından garanti edilen davranışı bozmamasını sağlar. Bu eşleme için güncel bir eşleme dosyası tutarak korunur her platformu sürümü kamu politikası ihraç her türü için öznitelik üyelik bilgilerini tutar.

Nesne sahipliği ve etiketleme

Politikayı Android 8.0 ve sonraki sürümlerde özelleştirirken, platform ve satıcı politikasını ayrı tutmak için her nesne için sahiplik açıkça tanımlanmalıdır. Satıcı etiketleri Örneğin, /dev/foo ve platform daha sonra etiket /dev/foo müteakip OTA içinde, tanımsız davranış olacaktır. SELinux için bu, bir etiketleme çakışması olarak kendini gösterir. Aygıt düğümü, en son uygulanan etikete çözümlenen yalnızca tek bir etikete sahip olabilir. Sonuç olarak:

  • Süreçler başarısız uygulanan etikete gerek erişim kaynağa erişimi kaybedecek.
  • Yanlış cihaz düğümü oluşturulduğu için Süreçler dosyaya kazanç erişim çıkabileceğinden.

Sistem özellikleri aynı zamanda sistemde tanımsız davranışa (SELinux etiketlemesinin yanı sıra) yol açabilecek adlandırma çakışmalarına da sahiptir. Özellikler, hizmetler, işlemler, dosyalar ve yuvalar dahil olmak üzere SELinux etiketine sahip herhangi bir nesne için platform ve satıcı etiketleri arasında çakışmalar meydana gelebilir. Bu sorunlardan kaçınmak için bu nesnelerin sahipliğini açıkça tanımlayın.

Etiket çakışmalarına ek olarak, SELinux tür/özellik adları da çakışabilir. Bir tür/öznitelik adı çakışması her zaman bir ilke derleyici hatasıyla sonuçlanır.

Tür/özellik ad alanı

SELinux, aynı türde/öznitelikte birden çok bildirime izin vermez. Yinelenen bildirimlere sahip politika derlemede başarısız olur. Tipi ve özellik adı çarpışmaları engellemek için tüm satıcı beyanları ile başlayan isim alanlı olmalıdır np_ .

type foo, domain; → type np_foo, domain;

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

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

Emlak Tipi Kabul edilebilir önekler
okunabilir vendor.
Sadece oku ro.vendor.
ro.boot.
ro.hardware.
kalici persist.vendor.

Satıcılar kullanmaya devam edebilirsiniz ro.boot.* Ve (çekirdek cmdline gelir ki) ro.hardware.* (Bariz donanımla ilgili mülkiyet).

İnit rc dosyalarında tüm satıcı hizmetler olmalıdır vendor. sistem dışı bölümlerin init rc dosyalarındaki hizmetler için. Benzer kurallar satıcı özellikleri için SELinux'un etiketlere (uygulanır vendor_ satıcı özellikleri için).

Dosya sahipliği

Dosyalar için çarpışmaları önlemek zordur çünkü hem platform hem de satıcı politikası tüm dosya sistemleri için yaygın olarak etiketler sağlar. Tür adlandırmanın aksine, çoğu çekirdek tarafından oluşturulduğu için dosyaların ad alanı pratik değildir. Bu çakış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 tarafından uygulanacaktır Vendor Testi Suite (VTS).

Sistem (/sistem)

Sadece sistem görüntüsü için etiket sağlamalıdır /system aracılığıyla bileşenleri file_contexts , service_contexts etiketler için ise, vb /system bileşenleri eklenir /vendor politikasını, bir çerçeve salt OTA güncellemesi mümkün olmayabilir.

Satıcı (/satıcı)

AOSP SELinux'un politikası zaten parçalarını etiketler vendor bölümü platformu işlemleri için SELinux'un kurallarını yazmaya olanak tanır ile platformu etkileşimde bulunduğunda, konuşabilecek ve / veya erişim parçaları için vendor bölümü. Örnekler:

/vendor yolu Platform tarafından sağlanan etiket Etikete bağlı olarak platform işlemleri
/vendor(/. * )? vendor_file Çerçeve, 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, belirli kurallar takip (aracılığıyla uygulanması gereken neverallows içinde ek dosyalar etiketlerken) vendor bölümü:

  • vendor_file tüm dosyalar için varsayılan etiket olmalıdır vendor bölümü. Platform ilkesi, bunun doğrudan HAL uygulamalarına erişmesini gerektirir.
  • Tüm yeni exec_types ilave vendor satıcı SEPolicy aracılığıyla bölme olmalıdır vendor_file_type niteliği. Bu, Neverallows aracılığıyla uygulanır.
  • Gelecekteki platformu / çerçeve güncellemeleri, başka önlemek etiketleme dosyaları ile çakışmaları önlemek için exec_types içinde vendor bölümü.
  • AOSP tanımlanan aynı işlem HAL'lere için tüm kütüphane bağımlılıklarını olarak etiketlenmesi gerekir same_process_hal_file.

Procfs (/proc)

Dosyalar /proc sadece kullanılarak işaretlenebilir genfscon etiketi. Android 7.0, her iki platformu ve satıcı politikası kullanılan genfscon etiket dosyalarına procfs .

Öneri: Sadece bir platform politikası etiketleri /proc . Eğer vendor süreçleri dosyalara erişim ihtiyacı /proc şu anda varsayılan etiket (etiketlenir proc ), satıcı politikası açıkça etiketlemek olmamalıdır ve bunun yerine jenerik kullanmalıdır proc satıcı alan adları için kuralları eklemeyi türü. Bu platform güncellemeleri yoluyla maruz gelecek çekirdek arayüzleri uyum sağlayan procfs ve gerektiğinde bunları açıkça etiketleyin.

Debugfs (/sys/kernel/debug)

Debugfs hem etiketli olabilir file_contexts ve genfscon . Android 7.0, Android 10, hem platformu ve satıcı etiket için debugfs .

Android 11, debugfs erişilemez veya üretim cihazlarında monte edilir. Cihaz üreticileri kaldırmalısınız debugfs .

Tracef'ler (/sys/kernel/debug/tracing)

Tracefs hem etiketli olabilir file_contexts ve genfscon . Android 7.0 yılında tek platform etiketler tracefs .

Öneri: etiketleyeceğine Sadece platformu tracefs .

Sysfs (/sys)

Dosyalar /sys ikisini de kullanarak etiketlenebilir file_contexts ve genfscon . Android 7.0, her iki platformu ve satıcı kullanım file_contexts ve genfscon etiket dosyalarına sysfs .

Öneri: platformu etiketleyeceğine sysfs cihaza özgü olmayan düğümleri. Aksi takdirde, yalnızca satıcı dosyaları etiketleyebilir.

tmpfs (/dev)

Dosyalar /dev etiketli olabilir file_contexts . Android 7.0'da hem platform hem de satıcı etiket dosyaları burada.

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

Kökler (/)

Dosyalar / de etiketlenebilir file_contexts . Android 7.0'da hem platform hem de satıcı etiket dosyaları burada.

Öneri: Sadece sistem dosyaları etiketleyeceğine / .

Veri (/veri)

Veri kombinasyonuyla etiketli file_contexts ve seapp_contexts .

Öneri: Disallow satıcı etiketleme dışında /data/vendor . Sadece platformu diğer kısımlarını etiketleyeceğine /data .

Uyumluluk özellikleri

SELinux ilkesi, belirli nesne sınıfları ve izinleri için kaynak ve hedef türleri arasındaki bir etkileşimdir. SELinux ilkesinden etkilenen her nesne (işlemler, dosyalar, vb.) yalnızca bir türe sahip olabilir, ancak bu türün birden çok özniteliğ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ürleri kullanıyorsa ve belirli bir nesnenin etiketi bu ilkelerden yalnızca birinde değişiyorsa, diğeri daha önce güvenilen erişimi kazanmış veya kaybetmiş olan ilkeyi 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ı kalacağını rağmen v_domain nedeniyle yeni politikasının eksikliği erişim kaybeder sysfs_A türü.

Öznitelikler açısından bir ilke tanımlayarak, temel alınan nesneye hem platform hem de satıcı kodu için ilkeye karşılık gelen bir özniteliğe sahip bir tür verebiliriz. Bu etkin beton tipleri hiç kullanılmamış burada bir nitelik-politikası oluşturmak için tüm türleri için yapılabilir. Uygulamada, bu, sadece tanımlanmış ve satıcı ilkenin bir parçası olarak yerleşik alır platform, kamu politikası olarak verilmiştir platform ve satıcı arasında üst üste politika bölümleri için gereklidir.

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

  • Emin olun satıcı kodu platformu güncellemeden sonra işe devam eder. Erişimi koruyarak, satıcı kodunun dayandığı nesnelere karşılık gelen nesneler için somut türlere nitelikler ekleyerek elde edilir.
  • Kullanımdan kaldırmak politikasına yeteneği. İlke kümelerini, karşılık gelen sürüm artık desteklenmez kaldırılabilen niteliklere net bir şekilde tanımlayarak elde edilir. Geliştirme, platformda devam edebilir, eski politikanın satıcı politikasında hala mevcut olduğunu ve yükseltildiğinde/eğer yükseltilirse otomatik olarak kaldırılacağını bilerek.

Politika yazılabilirliği

Politika geliştirme için belirli sürüm değişiklikleri hakkında bilgi gerektirmeme hedefini karşılamak için Android 8.0, platform-genel politika türleri ve bunların nitelikleri arasında bir eşleme içerir. Tür foo niteliği eşleştirilir foo_v N , N hedeflenen versiyonudur. vN tekabül PLATFORM_SEPOLICY_VERSION yapı değişkeni olup aşağıdaki MM.NN , MM platformu SDK numarasına karşılık gelen ve NN platform sepolicy belirli bir versiyonu.

Genel ilkedeki öznitelikler sürümlendirilmemiştir, bunun yerine iki bölüm arasındaki arabirimi sabit tutmak için platform 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ı olarak ihraç allow source_foo target_bar: class perm ; satıcı politikasının bir parçası olarak dahil edilmiştir. Sırasında derleme (karşılık gelen sürümünü içerir) o (dönüştürülmüş Common Intermediate Language (CIL) gösterilmiştir) cihazın satıcı kısmına gidecek politikasına dönüşür:

 (allow source_foo_vN target_bar_vN (class (perm)))

Satıcı politikası hiçbir zaman platformun ilerisinde olmadığından, önceki sürümlerle ilgilenmemelidir. Ancak, platform ilkesinin satıcı ilkesinin ne kadar geride olduğunu bilmesi, türlerine öznitelikler eklemesi ve sürümlü özniteliklere karşılık gelen ilkeyi ayarlaması gerekir.

Politika farklılıkları

Otomatik olarak ekleyerek özelliklerini oluştururken _v N her tür sonuna versiyonu fark dosyaları arasında türlerine niteliklerin haritalama olmadan hiçbir şey yapmaz. Android, öznitelikler için sürümler arasında bir eşleme ve bu özniteliklerle türlerin eşleştirilmesini sağlar. Bu, yukarıda belirtilen eşleme dosyalarında (CIL) gibi ifadelerle yapılır:

(typeattributeset foo_vN (foo))

Platform yükseltmeleri

Aşağıdaki bölüm, platform yükseltmeleri için senaryoları detaylandırmaktadır.

aynı tipler

Bu senaryo, bir nesne ilke sürümlerinde etiketleri değiştirmediğinde ortaya çıkar. Bu kaynak ve hedef türleri için aynıdır ve görülebilir /dev/binder etiketli, binder_device tüm bültenleri arasında. Dönüştürülmüş politikada şu şekilde temsil edilir:

binder_device_v1 … binder_device_vN

Ne zaman yükseltme dan v1v2 , platform politikası 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 türler

Bu senaryo, platform yeni bir tür eklediğinde ortaya çıkar; bu, yeni özellikler eklenirken veya ilke katılaştırması sırasında gerçekleşebilir.

  • Yeni özellik. Tür, daha önce var olmayan bir nesneyi etiketlerken (yeni bir hizmet süreci gibi), satıcı kodu daha önce onunla doğrudan etkileşime girmediğinden, karşılık gelen bir politika yoktur. Türe karşılık gelen yeni öznitelik, önceki sürümde bir özniteliğe sahip değildir ve bu nedenle, eşleme dosyasında o sürümü hedefleyen bir girişe ihtiyaç duymaz.
  • Politika sertleştirme. Türü ilke sertleştirme temsil ettiğinde, yeni tip özelliği, önceki ilgili özelliklerin bir zincire geri bağlantı gerekir (değiştirme, önceki örneğe benzer /sys/A dan sysfs için sysfs_A ). Satıcı kodu erişimi sağlayan bir kural dayanıyor sysfs ve yeni türde bir niteliği olarak bu kuralı içermesi gerekir.

Ne zaman yükseltme dan v1v2 , platform politikası 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 ortaya çıkar ve bu, alttaki nesne aşağıdaki 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, zaten var olan farklı bir etiket verilir. Bu, öznitelik eşlemelerinin bir birleşimini temsil eder: Satıcı kodu, altta yatan nesneye eskiden sahip olduğu öznitelikle erişebilmelidir, ancak sistemin geri kalanı artık yeni özniteliği ile ona erişebilmelidir.

Değiştirildiği öznitelik yeniyse, yeniden etiketleme, yeni tür durumundakiyle aynıdır, ancak mevcut bir etiket kullanıldığında, yeni tür eski özniteliğin eklenmesi, bu türle etiketlenen başka nesnelere de neden olur. yeni erişilebilir olmak. Bu, esasen platform tarafından yapılan şeydir ve uyumluluğu korumak için kabul edilebilir bir ödünleşim olarak kabul edilir.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Örnek Sürüm 1: Daralan türler (sysfs_A'nın kaldırılması)

Ne zaman yükseltme dan v1v2 , platform politikası 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ırılıyor (foo tipi)

Ne zaman yükseltme dan v1v2 , platform politikası 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 ortaya çıkar. Örneğin, Android eklendiğinde servicemanager eklenti, bul ve liste izinleri, kayıt isteyen satıcı cinleri yarattı nesne yöneticisi servicemanager mevcut değildi gerekli izinler. Android 8.0'da yalnızca platform politikası yeni sınıflar ve izinler ekleyebilir.

Satıcı ilkesi tarafından yaratılmış veya genişletilmiş olabilecek tüm etki alanlarının yeni sınıfı engellemeden kullanmasına izin vermek için platform ilkesinin aşağıdakine benzer bir kural içermesi gerekir:

allow {domain -coredomain} *:new_class perm;

Bu, satıcı görüntüsünün erişim kazandığından emin olmak için tüm arabirim (genel ilke) türleri için erişime izin veren bir ilke bile gerektirebilir. Bu, kabul edilemez bir güvenlik ilkesiyle sonuçlanırsa (hizmet yöneticisi değişikliklerinde olabileceği gibi), potansiyel olarak bir satıcı yükseltmesi zorunlu olabilir.

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

Bu senaryo, Nesne Yöneticisi (örneğin kaldırıldığında oluşan ZygoteConnection nesne yönetici) ve olmamalıdır sorunlara neden olmaktadır. Nesne yöneticisi sınıfı ve izinleri, satıcı sürümü artık onu kullanmayana kadar ilkede tanımlanmış olarak kalabilir. Bu, ilgili eşleme dosyasına tanımların eklenmesiyle 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ı, cihazları, alt sistemleri ve depolanan verileri tanımlamak için ihtiyaç duyulduğundan, satıcı politikası geliştirmenin merkezinde yer alır. Bu nedenle, satıcı tanımlı türlerin oluşturulmasına izin vermek zorunludur.

Satıcı ilkesi her zaman cihazdaki en eskisi olduğundan, tüm satıcı türlerini otomatik olarak ilkedeki niteliklere dönüştürmeye gerek yoktur. Platform, satıcı politikasında etiketlenmiş hiçbir şeye güvenmez çünkü platformun bununla ilgili bilgisi yoktur; Ancak, platform bu (gibi bu tür ile etiketlenmiş nesnelerle etkileşim için kullandığı özelliklerini ve kamu tiplerini sağlayacak domain , sysfs_type , vs.). Platform, bu nesnelerin düzgün etkileşim devam etmesi için, özellikleri ve tipleri de uygun bir şekilde uygulanabilir olması ve belirli kurallar (örneğin özelleştirilebilir etki ilave edilmesi gerekebilir init ).

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

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

İhlal eden nitelikler

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

  • data_between_core_and_vendor_violators . Arasındaki yol ile dosya paylaşımı değil gereksinimini ihlal tüm alan adları için Özellik vendor ve coredomains . Platform ve satıcı süreçleri, iletişim kurmak için diskteki dosyaları kullanmamalıdır (kararsız ABI). Öneri:
    • Satıcı kodu kullanmalıdır /data/vendor .
    • Sistem kullanmamalıdır /data/vendor .
  • system_executes_vendor_violators . (Dışındaki tüm sistem alanları için Özellik init ve shell domains satıcı ikilileri yürütme değil gereksinimini ihlal). 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'lerinin arkasında olmalıdır.

      VEYA

    • coredomains satıcı ikili ihtiyacı erişim sağlayıcı bölümü taşınmış ve böylece gerektiğini, olmayı bırak coredomain .

güvenilmeyen özellikler

Rasgele kod barındıran güvenilmeyen uygulamaların, bu tür uygulamalardan erişim için yeterince güvenli olduğu düşünülenler dışında HwBinder hizmetlerine erişimi olmamalıdır (aşağıdaki güvenli hizmetlere bakın). Bunun iki ana nedeni:

  1. HwBinder sunucuları, HIDL şu anda arayan UID bilgilerini göstermediğinden istemci kimlik doğrulaması gerçekleştirmez. HIDL bu tür verileri ifşa etmiş olsa bile, birçok HwBinder hizmeti ya uygulamaların (HAL'ler gibi) altında bir düzeyde çalışır ya da yetkilendirme için uygulama kimliğine güvenmemelidir. Bu nedenle, güvenli olmak için, varsayılan varsayım, her HwBinder hizmetinin, tüm istemcilerine hizmet tarafından sunulan işlemleri gerçekleştirme konusunda eşit olarak yetkilendirilmiş olarak davranmasıdır.
  2. HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi) den güvenlik sorunlarının daha yüksek insidans hızı ile kodu içeren system/core bileşenleri ve dolayısıyla Android güvenlik modeli atlayarak için fırsatlar artan (tüm yol donanıma aşağı) yığının alt katmanlarına erişimi .

Güvenli hizmetler

Güvenli hizmetler şunları içerir:

  • same_process_hwservice . Bu hizmetler (tanım gereği) istemci sürecinde çalışır ve dolayısıyla sürecin çalıştığı istemci etki alanıyla aynı erişime sahiptir.
  • coredomain_hwservice . Bu hizmetler neden #2 ile 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 de sunulmaktadır surfaceflinger uygulama erişimi için izin verilen Bağlayıcı hizmeti.
  • hal_omx_hwservice . Bu bir HwBinder versiyonudur mediacodec uygulama erişimi için izin verilen Bağlayıcı hizmeti.
  • hal_codec2_hwservice . Bu daha yeni bir sürümü hal_omx_hwservice .

Kullanılabilir nitelikler

Tüm hwservices güvenli kabul değil nitelik sahip untrusted_app_visible_hwservice . İlgili HAL sunucuları nitelik sahip untrusted_app_visible_halserver . Android 9 ZORUNLU kullanımına sunulacak cihazlar ya KULLANMAYIN untrusted niteliğini.

Öneri:

  • Güvenilmeyen uygulamalar bunun yerine satıcı HIDL HAL ile konuşan bir sistem hizmetiyle konuşmalıdır. Örneğin, uygulamalar konuşabilirsiniz binderservicedomain sonra, mediaserver (bir olan binderservicedomain için dönüş görüşmelerinde) hal_graphics_allocator .

    VEYA

  • Doğrudan erişim ihtiyaç Uygulamalar vendor HAL'lere kendi satıcı tarafından tanımlanan sepolicy alana sahip olmalıdır.

Dosya özniteliği testleri

Android 9 içerir inşa süresi testlerinde uygun özelliklere sahiptir belirli yerlerde tüm dosyaları sağlamak (olduğu gibi, tüm dosyalar sysfs gerekli olan sysfs_type özelliğini).

Platform-kamu politikası

Platform-genel politikası, v1 ve v2'deki platform politikalarının birliğini sürdürmeden Android 8.0 mimari modeline uymanın özüdür. Satıcılar kullanışlı türleri ve sonra satıcı politikasının parçası olur bu tür ve özelliklerine (yani üzerindeki özellik ve kuralları içeren bir platform politikasının bir alt maruz kalan vendor_sepolicy.cil ).

Türleri ve kurallar otomatik olarak satıcı tarafından oluşturulan ilkesinde çevrilir attribute_v N platforma Resim tipi özelliklerini sürüm öyle ki (ancak özellikler sürüm 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, bağımsız platform ve satıcı yapılarına izin verme Android 8.0 mimari modeli hedefini karşılar.

Öznitelik zincirlerine eşleme

İlke sürümlerine eşlemek için öznitelikler kullanılırken, bir tür bir özniteliğe veya birden çok özniteliğe eşlenir 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 bilgilerini ilke yazarından gizleme hedefini sürdürmek, sürümlendirilmiş öznitelikleri otomatik olarak oluşturmak ve bunları uygun türlere atamak anlamına gelir. Statik tiplerinin ortak bir durumda, bu açıktır: type_foo eşleştiren type_foo_v1 .

Gibi bir nesne, etiket değişimi için sysfssysfs_A veya mediaserveraudioserver Bu kurup, önemsiz olmayan (ve örnekler yukarıda tarif edilmiştir). Platform ilkesi sağlayıcıları, nesneler ve atanan etiketler arasındaki ilişkiyi anlamayı ve bunun ne zaman gerçekleştiğini 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, yükselebilecek 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 tarif edildiği gibi, versiyon numarası içerdiği PLATFORM_SEPOLICY_VERSION ve form ait MM.nn , MM SDK değerine karşılık geldiği ve nn muhafaza özel bir değerdir /platform/system/sepolicy. Örneğin, 19.0 KitKat'ta için, 21.0 Lollipop, 22.0 lolipop-MR1 için 23.0 Marshmallow için, 24.0 koz helvası için, 25.0 nugat-MR1 için, 26.0 Oreo için, 27.0 Oreo-MR1 için ve 28.0 Android 9. Uprevs için değildir her zaman tam sayılar Bir sürümleri için bir MR yumru uyumsuz bir değişiklik gerektirir Örneğin, system/sepolicy/public ancak bir API tümsek, ardından sepolicy versiyonu olabileceğini: vN.1 . Bir gelişme dalında versiyonu bulunan bir-asla kullanılmayacaktır-to-in-nakliye-cihazlarla 10000.0 .

Android, yukarı çıkarken en eski sürümü kullanımdan kaldırabilir. Bir sürümün ne zaman kullanımdan kaldırılacağına ilişkin girdi için Android, o Android sürümünü çalıştıran ve yine de büyük platform güncellemelerini 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ılır.

Birden çok özelliğin performans etkisi

Açıklandığı gibi https://github.com/SELinuxProject/cil/issues/9 , niteliklerin çok sayıda politika önbellek gereksinimi olması durumunda performans sorunları bir tür sonucu atanan.

Böylece bu, Android'de bir sorun olarak doğrulandı değişiklik yapılmadı politika derleyici tarafından politikasına eklenen nitelikleri kaldırmak, hem de kullanılmayan özelliklerini kaldırmak için Android 8.0. Bu değişiklikler performans gerilemelerini çözdü.

SELinux bağlam etiketleme

Platform ve satıcı sepolicy arasındaki ayrımı desteklemek için sistem, SELinux bağlam dosyalarını ayrı tutmak için farklı şekilde oluşturur.

Dosya bağlamları

Android 8.0 için aşağıdaki değişiklikler yapılmıştır file_contexts :

  • Açılışı sırasında Cihaza başka derleme yükünden kaçınmak için file_contexts ikili biçimde ortadan kalkıncaya. Bunun yerine, okunabilir, örneğin düzenli ifade metin dosyası {property, service}_contexts (onlar gibi önceden 7.0).
  • file_contexts iki dosya arasında bölünür:
    • plat_file_contexts
      • Android platformu file_context etiketleme parçaları haricinde hiçbir cihaz belirli etiketlere /vendor sepolicy dosyalarının düzgün işlemesini sağlamak için kesin olarak etiketlenmesi gerekir bölümü.
      • Bulunması gerekir system bölmenin /system/etc/selinux/plat_file_contexts cihazda ve yüklenemez init satıcı ile birlikte başında file_context .
    • vendor_file_contexts
      • Cihaza özel file_context birleştirerek inşa file_contexts dizinleri tarafından işaret bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk dosyaları.
      • Kurulacak olmalı /vendor/etc/selinux/vendor_file_contexts içinde vendor bölme ve yüklenemez init platformu ile birlikte başında file_context .

Mülk bağlamları

Android 8.0'da, property_contexts iki dosya arasındaki bölünmüş geçerli:

  • plat_property_contexts
    • Android platformu property_context hiçbir cihaza özel etiketleri bulunmaktadır.
    • Bulunması gerekir system bölmenin /system/etc/selinux/plat_property_contexts ve yüklenemez init satıcı ile birlikte başında property_contexts .
  • vendor_property_contexts
    • Cihaza özel property_context birleştirerek inşa property_contexts dizinleri tarafından işaret bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk dosyaları.
    • Bulunması gerekir vendor bölmenin /vendor/etc/selinux/vendor_property_contexts ve yüklenemez init platformu ile birlikte başında property_context

Hizmet bağlamları

Android 8.0'da, service_contexts aşağıdaki dosyalar arasındaki bölünmüş geçerli:

  • plat_service_contexts
    • Android platforma özel service_context için servicemanager . service_context hiçbir cihaza özel etiketleri bulunmaktadır.
    • Bulunması gerekir system bölmenin /system/etc/selinux/plat_service_contexts ve yüklenemez servicemanager satıcı ile birlikte başında service_contexts .
  • vendor_service_contexts
    • Cihaza özel service_context birleştirerek inşa service_contexts dizinleri tarafından işaret bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk dosyaları.
    • Bulunması gerekir vendor bölmenin /vendor/etc/selinux/vendor_service_contexts ve yüklenemez servicemanager platformu ile birlikte başında service_contexts .
    • Her ne kadar servicemanager önyükleme sırasında bu dosya için görünüyor, tamamen uyumlu bir için TREBLE cihazı vendor_service_contexts var ZORUNLU. Arasındaki tüm etkileşim Bunun nedeni vendor ve system süreçleri ile gitmek gerekir hwservicemanager / hwbinder .
  • plat_hwservice_contexts
    • Android platformu hwservice_context için hwservicemanager hiçbir cihaza özel etiketleri bulunmaktadır.
    • Bulunması gerekir system bölmenin /system/etc/selinux/plat_hwservice_contexts ve yüklenemez hwservicemanager birlikte başlangıcında vendor_hwservice_contexts .
  • vendor_hwservice_contexts
    • Cihaza özel hwservice_context birleştirerek inşa hwservice_contexts dizinleri tarafından işaret bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk dosyaları.
    • Bulunması gerekir vendor bölmenin /vendor/etc/selinux/vendor_hwservice_contexts ve yüklenemez hwservicemanager birlikte başlangıcında plat_service_contexts .
  • vndservice_contexts
    • Cihaza özel service_context için vndservicemanager birleştirerek inşa vndservice_contexts dizinleri tarafından işaret bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk .
    • Bu dosya bulunması gerekir vendor bölmenin /vendor/etc/selinux/vndservice_contexts ve yüklenemez vndservicemanager başında.

Seaapp bağlamları

Android 8.0'da, seapp_contexts iki dosya arasındaki bölünmüş geçerli:

  • plat_seapp_contexts
    • Android platformu seapp_context hiçbir cihaza özgü değişiklikler var.
    • Bulunması gerekir system bölmenin /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • Platform için Cihaza özgü uzatma seapp_context birleştirerek inşa seapp_contexts tarafından işaret dizinlerde bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk dosyaları.
    • Bulunması gerekir vendor bölmenin /vendor/etc/selinux/vendor_seapp_contexts .

MAC izinleri

Android 8.0'da, mac_permissions.xml iki dosya arasındaki bölünmüş geçerli:

  • Platform mac_permissions.xml
    • Android platformu mac_permissions.xml hiçbir cihaza özgü değişiklikler var.
    • Bulunması gerekir system bölmenin /system/etc/selinux/.
  • Sigara Platformu mac_permissions.xml
    • Platform için Cihaza özgü uzatma mac_permissions.xml inşa mac_permissions.xml tarafından işaret dizinlerde bulunan BOARD_SEPOLICY_DIRS cihazın içinde Boardconfig.mk dosyaları.
    • Bulunması gerekir vendor bölmenin /vendor/etc/selinux/.