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 ilke tasarımı, platform ve satıcı ilkesi arasında ikili bir 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 ayrılmıştır. Genel bileşenler, bir platform sürümü için mevcut olması garanti edilen ilke ve ilgili altyapıdan oluşur. Bu ilke, satı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 oluşturma için, dışa aktarılan platform-genel ilkesi, 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, satıcı bağlam dosyaları tarafından sağlanan etiketleme kararlarında doğrudan kullanılabilir.

Android, platform ilkesinde dışa aktarılan somut türler ile her bir platform sürümü için ilgili sürümlenmiş öznitelikler arasında bir eşleme sağlar . 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, her platform sürümü için güncel bir eşleme dosyası tutularak sürdürülür; bu, kamu politikasında dışa aktarılan 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. Örneğin, satıcı /dev/foo olarak etiketlerse ve platform sonraki OTA'da /dev/foo olarak etiketlerse, 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:

• 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 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. Tür ve öznitelik ad çakışmalarını önlemek için, tüm satıcı bildirimleri np_ ile başlayan ad boşluklu olmalıdır.

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 belirlemek ve ad çakışmalarını önlemek için tüm satıcı mülklerinin kendi öneklerine sahip olduğundan emin olun:

Satıcılar ro.boot.* (çekirdek cmdline'dan 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. Satıcı özellikleri için SELinux etiketlerine benzer kurallar uygulanır (satıcı özellikleri için vendor_ ).

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ğundan, 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 Vendor Test Suite (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. /vendor politikasına /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şimde bulunduğu vendor bölümünün bölümlerini zaten etiketler; bu, platform süreçleri için SELinux kurallarının yazılabilmesini ve/veya vendor bölümünün bölümlerine erişilebilmesini sağlar. Örnekler:

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

• vendor_file , vendor bölümündeki tüm dosyalar için varsayılan etiket olmalıdır. Platform ilkesi, bunun doğrudan HAL uygulamalarına erişmesini 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.

Procfs (/proc)

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

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

Debugfs (/sys/kernel/debug)

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

Android 11'de debugfs üretim cihazlarına erişilemez veya bunlar yüklenemez. Cihaz üreticileri debugfs kaldırmalıdır.

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

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

Öneri: tracefs yalnızca platform etiketleyebilir.

Sysfs (/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 özgü 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ı 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 kombinasyonu aracılığıyla etiketlenir.

Öneri: /data/vendor dışında satıcı etiketlemesine izin vermeyin. Yalnızca platform /data data'nın diğer kısımlarını 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 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ı ilkesi aynı kalacak olsa da, yeni sysfs_A türü için ilke eksikliği nedeniyle v_domain erişimi kaybedecekti.

Ö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, somut tiplerin asla kullanılmadığı bir nitelik politikası oluşturmak için tüm tipler için yapılabilir. Uygulamada, bu yalnızca, satıcı ilkesinin bir parçası olarak oluşturulan platform genel ilkesi olarak tanımlanan ve sağlanan, platform ve satıcı arasında örtüşen ilke bölümleri için gereklidir.

Kamu politikasını sürümlü nitelikler olarak tanımlamak, iki ilke 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 nesneler için somut türlere nitelikler ekleyerek elde edilir.
• Politikayı kullanımdan kaldırma yeteneği . İlke kümelerini, karşılık gelen sürüm artık desteklenmez kaldırılabilir özniteliklere açıkça 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 bilgisi gerektirmeme hedefini karşılamak için Android 8.0, platform-kamu politikası 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 güvenlik ilkesine özel bir sürümdür.

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.

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 olan ilkeye 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. Bununla birlikte, 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ı

Her türün sonuna _v N ekleyerek otomatik olarak öznitelikler oluşturmak, öznitelikleri sürüm farklarındaki türlerle eşlemeden 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, (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ı 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 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

v1 → v2 yükseltme yaparken, platform ilkesi ş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; 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 etiketlediğinde (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 katılaştırmasını temsil ettiğinde, yeni tür özniteliği, öncekine karşılık gelen bir öznitelik zincirine geri bağlanmalıdır ( /sys/A öğesinin sysfs sysfs_A olarak değiştirilmesine benzer bir önceki örneğe benzer). Satıcı kodu, sysfs erişimine izin veren bir kurala dayanır ve bu kuralı yeni türün bir özniteliği olarak dahil etmesi gerekir.

v1 → v2 yükseltme yaparken, platform ilkesi ş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 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ı)

v1 → v2 yükseltme yaparken, platform ilkesi ş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ırılıyor (foo tipi)

v1 → v2 yükseltme yaparken, platform ilkesi ş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ı cinleri, mevcut olmayan izinlere ihtiyaç duyuyordu. 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, bir nesne yöneticisi kaldırıldığında ( ZygoteConnection nesne yöneticisi gibi) ortaya çıkar ve sorunlara neden olmaması gerekir. 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 süreçleri, ikili dosyaları, cihazları, alt sistemleri ve depolanan verileri tanımlamak için ihtiyaç duyulduğundan, yeni satıcı türleri 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 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, öznitelikler ve türler uygun şekilde uygulanmalıdır ve özelleştirilebilir etki alanlarına ( init gibi) belirli kuralların eklenmesi gerekebilir.

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 . vendor ve ana etki alanları arasında yola göre dosya paylaşmama gereksinimini ihlal eden tüm etki alanları için 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 /data/vendor kullanmalıdır.
  • Sistem /data/vendor kullanmamalıdır.
• system_executes_vendor_violators . Satıcı ikili dosyalarını yürütmeme gereksinimini 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'lerinin arkasında olmalıdır.

    VEYA

  • satıcı ikili dosyalarına coredomains gereken çekirdek alanlar satıcı bölümüne taşınmalı ve bu nedenle çekirdek etki alanı olmayı 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), system/core bileşenlerine göre güvenlik sorunlarının görülme oranı daha yüksek olan kodlar içerir ve yığının alt katmanlarına (donanımdan 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 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 ayrıca, 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 nitelikler

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 özelliklerden herhangi birini KULLANMAMALIDIR.

Öneri:

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

  VEYA

• vendor HAL'lerine doğrudan erişime ihtiyaç duyan uygulamalar, kendi satıcı tanımlı sepolicy etki alanına sahip olmalıdır.

Dosya özniteliği testleri

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

Platform-kamu politikası

Platform-kamu politikası, v1 ve v2'deki platform politikalarının birliğini korumadan 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ürleri ve öznitelikleri ve bu türler ve özniteliklere ilişkin kuralları içeren bir platform ilkesi alt kümesine maruz kalırlar (örneğin, vendor_sepolicy.cil ).

Türler ve kurallar, satıcı tarafından oluşturulan ilkede otomatik olarak, platform tarafından sağlanan tüm türler sürümlendirilmiş nitelikler olacak şekilde (ancak nitelikler sürümlendirilmemiş) nitelik_v attribute_v N çevrilir. 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 şeklindeki 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 türle etiketlenen nesnelere ö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 türlerin genel 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şlemeyi oluşturmak önemsiz değildir (ve yukarıdaki örneklerde açıklanmıştır). 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

Basit olması 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 , 25.0 için 24.0 , Nougat-MR1, Oreo için 26.0 , Oreo-MR1 için 27.0 ve Android 9 için 28.0 Uprev'ler değil. her zaman tam sayılar Örneğin, bir sürüme yönelik bir MR çarpması, system/sepolicy/public uyumsuz bir değişiklik gerektiriyorsa ancak bir API çarpması gerektirmiyorsa, bu sepolicy sürümü şöyle olabilir: vN.1 . Bir geliştirme dalında mevcut olan sürüm, asla sevkiyatta kullanılmayacak bir 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

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

Bunun Android'de bir sorun olduğu onaylandı, bu nedenle politika derleyicisi tarafından politikaya eklenen niteliklerin kaldırılması ve ayrıca kullanılmayan niteliklerin kaldırılması 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ümlenmiş özniteliklere çevrilen type ve kuralları kullanır, örneğin type_ N , burada N , satıcı bölümünün karşı 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 type

Yalnızca system_ext ve ürün bölümlerinin güncellenmesi durumunda, örneğin N N+1 (veya üzeri), satıcı N konumunda kalırken satıcı, system_ext türlerine ve ürün bölümlerine erişimi kaybedebilir. Kırılmayı önlemek için system_ext ve ürün bölümleri, somut türlerden type_ N özniteliklerine eşleme dosyaları sağlamalıdır. Her ortak, N+1 (veya daha yeni) 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 ortakların şunları yapması beklenir:

1. N system_ext ve ürün bölümlerinden oluşturulan temel eşleme dosyalarını 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 yükleyin.

Örneğin, N system_ext'in foo_type adında bir genel türü olduğunu varsayalım. Ardından, N system_ext bölümünde system_ext/etc/selinux/mapping/ N .cil 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 foo_type N satıcı için bar_type ile eşlenecekse, N .cil 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 satıcı, N+1 system_ext'in foo_type ve bar_type öğelerine erişmeye devam edebilir.

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, 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 var olmayı bırakır. 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ünür:
  • plat_file_contexts
    • /vendor bölümünün, sepolicy dosyalarının düzgün çalışmasını sağlamak için tam olarak etiketlenmesi gereken bölümlerinin etiketlenmesi dışında, cihaza özel etiketlere sahip olmayan Android platformu file_context .
    • /system/etc/selinux/plat_file_contexts system bölümünde bulunmalı ve init tarafından, satıcı file_context ile birlikte yüklenmelidir.
  • vendor_file_contexts
    • Aygıtın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından gösterilen dizinlerde bulunan file_contexts birleştirilmesiyle oluşturulan aygıta özgü file_context .
    • Satıcı bölümünde / vendor /vendor/etc/selinux/vendor_file_contexts ve 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ünür:

• plat_property_contexts
  • Cihaza özel etiketleri 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şturulmuş cihaza özel property_context .
  • /vendor/etc/selinux/vendor_property_contexts vendor bölümünde bulunmalı ve başlangıçta platform property_context ile birlikte init tarafından yüklenmelidir

Hizmet bağlamları

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

• plat_service_contexts
  • servicemanager için Android platformuna özel service_context . service_context cihaza özel etiketi yok.
  • /system/etc/selinux/plat_service_contexts system bölümünde bulunmalı ve başlangıçta servicemanager tarafından satıcı service_contexts ile birlikte yüklenmelidir.
• vendor_service_contexts
  • Cihazın service_context dosyalarında BOARD_SEPOLICY_DIRS tarafından gösterilen dizinlerde bulunan service_contexts birleştirilmesiyle oluşturulan cihaza özel Boardconfig.mk .
  • /vendor/etc/selinux/vendor_service_contexts 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, tam uyumlu bir TREBLE aygıtı için vendor_service_contexts OLMAMALIDIR. Bunun nedeni, vendor ve system süreçleri arasındaki tüm etkileşimin hwservicemanager / hwbinder geçmesi ZORUNLUDUR.
• plat_hwservice_contexts
  • Cihaza özel etiketlere sahip 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 hwservicemanager ile birlikte vendor_hwservice_contexts .
• vendor_hwservice_contexts
  • Cihazın hwservice_context dosyalarında BOARD_SEPOLICY_DIRS tarafından gösterilen dizinlerde bulunan hwservice_contexts birleştirilmesiyle oluşturulan cihaza özel Boardconfig.mk .
  • /vendor/etc/selinux/vendor_hwservice_contexts vendor bölümünde bulunmalı ve başlangıçta hwservicemanager tarafından hwservicemanager ile birlikte plat_service_contexts .
• vndservice_contexts
  • Cihazın service_context vndservicemanager tarafından gösterilen dizinlerde bulunan vndservice_contexts birleştirilmesiyle oluşturulan BOARD_SEPOLICY_DIRS için cihaza özel Boardconfig.mk .
  • Bu dosya /vendor/etc/selinux/vndservice_contexts vendor bölümünde bulunmalı ve başlangıçta vndservicemanager tarafından yüklenmelidir.

Seaapp bağlamları

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

• plat_seapp_contexts
  • Cihaza özel değişiklik içermeyen Android platformu seapp_context .
  • /system/etc/selinux/plat_seapp_contexts. adresindeki system bölümünde bulunmalıdır.
• 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 adresindeki vendor bölümünde bulunmalıdır.

MAC izinleri

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

• Platform mac_permissions.xml
  • Cihaza özel değişiklik içermeyen Android platformu mac_permissions.xml .
  • /system/etc/selinux/. adresindeki system bölümünde bulunmalıdır.
• Platform mac_permissions.xml
  • Cihazın Boardconfig.mk dosyalarında BOARD_SEPOLICY_DIRS tarafından gösterilen dizinlerde bulunan mac_permissions.xml oluşturulmuş platform mac_permissions.xml için cihaza özel uzantı.
  • /vendor/etc/selinux/. adresindeki vendor bölümünde bulunmalıdır.