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:
Emlak Tipi | Kabul edilebilir önekler |
---|---|
kontrol özellikleri | ctl.vendor. ctl.start$vendor. ctl.stop$vendor. init.svc.vendor. |
okunabilir | vendor. |
Sadece oku | ro.vendor. ro.boot. ro.hardware. |
kalici | persist.vendor. |
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:
/vendor yolu | Platform tarafından sağlanan etiket | Etikete bağlı olarak platform işlemleri |
---|---|---|
/vendor(/. * )? | vendor_file | Framework, ueventd , vb. içindeki tüm HAL istemcileri. |
/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 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 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.
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
öğesininsysfs
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çincoredomains
. 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.
- Satıcı kodu
-
system_executes_vendor_violators
. Satıcı ikili dosyalarını yürütmeme gereksinimini 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'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
.
- Satıcı ikili dosyalarındaki bu tür platform bağımlılıkları, HIDL HAL'lerinin arkasında olmalıdır.
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:
- 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.
- 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 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 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ındanmediaserver
(birbinderservicedomain
olan) sıraylahal_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:
-
N
system_ext ve ürün bölümlerinden oluşturulan temel eşleme dosyalarını 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 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 platformufile_context
. -
/system/etc/selinux/plat_file_contexts
system
bölümünde bulunmalı veinit
tarafından, satıcıfile_context
ile birlikte yüklenmelidir.
-
-
vendor_file_contexts
- Aygıtın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından gösterilen dizinlerde bulunanfile_contexts
birleştirilmesiyle oluşturulan aygıta özgüfile_context
. - Satıcı bölümünde /
vendor
/vendor/etc/selinux/vendor_file_contexts
veinit
tarafındanfile_context
platformuyla birlikte yüklenmelidir.
- Aygıtın
-
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
adresindekisystem
bölümünde bulunmalı ve satıcıproperty_contexts
ile birlikte başlangıçtainit
tarafından 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şturulmuş cihaza özelproperty_context
. -
/vendor/etc/selinux/vendor_property_contexts
vendor
bölümünde bulunmalı ve başlangıçta platformproperty_context
ile birlikteinit
tarafından yüklenmelidir
- Cihazın
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 özelservice_context
.service_context
cihaza özel etiketi yok. -
/system/etc/selinux/plat_service_contexts
system
bölümünde bulunmalı ve başlangıçtaservicemanager
tarafından satıcıservice_contexts
ile birlikte yüklenmelidir.
-
-
vendor_service_contexts
- Cihazın
service_context
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından gösterilen dizinlerde bulunanservice_contexts
birleştirilmesiyle oluşturulan cihaza özelBoardconfig.mk
. -
/vendor/etc/selinux/vendor_service_contexts
vendor
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, tam uyumlu birTREBLE
aygıtı içinvendor_service_contexts
OLMAMALIDIR. Bunun nedeni,vendor
vesystem
süreçleri arasındaki tüm etkileşiminhwservicemanager
/hwbinder
geçmesi ZORUNLUDUR.
- Cihazın
-
plat_hwservice_contexts
- Cihaza özel etiketlere sahip olmayan
hwservicemanager
için Android platformuhwservice_context
. -
/system/etc/selinux/plat_hwservice_contexts
adresindekisystem
bölümünde bulunmalı ve başlangıçta hwservicemanager tarafındanhwservicemanager
ile birliktevendor_hwservice_contexts
.
- Cihaza özel etiketlere sahip olmayan
-
vendor_hwservice_contexts
- Cihazın
hwservice_context
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından gösterilen dizinlerde bulunanhwservice_contexts
birleştirilmesiyle oluşturulan cihaza özelBoardconfig.mk
. -
/vendor/etc/selinux/vendor_hwservice_contexts
vendor
bölümünde bulunmalı ve başlangıçta hwservicemanager tarafındanhwservicemanager
ile birlikteplat_service_contexts
.
- Cihazın
-
vndservice_contexts
- Cihazın
service_context
vndservicemanager
tarafından gösterilen dizinlerde bulunanvndservice_contexts
birleştirilmesiyle oluşturulanBOARD_SEPOLICY_DIRS
için cihaza özelBoardconfig.mk
. - Bu dosya
/vendor/etc/selinux/vndservice_contexts
vendor
bölümünde bulunmalı ve başlangıçtavndservicemanager
tarafından yüklenmelidir.
- Cihazın
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.
adresindekisystem
bölümünde bulunmalıdır.
- Cihaza özel değişiklik içermeyen Android platformu
-
vendor_seapp_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanseapp_contexts
birleştirilmesiyle oluşturulmuşseapp_context
platformuna yönelik cihaza özel 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
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/.
adresindekisystem
bölümünde bulunmalıdır.
- Cihaza özel değişiklik içermeyen Android platformu
- Platform
mac_permissions.xml
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından gösterilen dizinlerde bulunanmac_permissions.xml
oluşturulmuş platformmac_permissions.xml
için cihaza özel uzantı. -
/vendor/etc/selinux/.
adresindekivendor
bölümünde bulunmalıdır.
- Cihazın