Politika Uyumluluğu

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

Treble tabanlı SELinux politikası 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 üzeri 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 mevcut olması garanti edilen politika ve ilgili altyapıdan oluşur. Bu politika, satıcıların platform tarafından sağlanan politikayla birleştirildiğinde bir cihaz için tam işlevsel bir politikayla sonuçlanan bir satıcı politika dosyası oluşturmasını sağlamak için satıcı politika yazarlarına sunulacaktır.

  • Sürüm oluşturma için dışa aktarılan platform-genel politikası, nitelikler olarak yazılacaktır.
  • Politika yazımının kolaylığı için, dışa aktarılan türler, politika oluşturma sürecinin bir parçası olarak versiyonlanmış niteliklere dönüştürülecektir. Genel türler ayrıca satıcı bağlam dosyaları tarafından sağlanan etiketleme kararlarında doğrudan kullanılabilir.

Android, platform politikasında dışa aktarılan somut türler ile her platform sürümü için karşılık gelen sürümlendirilmiş öznitelikler arasında bir eşleme sağlar . Bu, nesneler bir türle etiketlendiğinde önceki sürümde platform genel 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 üyeliği bilgilerini tutan, her platform sürümü için bir eşleme dosyasının güncel tutulmasıyla sağlanır.

Nesne sahipliği ve etiketleme

Android 8.0 ve sonraki sürümlerde politikayı özelleştirirken, platform ve satıcı politikasını ayrı tutmak amacıyla her nesne için sahiplik açıkça tanımlanmalıdır. Örneğin, satıcı /dev/foo etiketlerse ve platform daha sonra sonraki bir OTA'da /dev/foo etiketlerse tanımsız davranış ortaya çıkacaktır. SELinux için bu, bir etiketleme çarpışması olarak ortaya çıkar. Cihaz düğümü, en son uygulanan etikete çözümlenen 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 kaybedecektir.
  • Yanlış aygıt düğümü oluşturulduğu için dosyaya erişim sağlayan işlemler bozulabilir.

Sistem özellikleri aynı zamanda sistemde tanımsız davranışlara yol açabilecek çarpışmaları adlandırma potansiyeline de sahiptir (aynı zamanda SELinux etiketlemesi için). Ö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 çarpışmalar meydana gelebilir. Bu sorunları önlemek için bu nesnelerin sahipliğini açıkça tanımlayın.

Etiket çarpışmalarına ek olarak SELinux türü/öznitelik adları da çakışabilir. Tür/öznitelik adı çarpışması her zaman politika derleyici hatasıyla sonuçlanacaktır.

Tür/özellik ad alanı

SELinux aynı tipte/öznitelikte birden fazla bildirime izin vermez. Yinelenen bildirimlere sahip politikanın derlenmesi başarısız olur. Tür ve öznitelik adı çakışmalarını önlemek için, tüm satıcı bildirimlerinin np_ ile başlayan ad alanına sahip olması gerekir.

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ı mülklerinin kendi öneklerine sahip olduğundan emin olun:

Emlak Tipi Kabul edilebilir önekler
kontrol özellikleri ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
okunabilir-yazılabilir vendor.
Sadece oku ro.vendor.
ro.boot.
ro.hardware.
kalıcı persist.vendor.

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ı hizmetlerinin vendor. sistem dışı bölümlerin init rc dosyalarındaki hizmetler için. Satıcı özellikleri için SELinux etiketlerine de benzer kurallar uygulanır (satıcı özellikleri için vendor_ ).

Dosya sahipliği

Platform ve satıcı politikasının her ikisi de 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 çakışmaları önlemek için bu bölümdeki dosya sistemlerine yönelik adlandırma yönergelerini izleyin. Android 8.0 için bunlar teknik yaptırımı olmayan önerilerdir. Gelecekte bu öneriler Satıcı Test Paketi (VTS) tarafından uygulanacaktır.

Sistem (/sistem)

Yalnızca sistem görüntüsü, file_contexts , service_contexts vb. aracılığıyla /system bileşenleri için etiketler sağlamalıdır. /system bileşenleri için etiketler /vendor politikasına 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şlemlerinin vendor bölümünün bölümleriyle konuşabilmesi ve/veya bunlara erişebilmesi için SELinux kurallarının yazılmasına olanak tanır. Örnekler:

/vendor yolu Platform tarafından sağlanan etiket Etikete bağlı olarak 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ü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 politikası, geçişli HAL uygulamalarına erişim için bunu gerektirir.
  • Satıcı SEPolicy aracılığıyla vendor bölümüne eklenen tüm yeni exec_types vendor_file_type niteliğine sahip olması gerekir. Bu, Neverallows aracılığıyla uygulanır.
  • Gelecekteki platform/çerçeve güncellemeleriyle çakışmaları önlemek için vendor bölümünde dosyaları exec_types dışında etiketlemekten kaçının.
  • AOSP tarafından tanımlanan aynı işlem HAL'lerine yönelik tüm kitaplık bağımlılıkları, same_process_hal_file.

Procf'ler (/proc)

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

Öneri: Yalnızca platform politikası etiketleri /proc . vendor işlemlerinin, şu anda varsayılan etiketle ( proc ) etiketlenmiş olan /proc içindeki dosyalara erişmesi gerekiyorsa, satıcı politikası bunları açıkça etiketlememeli ve bunun yerine satıcı etki alanlarına kural eklemek için genel proc türünü kullanmalıdır. Bu, platform güncellemelerinin, procfs aracılığıyla kullanıma sunulan gelecekteki çekirdek arayüzlerine uyum sağlamasına ve bunları gerektiğinde açıkça etiketlemesine olanak tanır.

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

Debugfs hem file_contexts hem de genfscon olarak etiketlenebilir. Android 7.0'dan Android 10'a kadar hem platform hem de satıcı etiketi debugfs .

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

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

Tracefs hem file_contexts hem de genfscon olarak etiketlenebilir. Android 7.0'da yalnızca platform tracefs etiketini kullanır.

Öneri: tracefs yalnızca platform etiketleyebilir.

Sistemler (/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 içindeki dosyaları etiketlemek için file_contexts ve genfscon kullanır.

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

tmpfs (/dev)

/dev içindeki dosyalar file_contexts ile etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket 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ı etiket dosyaları burada.

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

Veri (/veri)

Veriler, file_contexts ve seapp_contexts öğelerinin birleşimi aracılığıyla etiketlenir.

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

Uyumluluk özellikleri

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

Politika çoğunlukla mevcut türlere göre yazılır:

allow source_type target_type:target_class permission(s);

Bu işe yarar çünkü politika her türlü bilgiyle yazılmıştır. Ancak satıcı politikası ve platform politikası belirli türleri kullanıyorsa ve belirli bir nesnenin etiketi bu politikalardan yalnızca birinde değişirse, diğeri daha önce güvenilen erişim kazanılan veya kaybedilen politikayı 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, yeni sysfs_A türüne yönelik politika eksikliği nedeniyle v_domain erişimini kaybedecektir.

Bir politikayı nitelikler açısından tanımlayarak, temeldeki nesneye hem platform hem de satıcı kodu için politikaya karşılık gelen bir özniteliğe sahip bir tür verebiliriz. Bu, somut türlerin hiçbir zaman kullanılmadığı bir nitelik politikasını etkili bir şekilde oluşturmak için tüm türler için yapılabilir. Uygulamada bu, yalnızca satıcı politikasının bir parçası olarak oluşturulan platform kamu politikası olarak tanımlanan ve sağlanan, platform ile satıcı arasında örtüşen politika bölümleri için gereklidir.

Kamu politikasını sürümlendirilmiş nitelikler olarak tanımlamak, iki politika uyumluluk hedefini karşılar:

  • Satıcı kodunun platform güncellemesinden sonra çalışmaya devam ettiğinden emin olun . Satıcı kodunun dayandığı nesnelere karşılık gelen nesneler için somut türlere öznitelikler eklenerek erişim korunarak gerçekleştirilir.
  • Politikayı kullanımdan kaldırma yeteneği . Politika kümelerinin, karşılık geldikleri sürüm artık desteklenmediğinde kaldırılabilecek nitelikler halinde açıkça tanımlanmasıyla gerçekleştirilir. Satıcı politikasında eski politikanın hala mevcut olduğunu ve yükseltme yapıldığında/yükseltildiğinde otomatik olarak kaldırılacağını bilerek platformda geliştirme 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-genel politika türleri ve bunların nitelikleri arasında bir eşleme içerir. foo türü, foo_v N özniteliğine 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 , platform sepolicy'ye özgü bir sürümdür.

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

allow source_foo target_bar: class perm ; Satıcı politikasının bir parçası olarak dahil edilmiştir. Derleme sırasında (ilgili sürümü içerir), cihazın satıcı kısmına gidecek politikaya dönüştürülür (dönüştürülmüş Ortak Ara Dilde (CIL) gösterilir):

 (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 politikasının, satıcı politikasının ne kadar gerisinde olduğunu bilmesi, türlerine ilişkin öznitelikleri içermesi ve sürümlendirilmiş özniteliklere karşılık gelen politikayı ayarlaması gerekecektir.

Politika farklılıkları

Her türün sonuna _v N ekleyerek otomatik olarak öznitelikler oluşturmak, özniteliklerin sürüm farklılıkları arasındaki türlerle eşlenmesi olmadan hiçbir işe yaramaz. Android, niteliklere ilişkin sürümler arasında bir eşlemeyi ve türlerin bu niteliklerle eşlenmesini sürdürür. 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ümde platform yükseltmelerine ilişkin senaryolar ayrıntılı olarak anlatılmaktadır.

Aynı türler

Bu senaryo, bir nesnenin ilke sürümlerindeki etiketleri değiştirmemesi durumunda ortaya çıkar. 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ülen politikada şu şekilde temsil edilir:

binder_device_v1 … binder_device_vN

v1v2 yükseltme yaparken 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 türler

Bu senaryo, platform yeni bir tür eklediğinde ortaya çıkar ve bu, 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 süreci gibi) etiketlerken, satıcı kodu daha önce onunla doğrudan etkileşime girmedi, dolayısıyla karşılık gelen bir politika mevcut değil. Türe karşılık gelen yeni özniteliğin önceki sürümde bir özniteliği yoktur ve bu nedenle eşleme dosyasında bu sürümü hedefleyen bir girişe gerek yoktur.
  • Politikanın sertleştirilmesi Tür politika sağlamlaştırmayı temsil ettiğinde, yeni tür özniteliğinin öncekine karşılık gelen bir öznitelik zincirine geri bağlanması gerekir (önceki örnekte /sys/A sysfs sysfs_A değiştirilmesine benzer şekilde). Satıcı kodu, sysfs erişimi sağlayan bir kurala dayanır ve bu kuralı yeni türün bir özelliği olarak dahil etmesi gerekir.

v1v2 yükseltme yaparken 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 ortaya çıkar ve temeldeki nesne şu durumlarda gerçekleşebilir:

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

Politikanın gevşetilmesi sırasında bir tür kaldırılır ve bu türle etiketlenen nesneye, halihazırda var olan farklı bir etiket verilir. Bu, öznitelik eşlemelerinin birleştirilmesi anlamına gelir: Satıcı kodunun, eskiden sahip olduğu öznitelikle temel nesneye hala erişebilmesi gerekir, ancak sistemin geri kalanı artık ona yeni özniteliğiyle erişebilmelidir.

Değiştirildiği öznitelik yeniyse, yeniden etiketleme yeni tür durumundakiyle 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 aslında platform tarafından yapılan şeydir ve uyumluluğu sürdürmek için kabul edilebilir bir ödün olarak kabul edilir.

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Örnek Versiyon 1: Türleri daraltma (sysfs_A'yı kaldırma)

v1v2 yükseltme yaparken 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 Versiyon 2: Tamamen kaldırma (foo tipi)

v1v2 yükseltme yaparken 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 ortaya çıkar. Örneğin, Android, ekleme, bulma ve listeleme izinlerini oluşturan servicemanager nesne yöneticisini eklediğinde, servicemanager kaydolmak isteyen satıcı arka plan programlarının mevcut olmayan izinlere ihtiyacı vardı. Android 8.0'da yalnızca platform politikası yeni sınıflar ve izinler ekleyebilir.

Satıcı politikası tarafından oluşturulmuş veya genişletilmiş olabilecek tüm etki alanlarının yeni sınıfı engelleme olmaksızın 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 politikayı bile gerektirebilir. Bunun kabul edilemez bir güvenlik politikasıyla sonuçlanması durumunda (servis yöneticisi değişikliklerinde olabileceği gibi), potansiyel olarak satıcı yükseltmesi zorunlu olabilir.

Sınıf/izinler kaldırıldı

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

Yeni/yeniden etiketlenen 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ı tarafından tanımlanan 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 otomatik olarak politikadaki niteliklere dönüştürmeye gerek yoktur. Platform, satıcı politikasında etiketlenen hiçbir şeye güvenmez çünkü platformun bu konuda hiçbir bilgisi yoktur; ancak platform, bu türlerle etiketlenmiş nesnelerle ( domain , sysfs_type vb. gibi) etkileşim kurmak için kullandığı öznitelikleri ve genel türleri sağlayacaktır. Platformun bu nesnelerle doğru şekilde etkileşime girmeye devam etmesi için niteliklerin ve türlerin uygun şekilde uygulanması gerekir ve özelleştirilebilir alanlara ( init gibi) belirli kuralların 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 başlatılan cihazlar kullanmamalıdır.

İhlal edenin özellikleri

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

  • data_between_core_and_vendor_violators . vendor ve coredomains arasında dosyaların yola göre paylaşılmaması gerekliliğini ihlal eden tüm alan adları için özellik. 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ın yürütülmeme gerekliliğini ihlal eden tüm sistem etki alanlarına ( init ve shell domains hariç) ilişkin ö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ına olan 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 bu nedenle coredomain olmayı bırakmalı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 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 şunlardır:

  1. HwBinder sunucuları istemci kimlik doğrulaması gerçekleştirmez çünkü HIDL şu anda arayanın UID bilgilerini açığa çıkarmaz. HIDL bu tür verileri açığa çıkarmış olsa bile birçok HwBinder hizmeti ya uygulamaların (HAL'ler gibi) altında bir seviyede ç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 müşterilerine, hizmet tarafından sunulan işlemleri gerçekleştirme konusunda eşit yetkili olarak davrandığıdır.
  2. HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi), system/core bileşenlerine göre daha yüksek güvenlik sorunlarına sahip kod içerir ve yığının alt katmanlarına (donanımlara kadar) erişime sahiptir, böylece Android güvenlik modelini atlama fırsatları artar .

Güvenli hizmetler

Güvenli hizmetler şunları içerir:

  • same_process_hwservice . Bu hizmetler (tanım gereği) istemcinin sürecinde çalışır ve dolayısıyla sürecin çalıştığı istemci etki alanıyla aynı erişime sahiptir.
  • coredomain_hwservice . Bu hizmetler 2 numaralı nedenden kaynaklanan riskler oluşturmaz.
  • hal_configstore_ISurfaceFlingerConfigs . Bu hizmet, herhangi bir alan adı tarafından kullanılmak üzere özel olarak tasarlanmıştır.
  • hal_graphics_allocator_hwservice . Bu işlemler aynı zamanda 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 sayılmayan tüm hwservices untrusted_app_visible_hwservice özniteliğine sahiptir. İlgili HAL sunucuları untrusted_app_visible_halserver özelliğine sahiptir. Android 9 ile başlatılan cihazlar, untrusted özelliklerden herhangi birini 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 (bu bir binderservicedomain ) ile de hal_graphics_allocator ile konuşabilir.

    VEYA

  • vendor HAL'lerine doğrudan erişime ihtiyaç duyan uygulamaların kendi satıcı tanımlı sepolicy etki alanına sahip olması gerekir.

Dosya öznitelik testleri

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

Platform-kamu politikası

Platform genel politikası, yalnızca v1 ve v2'deki platform politikalarının birliğini korumadan Android 8.0 mimari modeline uymanın temelidir. Satıcılar, daha sonra satıcı politikasının bir parçası haline gelen, kullanılabilir türleri ve nitelikleri ve bu türler ve niteliklere ilişkin kuralları içeren bir platform politikası alt kümesine maruz kalır (ör. vendor_sepolicy.cil ).

Türler ve kurallar, satıcı tarafından oluşturulan politikada otomatik olarak attribute_v N çevrilir, böylece platform tarafından sağlanan tüm türler sürümlendirilmiş öznitelikler olur (ancak öznitelikler sürümlendirilmez). 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ürlerin uygun niteliklerle eşleştirilmesinden sorumludur. Platform-genel politika ve satıcı politikasının birleşimi, bağımsız platform ve satıcı yapılarına izin veren Android 8.0 mimari modeli hedefini karşılıyor.

Özellik zincirlerine eşleme

İlke sürümleriyle eşlemek için öznitelikler kullanıldığında, bir tür bir öznitelikle veya birden çok öznitelikle eşleşir ve türle etiketlenen nesnelere, önceki türlerine karşılık gelen öznitelikler aracılığıyla erişilebilmesi sağlanır.

Sürüm bilgisini ilke yazarından gizleme hedefini sürdürmek, sürümlendirilmiş özniteliklerin otomatik olarak oluşturulması ve bunların uygun türlere atanması anlamına gelir. Statik türlerin genel durumunda bu basittir: type_foo type_foo_v1 ile eşleşir.

sysfssysfs_A veya mediaserveraudioserver 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 politikasını sürdürenlerin, nesneler ve onlara atanan etiketler arasındaki ilişkinin anlaşılmasını ve bunun ne zaman gerçekleşeceğinin belirlenmesini gerektiren, nesneler için geçiş noktalarında eşlemenin nasıl oluşturulacağını belirlemesi gerekir. 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 açısından, 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 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 . Uprev'ler değildir. her zaman tam sayılar. Örneğin, bir sürümdeki MR artışı system/sepolicy/public uyumsuz bir değişiklik gerektiriyor ancak bir API artışı gerektirmiyorsa bu sepolicy sürümü şu şekilde olabilir: vN.1 . Bir geliştirme dalında mevcut olan sürüm, nakliye cihazlarında asla kullanılmayan 10000.0 sürümüdür.

Android, güncelleme sırasında 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 sağlamak için Android, satıcı politikalarına sahip, o Android sürümünü çalıştıran ve hâlâ önemli platform güncellemelerini alan cihazların sayısını toplayabilir. Sayı belirli bir eşiğin altındaysa o sürüm kullanımdan kaldırılır.

Birden çok özelliğin performans etkisi

https://github.com/SELinuxProject/cil/issues/9 adresinde açıklandığı gibi, bir türe atanan çok sayıda öznitelik, politika önbelleğinin kaçırılması 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 özellikleri 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, belirlenen genel türlerini satıcı bölümüne aktarmalarına izin verilmektedir. Platform genel politikası gibi, satıcı da otomatik olarak versiyonlanmış ö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ı platform sürümü N temel aldığında, yapı sistemi, system_ext/etc/selinux/mapping/ N .cil ve product/etc/selinux/mapping/ N .cil için kimlik içeren temel eşleme dosyaları oluşturur. type type_ N eşlemeler. Satıcı, type_ N sürümlü niteliğiyle type erişebilir.

Yalnızca system_ext ve ürün bölümlerinin güncellenmesi durumunda, örneğin N N+1 (veya daha sonra) satıcı N kalırken, satıcı system_ext ve ürün bölümleri türlerine erişimini kaybedebilir. Kırılmayı önlemek için, system_ext ve ürün bölümleri, dosyaların somut türlerden type_ N niteliklerine eşlenmesini sağlamalıdır. Her iş ortağı, N+1 (veya üzeri) system_ext ve ürün bölümleriyle N satıcıyı destekleyecekse, eşleme dosyalarının bakımından sorumludur.

Bunu yapmak için ortaklardan beklenenler:

  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 üzeri) system_ext ve ürün bölümlerine yükleyin.

Örneğin, N system_ext'in foo_type adında bir ortak türe sahip olduğunu varsayalım. Daha sonra N system_ext bölümündeki system_ext/etc/selinux/mapping/ 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 ile 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 kuruldu. N satıcı, N+1 system_ext'in foo_type ve bar_type öğelerine erişmeye devam edebilir.

SELinux bağlamları etiketlemesi

Platform ve satıcı politikası arasındaki ayrımı desteklemek için sistem, SELinux içerik dosyalarını ayrı tutacak şekilde 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ünü önlemek için, file_contexts ikili formdaki varlığı sona erer. Bunun yerine, {property, service}_contexts (7.0 öncesi oldukları gibi) gibi okunabilir, düzenli ifade metin dosyalarıdırlar.
  • 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 parçaları dışında, cihaza özel etiketleri olmayan Android platformu file_context .
      • Cihazdaki /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ştirilmesiyle oluşturulan cihaza özel file_context .
      • vendor bölümünde /vendor/etc/selinux/vendor_file_contexts konumuna kurulmalı ve başlangıçta init tarafından file_context platformuyla birlikte yüklenmelidir.

Mülk bağlamları

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

  • plat_property_contexts
    • Cihaza özel etiketi olmayan Android platformu property_context .
    • /system/etc/selinux/plat_property_contexts adresindeki system bölümünde bulunmalı ve satıcı property_contexts ile birlikte başlangıçta init tarafından 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 platform property_context ile birlikte başlangıçta init tarafından 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 özel service_context . service_context cihaza özel etiketleri yoktur.
    • /system/etc/selinux/plat_service_contexts adresindeki system bölümünde bulunmalı ve satıcı service_contexts ile birlikte başlangıçta servicemanager tarafından 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 özel service_context .
    • /vendor/etc/selinux/vendor_service_contexts adresindeki vendor bölümünde bulunmalı ve service_contexts platformuyla birlikte başlangıçta servicemanager tarafından 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 işlemleri arasındaki tüm etkileşimin hwservicemanager / hwbinder üzerinden geçmesi GEREKLİDİR.
  • plat_hwservice_contexts
    • Cihaza özel etiketleri olmayan hwservicemanager için hwservice_context Android platformu.
    • /system/etc/selinux/plat_hwservice_contexts adresindeki system bölümünde bulunmalı ve başlangıçta vendor_hwservice_contexts ile birlikte hwservicemanager tarafından yüklenmelidir.
  • vendor_hwservice_contexts
    • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından işaret edilen dizinlerde bulunan hwservice_contexts birleştirilmesiyle oluşturulan cihaza özel hwservice_context .
    • /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ştirilmesiyle 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.

Seapp bağlamları

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

  • plat_seapp_contexts
    • Cihaza özel hiçbir değişikliği 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şturulmuş, seapp_context platformuna yönelik cihaza özel uzantı.
    • /vendor/etc/selinux/vendor_seapp_contexts konumundaki vendor bölümünde bulunmalıdır.

MAC izinleri

Android 8.0'da mac_permissions.xml iki dosyaya bölünmüştür:

  • mac_permissions.xml platformu
    • Cihaza özel hiçbir değişikliği 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/.