Bu makale, Android'in, yeni platform SELinux ayarlarının eski satıcı SELinux ayarlarından farklı olabileceği platform OTA'ları ile politika uyumluluğu sorunlarını nasıl ele aldığını açıklamaktadır.
Tiz tabanlı SELinux politika tasarımı, platform ve satıcı politikası arasındaki ikili ayrımı dikkate alır; satıcı bölümleri platform
< vendor
< oem
gibi bağımlılıklar oluşturursa şema daha karmaşık hale gelir.
Android 8.0 ve sonraki sürümlerde, SELinux global politikası özel ve genel bileşenlere bölünmüştür. Genel bileşenler, bir platform sürümü için kullanılabilir olması garanti edilen ilke ve ilişkili altyapıdan oluşur. Bu politika, satıcıların, platform tarafından sağlanan ilkeyle birleştirildiğinde bir cihaz için tam işlevli bir ilkeyle sonuçlanan bir satıcı ilke dosyası oluşturmasını sağlamak için satıcı ilkesi yazarlarına sunulacaktır.
- Versiyon oluşturma için, dışa aktarılan platform-genel politikası nitelikler olarak yazılacaktır.
- İlke yazma kolaylığı için, dışa aktarılan türler, ilke oluşturma sürecinin bir parçası olarak sürümlü özniteliklere dönüştürülecektir. Genel türler, doğrudan satıcı bağlam dosyaları tarafından sağlanan etiketleme kararlarında da kullanılabilir.
Android, platform ilkesinde dışa aktarılan somut türler ile her platform sürümü için karşılık gelen sürümlü öznitelikler arasında bir eşleme sağlar . Bu, nesneler bir türle etiketlendiğinde, önceki bir sürümde platform-kamu politikası tarafından garanti edilen davranışı bozmamasını sağlar. Bu eşleme, kamu politikasında dışa aktarılan her tür için öznitelik üyelik bilgilerini tutan her platform sürümü için bir eşleme dosyasını güncel tutarak korunur.
Nesne sahipliği ve etiketleme
Android 8.0 ve sonraki sürümlerde politikayı özelleştirirken, platform ve satıcı politikasını ayrı tutmak için her bir nesne için sahiplik açıkça tanımlanmalıdır. Örneğin, sağlayıcı /dev/foo
etiketlerse ve platform daha sonra bir sonraki OTA'da /dev/foo
etiketlerse, tanımsız davranış olacaktır. SELinux için bu, etiketleme çakışması olarak kendini gösterir. Cihaz düğümü, en son hangi etiketin uygulandığını çözen yalnızca tek bir etikete sahip olabilir. Sonuç olarak:
- Başarısız bir şekilde uygulanan etikete erişmesi gereken işlemler, kaynağa erişimi kaybeder.
- Dosyaya erişim sağlayan işlemler, yanlış aygıt düğümü oluşturulduğundan bozulabilir.
Sistem özellikleri ayrıca, sistemde tanımsız davranışa neden olabilecek adlandırma çarpışmaları potansiyeline de sahiptir (ayrıca SELinux etiketlemesi için). Özellikler, hizmetler, işlemler, dosyalar ve soketler dahil olmak üzere bir SELinux etiketine sahip herhangi bir nesne için platform ve satıcı etiketleri arasında çakışmalar meydana gelebilir. Bu sorunları önlemek için, bu nesnelerin sahipliğini açıkça tanımlayın.
Etiket çakışmalarına ek olarak, SELinux türü/öznitelik adları da çakışabilir. Tür/öznitelik adı çakışması her zaman bir ilke derleyici hatasına neden olur.
Tür/öznitelik ad aralığı
SELinux, aynı türde/öznitelikte birden çok bildirime izin vermez. Yinelenen bildirimlere sahip politika derlemede başarısız olur. Tür ve öznitelik adı çakışmalarını önlemek için, tüm satıcı bildirimleri np_
ile başlayarak ad alanına yerleştirilmelidir.
type foo, domain; → type np_foo, domain;
Sistem özelliği ve süreç etiketleme sahipliği
Etiketleme çakışmalarından kaçınmak en iyi şekilde özellik ad alanları kullanılarak çözülür. Platform özelliklerini kolayca tanımlamak ve dışa aktarılan platform özelliklerini yeniden adlandırırken veya eklerken ad çakışmalarını önlemek için tüm satıcı özelliklerinin kendi ön eklerine sahip olduğundan emin olun:
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ı hizmetleri vendor.
sistem dışı bölümlerin init rc dosyalarındaki hizmetler için. Benzer kurallar satıcı özellikleri için SELinux etiketlerine uygulanır (satıcı özellikleri için vendor_
).
Dosya sahipliği
Hem platform hem de satıcı politikası genel olarak tüm dosya sistemleri için etiketler sağladığından, dosyalar için çakışmaları önlemek zordur. Tür adlandırmanın aksine, dosyaların ad alanı, çoğu çekirdek tarafından oluşturulduğundan pratik değildir. Bu çarpışmaları önlemek için bu bölümdeki dosya sistemleri için adlandırma kılavuzunu izleyin. Android 8.0 için bunlar, teknik yaptırımı olmayan önerilerdir. Gelecekte, bu öneriler Vendor Test Suite (VTS) tarafından uygulanacaktır.
Sistem (/sistem)
Yalnızca sistem görüntüsü, file_contexts
, service_contexts
vb. yoluyla /system
bileşenleri için etiketler sağlamalıdır. /vendor
ilkesinde /system
bileşenleri için etiketler eklenirse, yalnızca çerçeve OTA güncellemesi mümkün olmayabilir.
Satıcı (/satıcı)
AOSP SELinux politikası, platformun etkileşime girdiği vendor
bölümünün bölümlerini zaten etiketler; bu, platform işlemleri için vendor
bölümünün konuşabilmesi ve/veya bölümlerine erişebilmesi için SELinux kurallarının yazılmasını sağlar. Örnekler:
/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 ilkesi, doğrudan geçişli HAL uygulamalarına erişmek için bunu gerektirir. - Satıcı SEPolicy aracılığıyla
vendor
bölümüne eklenen tüm yeniexec_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ündeexec_types
dışındaki dosyaları etiketlemekten kaçının. - AOSP tarafından tanımlanan aynı işlem HAL'leri için tüm kitaplık bağımlılıkları
same_process_hal_file.
İşlemler (/işlem)
/proc
içindeki dosyalar yalnızca genfscon
etiketi kullanılarak etiketlenebilir. Android 7.0'da, hem platform hem de tedarikçi politikası genfscon
procfs
içindeki dosyaları etiketlemek için kullandı.
Öneri: Yalnızca platform politikası etiketleri /proc
. vendor
işlemlerinin, şu anda varsayılan etiketle ( proc
) etiketlenmiş /proc
içindeki dosyalara erişmesi gerekiyorsa, satıcı ilkesi bunları açıkça etiketlememeli ve bunun yerine satıcı etki alanlarına kurallar eklemek için genel proc
türünü kullanmalıdır. Bu, platform güncellemelerinin procfs
aracılığıyla ortaya çıkan gelecekteki çekirdek arabirimlerini barındırmasına ve gerektiğinde bunları açıkça etiketlemesine olanak tanır.
Hata ayıklamalar (/sys/kernel/debug)
Debugfs
hem file_contexts
hem de genfscon
içinde etiketlenebilir. Android 7.0'dan Android 10'a, hem platform hem de satıcı etiketi debugfs
.
Android 11'de debugfs
erişilemez veya üretim cihazlarına bağlanamaz. Cihaz üreticileri debugfs
kaldırmalıdır.
İzler (/sys/kernel/debug/tracing)
Tracefs
hem file_contexts
hem de genfscon
içinde etiketlenebilir. Android 7.0'da yalnızca platform tracefs
olarak etiketlenir.
Öneri: tracefs
yalnızca platform etiketleyebilir.
Sysf'ler (/sys)
/sys
içindeki dosyalar hem file_contexts
hem de genfscon
kullanılarak etiketlenebilir. Android 7.0'da, hem platform hem de satıcı, sysfs
dosyaları etiketlemek için file_contexts
ve genfscon
kullanır.
Öneri: Platform, cihaza özel olmayan sysfs
düğümlerini etiketleyebilir. Aksi takdirde, yalnızca satıcı dosyaları etiketleyebilir.
tmpfs (/dev)
/dev
içindeki dosyalar file_contexts
içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiketi dosyaları burada.
Öneri: Satıcı, yalnızca /dev/vendor
içindeki dosyaları etiketleyebilir (örneğin, /dev/vendor/foo
, /dev/vendor/socket/bar
).
Kökler (/)
/
içindeki dosyalar file_contexts
içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiketi dosyaları burada.
Öneri: Yalnızca sistem /
içindeki dosyaları etiketleyebilir.
Veri (/veri)
Veriler, file_contexts
ve seapp_contexts
kombinasyonuyla etiketlenir.
Öneri: /data/vendor
dışında satıcı etiketlemesine izin vermeyin. /data
öğesinin diğer bölümlerini yalnızca platform etiketleyebilir.
Uyumluluk özellikleri
SELinux ilkesi, belirli nesne sınıfları ve izinleri için kaynak ve hedef türleri arasındaki bir etkileşimdir. SELinux politikasından etkilenen her nesnenin (işlemler, dosyalar vb.) yalnızca bir türü olabilir, ancak bu türün birden fazla özelliği olabilir.
Politika çoğunlukla mevcut türler açısından yazılır:
allow source_type target_type:target_class permission(s);
Bu işe yarar, çünkü politika her türden bilgiyle yazılmıştır. Ancak satıcı ilkesi ve platform ilkesi belirli türler kullanıyorsa ve belirli bir nesnenin etiketi bu ilkelerden yalnızca birinde değişirse, diğeri daha önce güvenilen erişim kazanmış veya kaybetmiş bir ilke içerebilir. Örneğin:
File_contexts: /sys/A u:object_r:sysfs:s0 Platform: allow p_domain sysfs:class perm; Vendor: allow v_domain sysfs:class perm;
Şu şekilde değiştirilebilir:
File_contexts: /sys/A u:object_r:sysfs_A:s0
Satıcı politikası aynı kalsa da v_domain
, yeni sysfs_A
türü için politika olmaması nedeniyle erişimi kaybeder.
Nitelikler açısından bir ilke tanımlayarak, temel nesneye hem platform hem de satıcı kodu için ilkeye karşılık gelen bir özniteliği olan bir tür verebiliriz. Bu, somut türlerin asla kullanılmadığı bir öznitelik politikasını etkili bir şekilde oluşturmak için tüm türler için yapılabilir. Pratikte bu, yalnızca satıcı politikasının bir parçası olarak oluşturulan platform genel politikası olarak tanımlanan ve sağlanan, platform ve tedarikçi firma arasında çakışan politika bölümleri için gereklidir.
Kamu politikasını sürümlü nitelikler olarak tanımlamak, iki politika uyumluluğu hedefini karşılar:
- Satıcı kodunun platform güncellemesinden sonra çalışmaya devam etmesini sağlayın . Erişimi koruyarak satıcı kodunun dayandığı nesnelere karşılık gelen somut türlere öznitelikler ekleyerek elde edilir.
- İlkeyi kullanımdan kaldırma yeteneği . İlke kümelerinin, karşılık geldikleri sürüm artık desteklenmediğinde kaldırılabilecek özniteliklere net bir şekilde tanımlanmasıyla elde edilir. Eski ilkenin satıcı ilkesinde hala mevcut olduğunu ve yükseltildiğinde/yükseltilirse otomatik olarak kaldırılacağını bilerek, geliştirme platformda devam edebilir.
Politika yazılabilirliği
Politika geliştirme için belirli sürüm değişiklikleri hakkında bilgi gerektirmeme hedefine ulaşmak için Android 8.0, platform-kamu politikası türleri ve öznitelikleri arasında bir eşleme içerir. foo
türü, foo_v N
özniteliğiyle eşlenir; burada N
hedeflenen sürümdür. vN
, PLATFORM_SEPOLICY_VERSION
yapı değişkenine karşılık gelir ve MM.NN
biçimindedir; burada MM
, platform SDK numarasına karşılık gelir ve NN
, platforma özel politikaya özgü bir sürümdür.
Kamu politikasındaki öznitelikler sürümlendirilmez, bunun yerine iki bölüm arasındaki arabirimi sabit tutmak için platformun ve satıcı ilkesinin oluşturulabileceği bir API olarak bulunur. Hem platform hem de satıcı politikası yazarları, bugün yazıldığı gibi politika yazmaya devam edebilir.
Platform-kamu politikası, allow source_foo target_bar: class perm ;
satıcı politikasının bir parçası olarak dahil edilmiştir. Derleme sırasında (karşılık gelen sürümü içerir), cihazın satıcı kısmına gidecek ilkeye dönüştürülür (dönüştürülmüş Ortak Ara Dil'de (CIL) gösterilir):
(allow source_foo_vN target_bar_vN (class (perm)))
Satıcı politikası hiçbir zaman platformun ilerisinde olmadığı için önceki sürümlerle ilgilenmemelidir. Bununla birlikte, platform politikasının satıcı politikasının ne kadar geriye gittiğini bilmesi, türlerine öznitelikleri dahil etmesi ve sürümlü özniteliklere karşılık gelen politikayı ayarlaması gerekir.
Politika farklılıkları
Her türün sonuna _v N
ekleyerek öznitelikleri otomatik olarak oluşturmak, öznitelikleri sürüm farkları genelinde türlere eşlemeden hiçbir şey yapmaz. Android, nitelikler için sürümler arasında bir eşleme ve bu özniteliklere türlerin bir eşlemesini sağlar. Bu, (CIL) gibi ifadelerle yukarıda belirtilen eşleme dosyalarında yapılır:
(typeattributeset foo_vN (foo))
Platform yükseltmeleri
Aşağıdaki bölüm, platform yükseltmeleri için senaryoların ayrıntılarını vermektedir.
Aynı tipler
Bu senaryo, bir nesne ilke sürümlerinde etiketleri değiştirmediğinde oluşur. Bu, kaynak ve hedef türleri için aynıdır ve tüm sürümlerde binder_device
olarak etiketlenen /dev/binder
ile görülebilir. Dönüştürülmüş politikada şu şekilde temsil edilir:
binder_device_v1 … binder_device_vN
v1
→ v2
yükseltirken, platform politikası şunları içermelidir:
type binder_device; -> (type binder_device) (in CIL)
v1 eşleme dosyasında (CIL):
(typeattributeset binder_device_v1 (binder_device))
v2 eşleme dosyasında (CIL):
(typeattributeset binder_device_v2 (binder_device))
v1 satıcı politikasında (CIL):
(typeattribute binder_device_v1) (allow binder_device_v1 …)
v2 satıcı politikasında (CIL):
(typeattribute binder_device_v2) (allow binder_device_v2 …)
Yeni tipler
Bu senaryo, platform yeni bir tür eklediğinde ortaya çıkar ve bu durum, yeni özellikler eklenirken veya politika sağlamlaştırma sırasında gerçekleşebilir.
- Yeni özellik Tür, daha önce var olmayan bir nesneyi (yeni bir hizmet süreci gibi) etiketlerken, satıcı kodu daha önce onunla doğrudan etkileşime girmemiştir, bu nedenle karşılık gelen bir ilke yoktur. Türe karşılık gelen yeni öznitelik, önceki sürümde bir özniteliğe sahip değildir ve bu nedenle, bu sürümü hedefleyen eşleme dosyasında bir girişe ihtiyaç duymaz.
- Politika sertleştirme Tür, ilke sağlamlaştırmayı temsil ettiğinde, yeni tür özniteliği öncekine karşılık gelen bir öznitelikler zincirine geri bağlanmalıdır (
/sys/A
sysfs
sysfs_A
değiştirildiği önceki örneğe benzer). Satıcı kodu,sysfs
erişim sağlayan bir kurala dayanır ve bu kuralı yeni türün bir özniteliği olarak içermesi gerekir.
v1
→ v2
yükseltirken, platform politikası şunları içermelidir:
type sysfs_A; -> (type sysfs_A) (in CIL) type sysfs; (type sysfs) (in CIL)
v1 eşleme dosyasında (CIL):
(typeattributeset sysfs_v1 (sysfs sysfs_A))
v2 eşleme dosyasında (CIL):
(typeattributeset sysfs_v2 (sysfs)) (typeattributeset sysfs_A_v2 (sysfs_A))
v1 satıcı politikasında (CIL):
(typeattribute sysfs_v1) (allow … sysfs_v1 …)
v2 satıcı politikasında (CIL):
(typeattribute sysfs_A_v2) (allow … sysfs_A_v2 …) (typeattribute sysfs_v2) (allow … sysfs_v2 …)
Kaldırılan türler
Bu (nadir) senaryo, bir tür kaldırıldığında oluşur ve bu durum, temeldeki nesne şu durumlarda gerçekleşebilir:
- Kalır ancak farklı bir etiket alır.
- Platform tarafından kaldırılır.
İlke gevşetme sırasında, bir tür kaldırılır ve bu türle etiketlenen nesneye farklı, zaten var olan bir etiket verilir. Bu, öznitelik eşlemelerinin birleştirilmesini temsil eder: Satıcı kodu, temel alınan nesneye eskiden sahip olduğu öznitelik aracılığıyla hala erişebilmelidir, ancak sistemin geri kalanı artık ona yeni özniteliğiyle erişebilmelidir.
Değiştirildiği öznitelik yeniyse, yeniden etiketleme, yeni tip durumundaki ile aynıdır, ancak mevcut bir etiket kullanıldığında, eski öznitelik yeni türün eklenmesi, diğer nesnelerin de bu türle etiketlenmesine neden olur. yeni erişilebilir olmak. Bu, esasen platform tarafından yapılan şeydir ve uyumluluğu sürdürmek için kabul edilebilir bir takas olarak kabul edilir.
(typeattribute sysfs_v1) (allow … sysfs_v1 …)
Örnek Versiyon 1: Çöken tipler (sysfs_A kaldırılıyor)
v1
→ v2
yükseltirken, platform politikası şunları içermelidir:
type sysfs; (type sysfs) (in CIL)
v1 eşleme dosyasında (CIL):
(typeattributeset sysfs_v1 (sysfs)) (type sysfs_A) # in case vendors used the sysfs_A label on objects (typeattributeset sysfs_A_v1 (sysfs sysfs_A))
v2 eşleme dosyasında (CIL):
(typeattributeset sysfs_v2 (sysfs))
v1 satıcı politikasında (CIL):
(typeattribute sysfs_A_v1) (allow … sysfs_A_v1 …) (typeattribute sysfs_v1) (allow … sysfs_v1 …)
v2 satıcı politikasında (CIL):
(typeattribute sysfs_v2) (allow … sysfs_v2 …)
Örnek Sürüm 2: Tamamen kaldırma (foo türü)
v1
→ v2
yükseltirken, platform politikası şunları içermelidir:
# nothing - we got rid of the type
v1 eşleme dosyasında (CIL):
(type foo) #needed in case vendors used the foo label on objects (typeattributeset foo_v1 (foo))
v2 eşleme dosyasında (CIL):
# nothing - get rid of it
v1 satıcı politikasında (CIL):
(typeattribute foo_v1) (allow foo …) (typeattribute sysfs_v1) (allow sysfs_v1 …)
v2 satıcı politikasında (CIL):
(typeattribute sysfs_v2) (allow sysfs_v2 …)
Yeni sınıf/izinler
Bu senaryo, bir platform yükseltmesi önceki sürümlerde bulunmayan yeni ilke bileşenlerini tanıttığında oluşur. Örneğin Android, ekleme, bulma ve listeleme izinlerini oluşturan servicemanager
nesne yöneticisini eklediğinde, servicemanager
kaydolmak isteyen satıcı arka plan programları, mevcut olmayan izinlere ihtiyaç duyuyordu. Android 8.0'da yalnızca platform ilkesi yeni sınıflar ve izinler ekleyebilir.
Tedarikçi politikası tarafından oluşturulmuş veya genişletilmiş olabilecek tüm etki alanlarının yeni sınıfı engelleme olmadan kullanmasına izin vermek için platform politikasının aşağıdakine benzer bir kural içermesi gerekir:
allow {domain -coredomain} *:new_class perm;
Bu, satıcı imajının erişim kazandığından emin olmak için tüm arayüz (kamu politikası) türleri için erişime izin veren politika gerektirebilir. Bu, kabul edilemez bir güvenlik politikasıyla sonuçlanırsa (servis yöneticisi değişikliklerinde olabileceği gibi), bir satıcı yükseltmesi potansiyel olarak zorlanabilir.
Kaldırılan sınıf/izinler
Bu senaryo, bir nesne yöneticisi kaldırıldığında ( ZygoteConnection
nesne yöneticisi gibi) oluşur ve sorunlara neden olmamalıdır. Nesne yöneticisi sınıfı ve izinler, satıcı sürümü artık onu kullanmayana kadar ilkede tanımlı kalabilir. Bu, karşılık gelen eşleme dosyasına tanımları ekleyerek yapılır.
Yeni/yeniden etiketlenmiş türler için satıcı özelleştirmesi
Yeni satıcı türleri, yeni süreçleri, ikili dosyaları, aygıtları, alt sistemleri ve depolanan verileri açıklamak için gerekli olduğundan, satıcı politikası geliştirmenin merkezinde yer alır. Bu nedenle, satıcı tanımlı türlerin oluşturulmasına izin verilmesi zorunludur.
Satıcı politikası her zaman cihazdaki en eski politika olduğundan, tüm satıcı türlerini politikadaki özniteliklere otomatik olarak dönüştürmeye gerek yoktur. Platform, tedarikçi politikasında etiketlenmiş herhangi bir şeye güvenmez çünkü platformun bu konuda bilgisi yoktur; ancak platform, bu türlerle etiketlenmiş nesnelerle (örneğin, domain
, sysfs_type
, vb.) etkileşim kurmak için kullandığı öznitelikleri ve genel türleri sağlayacaktır. Platformun bu nesnelerle doğru bir şekilde etkileşime devam etmesi için nitelikler ve türler uygun şekilde uygulanmalı ve özelleştirilebilir etki alanlarına ( init
gibi) belirli kurallar eklenmelidir.
Android 9 için öznitelik değişiklikleri
Android 9'a yükseltme yapan cihazlar aşağıdaki öznitelikleri kullanabilir, ancak Android 9 ile başlayan cihazlar kullanmamalıdır.
İhlal eden özellikleri
Android 9, alanla ilgili şu özellikleri içerir:
-
data_between_core_and_vendor_violators
.vendor
vecoredomains
arasında yol yoluyla dosya paylaşmama gerekliliğini ihlal eden tüm etki alanları için öznitelik. Platform ve satıcı işlemleri, iletişim kurmak için diskteki dosyaları kullanmamalıdır (kararsız ABI). Öneri:- Satıcı kodu
/data/vendor
kullanmalıdır. - Sistem
/data/vendor
kullanmamalıdır.
- Satıcı kodu
-
system_executes_vendor_violators
. Satıcı ikili dosyalarını yürütmeme gerekliliğini ihlal eden tüm sistem etki alanları (init
veshell domains
hariç) için öznitelik. Satıcı ikili dosyalarının yürütülmesinde kararsız API var. Platform, satıcı ikili dosyalarını doğrudan yürütmemelidir. Öneri:- Satıcı ikili dosyalarındaki bu tür platform bağımlılıkları, HIDL HAL'lerin arkasında olmalıdır.
VEYA
- satıcı ikili dosyalarına erişmesi gereken
coredomains
, satıcı bölümüne taşınmalı ve böylececoredomain
olmaktan çıkmalıdır.
- Satıcı ikili dosyalarındaki bu tür platform bağımlılıkları, HIDL HAL'lerin arkasında olmalıdır.
güvenilmeyen özellikler
Rastgele kod barındıran güvenilmeyen uygulamaların, bu tür uygulamalardan erişim için yeterince güvenli kabul edilenler dışında HwBinder hizmetlerine erişimi olmamalıdır (aşağıdaki güvenli hizmetlere bakın). Bunun iki ana nedeni:
- HwBinder sunucuları, istemci kimlik doğrulaması gerçekleştirmez çünkü HIDL şu anda arayanın UID bilgilerini göstermez. HIDL bu tür verileri ifşa etmiş olsa bile, birçok HwBinder hizmeti, uygulamaların (HAL'ler gibi) altında çalışır veya yetkilendirme için uygulama kimliğine güvenmemelidir. Bu nedenle, güvende olmak için, varsayılan varsayım, her HwBinder hizmetinin, hizmet tarafından sunulan işlemleri gerçekleştirmek için tüm istemcilerine eşit derecede yetkili muamelesi yapmasıdır.
- HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi)
system/core
bileşenlerinden daha yüksek güvenlik sorunları görülme oranına sahip kod içerir ve yığının alt katmanlarına (donanıma kadar) erişime sahiptir, böylece Android güvenlik modelini atlama fırsatlarını artırır .
Güvenli hizmetler
Güvenli hizmetler şunları içerir:
-
same_process_hwservice
. Bu hizmetler (tanım gereği), istemci sürecinde çalışır ve bu nedenle, işlemin çalıştığı istemci etki alanıyla aynı erişime sahiptir. -
coredomain_hwservice
. Bu hizmetler, 2. nedenle ilişkili riskler oluşturmaz. -
hal_configstore_ISurfaceFlingerConfigs
. Bu hizmet, herhangi bir etki alanı tarafından kullanılmak üzere özel olarak tasarlanmıştır. -
hal_graphics_allocator_hwservice
. Bu işlemler, uygulamaların erişmesine izin verilensurfaceflinger
Binder hizmeti tarafından da sunulmaktadır. -
hal_omx_hwservice
. Bu, uygulamaların erişmesine izin verilenmediacodec
Binder hizmetinin HwBinder sürümüdür. -
hal_codec2_hwservice
. Bu,hal_omx_hwservice
daha yeni bir sürümüdür.
Kullanılabilir özellikler
Güvenli kabul edilmeyen tüm hwservices
untrusted_app_visible_hwservice
özniteliğine sahiptir. Karşılık gelen HAL sunucuları untrusted_app_visible_halserver
özniteliğine sahiptir. Android 9 ile başlatılan cihazlar untrusted
öznitelikleri KULLANMAMALIDIR.
Öneri:
- Güvenilmeyen uygulamalar bunun yerine satıcı HIDL HAL ile konuşan bir sistem hizmetiyle iletişim kurmalıdır. Örneğin, uygulamalar
binderservicedomain
ile konuşabilir, ardındanmediaserver
(birbinderservicedomain
)hal_graphics_allocator
ile konuşabilir.VEYA
-
vendor
HAL'lerine doğrudan erişime ihtiyaç duyan uygulamaların kendi tedarikçi firma tanımlı sepolicy etki alanı olmalıdır.
Dosya özelliği testleri
Android 9, belirli konumlardaki tüm dosyaların uygun özniteliklere sahip olmasını sağlayan derleme zamanı testleri içerir (örneğin, sysfs
tüm dosyalar gerekli sysfs_type
özniteliğine sahiptir).
Platform-kamu politikası
Platform-kamu politikası, yalnızca v1 ve v2'den platform politikalarının birliğini sürdürmeden Android 8.0 mimari modeline uymanın özüdür. Satıcılar, daha sonra satıcı politikasının bir parçası haline gelen kullanılabilir türler ve öznitelikler ve bu türler ve özniteliklere ilişkin kurallar içeren bir platform ilkesi alt kümesine tabi tutulur (örn. vendor_sepolicy.cil
).
Türler ve kurallar, satıcı tarafından oluşturulan ilkede otomatik olarak attribute_v N
çevrilir, öyle ki platform tarafından sağlanan tüm türler sürümlü öznitelikler olur (ancak öznitelikler sürümlü değildir). Platform, satıcı politikasının işlemeye devam etmesini ve belirli bir sürüm için sağlanan kuralların dahil edilmesini sağlamak için sağladığı somut türleri uygun niteliklerle eşleştirmekten sorumludur. Platform-kamu politikası ve satıcı politikasının birleşimi, Android 8.0 mimarisi modelinin bağımsız platform ve satıcı yapılarına izin verme hedefini karşılar.
Öznitelik zincirlerine eşleme
İlke sürümleriyle eşlemek için öznitelikleri kullanırken, bir tür, bir öznitelik veya birden çok öznitelikle eşleşir ve bu türle etiketlenen nesnelerin, önceki türlerine karşılık gelen öznitelikler aracılığıyla erişilebilir olmasını sağlar.
Sürüm bilgisini ilke yazarından gizleme hedefini sürdürmek, sürümlü öznitelikleri otomatik olarak oluşturmak ve bunları uygun türlere atamak anlamına gelir. Genel statik tür durumunda, bu basittir: type_foo
type_foo_v1
ile eşlenir.
sysfs
→ sysfs_A
veya mediaserver
→ audioserver
gibi bir nesne etiketi değişikliği için, bu eşlemenin oluşturulması önemsiz değildir (ve yukarıdaki örneklerde açıklanmıştır). Platform ilkesi koruyucuları, nesneler ve atanan etiketleri arasındaki ilişkiyi anlamayı ve bunun ne zaman olacağını belirlemeyi gerektiren, nesneler için geçiş noktalarında eşlemenin nasıl oluşturulacağını belirlemelidir. Geriye dönük uyumluluk için, bu karmaşıklığın, yukarı yönlü olabilecek tek bölüm olan platform tarafında yönetilmesi gerekir.
Sürüm yükseltmeleri
Basitlik için, Android platformu yeni bir sürüm dalı kesildiğinde bir sepolicy sürümü yayınlar. Yukarıda açıklandığı gibi, sürüm numarası PLATFORM_SEPOLICY_VERSION
içinde bulunur ve MM.nn
biçimindedir; burada MM
SDK değerine karşılık gelir ve nn
/platform/system/sepolicy.
Örneğin, Kitkat için 19.0
, Lollipop için 21.0
, Lollipop-MR1 için 22.0
, Marshmallow için 23.0
, Nougat için 24.0
, Nougat-MR1 için 25.0
, Oreo için 26.0
, Oreo-MR1 için 27.0
ve Android 9 için 28.0
. her zaman tam sayılar Örneğin, bir sürüme yönelik bir MR yükseltmesi system/sepolicy/public
uyumsuz bir değişiklik gerektiriyorsa ancak bir API yükseltmesi gerektirmiyorsa, o zaman bu sepolicy sürümü şöyle olabilir: vN.1
. Bir geliştirme şubesinde bulunan sürüm, nakliye cihazlarında asla kullanılmaması gereken bir 10000.0
sürümüdür.
Yükseltme sırasında Android en eski sürümü kullanımdan kaldırabilir. Android, bir sürümün ne zaman kullanımdan kaldırılacağına ilişkin giriş için, o Android sürümünü çalıştıran ve hâlâ büyük platform güncellemeleri alan satıcı politikalarına sahip cihazların sayısını toplayabilir. Sayı belirli bir eşiğin altındaysa, bu sürüm kullanımdan kaldırılmıştır.
Birden fazla özelliğin performans etkisi
https://github.com/SELinuxProject/cil/issues/9 içinde açıklandığı gibi, bir türe atanan çok sayıda öznitelik, bir ilke önbelleğinin kaybolması durumunda performans sorunlarına yol açar.
Bunun Android'de bir sorun olduğu onaylandı, bu nedenle politika derleyicisi tarafından politikaya eklenen öznitelikleri ve kullanılmayan öznitelikleri kaldırmak için Android 8.0'da değişiklikler yapıldı . Bu değişiklikler performans gerilemelerini çözdü.
System_ext genel ve ürün genel politikası
Android 11'den başlayarak, system_ext ve ürün bölümlerinin belirlenmiş genel türlerini satıcı bölümüne aktarmalarına izin verilir. Platform kamu politikası gibi satıcı, otomatik olarak sürümlü özniteliklere çevrilen türleri ve kuralları kullanır; örneğin, type
type_ N
, burada N
, satıcı bölümünün oluşturulduğu platformun sürümüdür.
system_ext ve ürün bölümleri aynı N
platform sürümünü temel aldığında, yapı sistemi, kimlik içeren system_ext/etc/selinux/mapping/ N .cil
ve product/etc/selinux/mapping/ N .cil
için temel eşleme dosyaları oluşturur. type
type_ N
eşlemeler. Satıcı, type_ N
sürümlü özniteliğiyle type
erişebilir.
Yalnızca system_ext ve ürün bölümlerinin güncellenmesi durumunda, örneğin N
N+1
(veya üstü), satıcı N
kalırken, satıcı system_ext ve ürün bölümleri türlerine erişimi kaybedebilir. Bozulmayı önlemek için system_ext ve ürün bölümleri, dosyaları somut türlerden type_ N
özniteliklerine eşleme sağlamalıdır. N+1
(veya üstü) system_ext ve ürün bölümleri ile N
satıcıyı destekleyeceklerse, her ortak eşleme dosyalarının bakımından sorumludur.
Bunu yapmak için ortakların şunları yapması beklenir:
- Oluşturulan temel eşleme dosyalarını
N
system_ext ve ürün bölümlerinden kaynak ağaçlarına kopyalayın. - Eşleme dosyalarını gerektiği gibi değiştirin.
- Eşleme dosyalarını
N+1
(veya üstü) system_ext ve ürün bölümlerine kurun.
Örneğin, N
system_ext öğesinin foo_type
adında bir genel türe sahip olduğunu varsayalım. Sonra system_ext/etc/selinux/mapping/ N .cil
N
system_ext bölümündeki N .cil şöyle görünecektir:
(typeattributeset foo_type_N (foo_type)) (expandtypeattribute foo_type_N true) (typeattribute foo_type_N)
N+1
system_ext'e bar_type
eklenirse ve N
satıcı için bar_type
foo_type
eşlenmesi gerekiyorsa, N .cil
şu adresten güncellenebilir:
(typeattributeset foo_type_N (foo_type))
ile
(typeattributeset foo_type_N (foo_type bar_type))
ve ardından N+1
system_ext'in bölümüne yüklenir. N
tedarikçi firma, N+1
system_ext'in foo_type
ve bar_type
öğelerine erişmeye devam edebilir.
SELinux içerik etiketlemesi
Sistem, platform ve satıcı politikası arasındaki ayrımı desteklemek için, SELinux içerik dosyalarını ayrı tutmak için farklı şekilde oluşturur.
Dosya bağlamları
Android 8.0, file_contexts
için aşağıdaki değişiklikleri getirdi:
- Önyükleme sırasında aygıtta ek derleme yükünden kaçınmak için,
file_contexts
ikili biçimde mevcut olmaktan çıkar. Bunun yerine,{property, service}_contexts
(7.0 öncesi oldukları gibi) gibi okunabilir, normal ifade metin dosyalarıdır. -
file_contexts
iki dosya arasında bölünmüştür:-
plat_file_contexts
- Sepolicy dosyalarının düzgün çalışmasını sağlamak için tam olarak etiketlenmesi gereken
/vendor
bölümünün etiketleme bölümleri dışında, cihaza özel etiketleri olmayan Android platformufile_context
. - Aygıtta
/system/etc/selinux/plat_file_contexts
adresindekisystem
bölümünde bulunmalı ve başlangıçtainit
tarafından satıcıfile_context
ile birlikte yüklenmelidir.
- Sepolicy dosyalarının düzgün çalışmasını sağlamak için tam olarak etiketlenmesi gereken
-
vendor_file_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanfile_contexts
birleştirilerek cihaza özelfile_context
oluşturulmuştur. -
/vendor/etc/selinux/vendor_file_contexts
vendor
bölümünde kurulmalı ve başlangıçtainit
tarafındanfile_context
platformuyla birlikte yüklenmelidir.
- Cihazın
-
Özellik bağlamları
Android 8.0'da, property_contexts
iki dosya arasında bölünmüştür:
-
plat_property_contexts
- Cihaza özel etiketleri olmayan Android platformu
property_context
. -
/system/etc/selinux/plat_property_contexts
konumundasystem
bölümünde bulunmalı ve başlangıçtainit
tarafından satıcıproperty_contexts
ile birlikte yüklenmelidir.
- Cihaza özel etiketleri olmayan Android platformu
-
vendor_property_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanproperty_contexts
birleştirilmesiyle oluşturulan cihaza özelproperty_context
. -
/vendor/etc/selinux/vendor_property_contexts
adresindekivendor
bölümünde bulunmalı ve başlangıçtainit
tarafından platformproperty_context
ile birlikte yüklenmelidir.
- Cihazın
Hizmet bağlamları
Android 8.0'da, service_contexts
aşağıdaki dosyalar arasında bölünmüştür:
-
plat_service_contexts
-
servicemanager
için Android platformuna özgüservice_context
.service_context
cihaza özgü etiketleri yoktur. -
/system/etc/selinux/plat_service_contexts
konumundasystem
bölümünde bulunmalı ve başlangıçtaservicemanager
tarafındanservice_contexts
satıcısı ile birlikte yüklenmelidir.
-
-
vendor_service_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanservice_contexts
birleştirilmesiyle oluşturulan cihaza özgüservice_context
. -
/vendor/etc/selinux/vendor_service_contexts
adresindekivendor
bölümünde bulunmalı ve başlangıçtaservicemanager
tarafındanservice_contexts
platformuyla birlikte yüklenmelidir. -
servicemanager
önyükleme sırasında bu dosyayı arasa da, tamamen uyumlu birTREBLE
aygıtı içinvendor_service_contexts
mevcut OLMAMALIDIR. Bunun nedeni,vendor
vesystem
süreçleri arasındaki tüm etkileşiminhwservicemanager
/hwbinder
üzerinden geçmesi GEREKİR.
- Cihazın
-
plat_hwservice_contexts
- Cihaza özgü etiketleri olmayan
hwservicemanager
için Android platformuhwservice_context
. -
/system/etc/selinux/plat_hwservice_contexts
adresindekisystem
bölümünde bulunmalı ve başlangıçtahwservicemanager
tarafındanvendor_hwservice_contexts
ile birlikte yüklenmelidir.
- Cihaza özgü etiketleri olmayan
-
vendor_hwservice_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanhwservice_contexts
birleştirilerek cihaza özelhwservice_context
oluşturulmuştur. -
/vendor/etc/selinux/vendor_hwservice_contexts
adresindekivendor
bölümünde bulunmalı ve başlangıçtaplat_service_contexts
ile birliktehwservicemanager
tarafından yüklenmelidir.
- Cihazın
-
vndservice_contexts
- Cihazın
Boardconfig.mk
dosyasındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanvndservice_contexts
birleştirilerek oluşturulanvndservicemanager
için cihaza özelservice_context
. - Bu dosya
/vendor/etc/selinux/vndservice_contexts
adresindekivendor
bölümünde bulunmalı ve başlangıçtavndservicemanager
tarafından yüklenmelidir.
- Cihazın
Uygulama bağlamları
Android 8.0'da seapp_contexts
iki dosya arasında bölünmüştür:
-
plat_seapp_contexts
- Cihaza özel değişiklikleri olmayan Android platformu
seapp_context
. - /system/etc/selinux/plat_seapp_contexts adresindeki
system
bölümünde bulunmalıdır/system/etc/selinux/plat_seapp_contexts.
- Cihaza özel değişiklikleri olmayan Android platformu
-
vendor_seapp_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanseapp_contexts
birleştirilmesiyle oluşturulanseapp_context
platformuna cihaza özgü uzantı. -
/vendor/etc/selinux/vendor_seapp_contexts
adresindekivendor
bölümünde bulunmalıdır.
- Cihazın
MAC izinleri
Android 8.0'da mac_permissions.xml
dosyası iki dosya arasında bölünmüştür:
- Platform
mac_permissions.xml
- Cihaza özel değişiklikleri olmayan Android platformu
mac_permissions.xml
. - /system/etc/selinux/ adresindeki
system
bölümünde bulunmalıdır/system/etc/selinux/.
- Cihaza özel değişiklikleri olmayan Android platformu
- Platform Dışı
mac_permissions.xml
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanmac_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/.
- Cihazın