Bu makalede Android'in, yeni platform SELinux ayarlarının eski satıcı SELinux ayarlarından farklı olabileceği platform OTA'larıyla ilgili politika uyumluluk sorunlarını nasıl ele aldığı açıklanmaktadır.
Treble tabanlı SELinux politikası tasarımı, platform ve satıcı politikası arasındaki ikili ayrımı dikkate alır; satıcı bölümleri platform
< vendor
< oem
gibi bağımlılıklar oluşturursa şema daha karmaşık hale gelir.
Android 8.0 ve üzeri sürümlerde SELinux global politikası özel ve genel bileşenlere ayrılmıştır. Genel bileşenler, bir platform sürümü için mevcut olması garanti edilen politika ve ilgili altyapıdan oluşur. Bu politika, satıcıların platform tarafından sağlanan politikayla birleştirildiğinde bir cihaz için tam işlevsel bir politikayla sonuçlanan bir satıcı politika dosyası oluşturmasını sağlamak için satıcı politika yazarlarına sunulacaktır.
- Sürüm oluşturma için dışa aktarılan platform-genel politikası, nitelikler olarak yazılacaktır.
- Politika yazımının kolaylığı için, dışa aktarılan türler, politika oluşturma sürecinin bir parçası olarak versiyonlanmış niteliklere dönüştürülecektir. Genel türler ayrıca satıcı bağlam dosyaları tarafından sağlanan etiketleme kararlarında doğrudan kullanılabilir.
Android, platform politikasında dışa aktarılan somut türler ile her platform sürümü için karşılık gelen sürümlendirilmiş öznitelikler arasında bir eşleme sağlar . Bu, nesneler bir türle etiketlendiğinde önceki sürümde platform genel politikası tarafından garanti edilen davranışı bozmamasını sağlar. Bu eşleme, kamu politikasında dışa aktarılan her tür için öznitelik üyeliği bilgilerini tutan, her platform sürümü için bir eşleme dosyasının güncel tutulmasıyla sağlanır.
Nesne sahipliği ve etiketleme
Android 8.0 ve sonraki sürümlerde politikayı özelleştirirken, platform ve satıcı politikasını ayrı tutmak amacıyla her nesne için sahiplik açıkça tanımlanmalıdır. Örneğin, satıcı /dev/foo
etiketlerse ve platform daha sonra sonraki bir OTA'da /dev/foo
etiketlerse tanımsız davranış ortaya çıkacaktır. SELinux için bu, bir etiketleme çarpışması olarak ortaya çıkar. Cihaz düğümü, en son uygulanan etikete çözümlenen yalnızca tek bir etikete sahip olabilir. Sonuç olarak:
- Başarısız bir şekilde uygulanan etikete erişmesi gereken işlemler, kaynağa erişimi kaybedecektir.
- Yanlış aygıt düğümü oluşturulduğu için dosyaya erişim sağlayan işlemler bozulabilir.
Sistem özellikleri aynı zamanda sistemde tanımsız davranışlara yol açabilecek çarpışmaları adlandırma potansiyeline de sahiptir (aynı zamanda SELinux etiketlemesi için). Özellikler, hizmetler, işlemler, dosyalar ve yuvalar dahil olmak üzere SELinux etiketine sahip herhangi bir nesne için platform ve satıcı etiketleri arasında çarpışmalar meydana gelebilir. Bu sorunları önlemek için bu nesnelerin sahipliğini açıkça tanımlayın.
Etiket çarpışmalarına ek olarak SELinux türü/öznitelik adları da çakışabilir. Tür/öznitelik adı çarpışması her zaman politika derleyici hatasıyla sonuçlanacaktır.
Tür/özellik ad alanı
SELinux aynı tipte/öznitelikte birden fazla bildirime izin vermez. Yinelenen bildirimlere sahip politikanın derlenmesi başarısız olur. Tür ve öznitelik adı çakışmalarını önlemek için, tüm satıcı bildirimlerinin np_
ile başlayan ad alanına sahip olması gerekir.
type foo, domain; → type np_foo, domain;
Sistem özelliği ve süreç etiketleme sahipliği
Etiketleme çakışmalarından kaçınmak en iyi şekilde özellik ad alanları kullanılarak çözülür. Platform özelliklerini kolayca tanımlamak ve dışa aktarılan platform özelliklerini yeniden adlandırırken veya eklerken ad çakışmalarını önlemek için tüm satıcı mülklerinin kendi öneklerine sahip olduğundan emin olun:
Emlak Tipi | Kabul edilebilir önekler |
---|---|
kontrol özellikleri | ctl.vendor. ctl.start$vendor. ctl.stop$vendor. init.svc.vendor. |
okunabilir-yazılabilir | vendor. |
Sadece oku | ro.vendor. ro.boot. ro.hardware. |
kalıcı | persist.vendor. |
Satıcılar ro.boot.*
(çekirdek cmdline'ından gelir) ve ro.hardware.*
(donanımla ilgili bariz bir özellik) kullanmaya devam edebilir.
init rc dosyalarındaki tüm satıcı hizmetlerinin vendor.
sistem dışı bölümlerin init rc dosyalarındaki hizmetler için. Satıcı özellikleri için SELinux etiketlerine de benzer kurallar uygulanır (satıcı özellikleri için vendor_
).
Dosya sahipliği
Platform ve satıcı politikasının her ikisi de genel olarak tüm dosya sistemleri için etiketler sağladığından dosyalar için çakışmaları önlemek zordur. Tür adlandırmanın aksine, dosyaların ad alanı, çoğu çekirdek tarafından oluşturulduğundan pratik değildir. Bu çakışmaları önlemek için bu bölümdeki dosya sistemlerine yönelik adlandırma yönergelerini izleyin. Android 8.0 için bunlar teknik yaptırımı olmayan önerilerdir. Gelecekte bu öneriler Satıcı Test Paketi (VTS) tarafından uygulanacaktır.
Sistem (/sistem)
Yalnızca sistem görüntüsü, file_contexts
, service_contexts
vb. aracılığıyla /system
bileşenleri için etiketler sağlamalıdır. /system
bileşenleri için etiketler /vendor
politikasına eklenirse, yalnızca çerçeve OTA güncellemesi mümkün olmayabilir.
Satıcı (/satıcı)
AOSP SELinux politikası, platformun etkileşime girdiği vendor
bölümünün bölümlerini zaten etiketler; bu, platform işlemlerinin vendor
bölümünün bölümleriyle konuşabilmesi ve/veya bunlara erişebilmesi için SELinux kurallarının yazılmasına olanak tanır. Örnekler:
/vendor yolu | Platform tarafından sağlanan etiket | Etikete bağlı olarak platform işlemleri |
---|---|---|
/vendor(/. * )? | vendor_file | Çerçevedeki tüm HAL istemcileri, ueventd vb. |
/vendor/framework(/. * )? | vendor_framework_file | dex2oat , appdomain vb. |
/vendor/app(/. * )? | vendor_app_file | dex2oat , installd , idmap vb. |
/vendor/overlay(/. * ) | vendor_overlay_file | system_server , zygote , idmap vb. |
Sonuç olarak, vendor
bölümündeki ek dosyaları etiketlerken belirli kurallara uyulmalıdır ( neverallows
aracılığıyla uygulanır):
-
vendor_file
vendor
bölümündeki tüm dosyalar için varsayılan etiket olmalıdır. Platform politikası, geçişli HAL uygulamalarına erişim için bunu gerektirir. - Satıcı SEPolicy aracılığıyla
vendor
bölümüne eklenen tüm yeniexec_types
vendor_file_type
niteliğine sahip olması gerekir. Bu, Neverallows aracılığıyla uygulanır. - Gelecekteki platform/çerçeve güncellemeleriyle çakışmaları önlemek için
vendor
bölümünde dosyalarıexec_types
dışında etiketlemekten kaçının. - AOSP tarafından tanımlanan aynı işlem HAL'lerine yönelik tüm kitaplık bağımlılıkları,
same_process_hal_file.
Procf'ler (/proc)
/proc
içindeki dosyalar yalnızca genfscon
etiketi kullanılarak etiketlenebilir. Android 7.0'da hem platform hem de satıcı politikası, procfs
içindeki dosyaları etiketlemek için genfscon
kullandı.
Öneri: Yalnızca platform politikası etiketleri /proc
. vendor
işlemlerinin, şu anda varsayılan etiketle ( proc
) etiketlenmiş olan /proc
içindeki dosyalara erişmesi gerekiyorsa, satıcı politikası bunları açıkça etiketlememeli ve bunun yerine satıcı etki alanlarına kural eklemek için genel proc
türünü kullanmalıdır. Bu, platform güncellemelerinin, procfs
aracılığıyla kullanıma sunulan gelecekteki çekirdek arayüzlerine uyum sağlamasına ve bunları gerektiğinde açıkça etiketlemesine olanak tanır.
Hata ayıklamalar (/sys/kernel/debug)
Debugfs
hem file_contexts
hem de genfscon
olarak etiketlenebilir. Android 7.0'dan Android 10'a kadar hem platform hem de satıcı etiketi debugfs
.
Android 11'de debugfs
erişilemez veya üretim cihazlarına bağlanılamaz. Cihaz üreticileri debugfs
kaldırmalıdır.
Tracef'ler (/sys/kernel/debug/tracing)
Tracefs
hem file_contexts
hem de genfscon
olarak etiketlenebilir. Android 7.0'da yalnızca platform tracefs
etiketini kullanır.
Öneri: tracefs
yalnızca platform etiketleyebilir.
Sistemler (/sys)
/sys
içindeki dosyalar hem file_contexts
hem de genfscon
kullanılarak etiketlenebilir. Android 7.0'da, hem platform hem de satıcı, sysfs
içindeki dosyaları etiketlemek için file_contexts
ve genfscon
kullanır.
Öneri: Platform, cihaza özel olmayan sysfs
düğümlerini etiketleyebilir. Aksi takdirde dosyaları yalnızca satıcı etiketleyebilir.
tmpfs (/dev)
/dev
içindeki dosyalar file_contexts
ile etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket dosyaları burada.
Öneri: Satıcı yalnızca /dev/vendor
içindeki dosyaları etiketleyebilir (örneğin, /dev/vendor/foo
, /dev/vendor/socket/bar
).
Kökler (/)
/
içindeki dosyalar file_contexts
içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket dosyaları burada.
Öneri: /
içindeki dosyaları yalnızca sistem etiketleyebilir.
Veri (/veri)
Veriler, file_contexts
ve seapp_contexts
öğelerinin birleşimi aracılığıyla etiketlenir.
Öneri: /data/vendor
dışında satıcı etiketlemesine izin vermeyin. Yalnızca platform /data
dosyasının diğer bölümlerini etiketleyebilir.
Uyumluluk özellikleri
SELinux ilkesi, belirli nesne sınıfları ve izinler için kaynak ve hedef türleri arasındaki etkileşimdir. SELinux ilkesinden etkilenen her nesnenin (işlemler, dosyalar vb.) yalnızca bir türü olabilir, ancak bu türün birden çok özelliği olabilir.
Politika çoğunlukla mevcut türlere göre yazılır:
allow source_type target_type:target_class permission(s);
Bu işe yarar çünkü politika her türlü bilgiyle yazılmıştır. Ancak satıcı politikası ve platform politikası belirli türleri kullanıyorsa ve belirli bir nesnenin etiketi bu politikalardan yalnızca birinde değişirse, diğeri daha önce güvenilen erişim kazanılan veya kaybedilen politikayı içerebilir. Örneğin:
File_contexts: /sys/A u:object_r:sysfs:s0 Platform: allow p_domain sysfs:class perm; Vendor: allow v_domain sysfs:class perm;
Şu şekilde değiştirilebilir:
File_contexts: /sys/A u:object_r:sysfs_A:s0
Satıcı politikası aynı kalsa da, yeni sysfs_A
türüne yönelik politika eksikliği nedeniyle v_domain
erişimini kaybedecektir.
Bir politikayı nitelikler açısından tanımlayarak, temeldeki nesneye hem platform hem de satıcı kodu için politikaya karşılık gelen bir özniteliğe sahip bir tür verebiliriz. Bu, somut türlerin hiçbir zaman kullanılmadığı bir nitelik politikasını etkili bir şekilde oluşturmak için tüm türler için yapılabilir. Uygulamada bu, yalnızca satıcı politikasının bir parçası olarak oluşturulan platform kamu politikası olarak tanımlanan ve sağlanan, platform ile satıcı arasında örtüşen politika bölümleri için gereklidir.
Kamu politikasını sürümlendirilmiş nitelikler olarak tanımlamak, iki politika uyumluluk hedefini karşılar:
- Satıcı kodunun platform güncellemesinden sonra çalışmaya devam ettiğinden emin olun . Satıcı kodunun dayandığı nesnelere karşılık gelen nesneler için somut türlere öznitelikler eklenerek erişim korunarak gerçekleştirilir.
- Politikayı kullanımdan kaldırma yeteneği . Politika kümelerinin, karşılık geldikleri sürüm artık desteklenmediğinde kaldırılabilecek nitelikler halinde açıkça tanımlanmasıyla gerçekleştirilir. Satıcı politikasında eski politikanın hala mevcut olduğunu ve yükseltme yapıldığında/yükseltildiğinde otomatik olarak kaldırılacağını bilerek platformda geliştirme devam edebilir.
Politika yazılabilirliği
Politika geliştirme için belirli sürüm değişiklikleri hakkında bilgi gerektirmeme hedefine ulaşmak için Android 8.0, platform-genel politika türleri ve bunların nitelikleri arasında bir eşleme içerir. foo
türü, foo_v N
özniteliğine eşlenir; burada N
, hedeflenen sürümdür. vN
PLATFORM_SEPOLICY_VERSION
yapı değişkenine karşılık gelir ve MM.NN
biçimindedir; burada MM
platform SDK numarasına karşılık gelir ve NN
, platform sepolicy'ye özgü bir sürümdür.
Kamu politikasındaki öznitelikler sürümlendirilmez, bunun yerine iki bölüm arasındaki arayüzü sabit tutmak için platform ve satıcı politikasının oluşturulabileceği bir API olarak mevcuttur. Hem platform hem de satıcı politikası yazarları, politikayı bugün yazıldığı gibi yazmaya devam edebilir.
allow source_foo target_bar: class perm ;
Satıcı politikasının bir parçası olarak dahil edilmiştir. Derleme sırasında (ilgili sürümü içerir), cihazın satıcı kısmına gidecek politikaya dönüştürülür (dönüştürülmüş Ortak Ara Dilde (CIL) gösterilir):
(allow source_foo_vN target_bar_vN (class (perm)))
Satıcı politikası hiçbir zaman platformun ilerisinde olmadığından önceki sürümlerle ilgilenmemelidir. Ancak platform politikasının, satıcı politikasının ne kadar gerisinde olduğunu bilmesi, türlerine ilişkin öznitelikleri içermesi ve sürümlendirilmiş özniteliklere karşılık gelen politikayı ayarlaması gerekecektir.
Politika farklılıkları
Her türün sonuna _v N
ekleyerek otomatik olarak öznitelikler oluşturmak, özniteliklerin sürüm farklılıkları arasındaki türlerle eşlenmesi olmadan hiçbir işe yaramaz. Android, niteliklere ilişkin sürümler arasında bir eşlemeyi ve türlerin bu niteliklerle eşlenmesini sürdürür. Bu, yukarıda belirtilen eşleme dosyalarında (CIL) gibi ifadelerle yapılır:
(typeattributeset foo_vN (foo))
Platform yükseltmeleri
Aşağıdaki bölümde platform yükseltmelerine ilişkin senaryolar ayrıntılı olarak anlatılmaktadır.
Aynı türler
Bu senaryo, bir nesnenin ilke sürümlerindeki etiketleri değiştirmemesi durumunda ortaya çıkar. Bu, kaynak ve hedef türleri için aynıdır ve tüm sürümlerde binder_device
olarak etiketlenen /dev/binder
ile görülebilir. Dönüştürülen politikada şu şekilde temsil edilir:
binder_device_v1 … binder_device_vN
v1
→ v2
yükseltme yaparken platform politikası şunları içermelidir:
type binder_device; -> (type binder_device) (in CIL)
V1 eşleme dosyasında (CIL):
(typeattributeset binder_device_v1 (binder_device))
V2 eşleme dosyasında (CIL):
(typeattributeset binder_device_v2 (binder_device))
V1 satıcı politikasında (CIL):
(typeattribute binder_device_v1) (allow binder_device_v1 …)
V2 satıcı politikasında (CIL):
(typeattribute binder_device_v2) (allow binder_device_v2 …)
Yeni türler
Bu senaryo, platform yeni bir tür eklediğinde ortaya çıkar ve bu, yeni özellikler eklenirken veya politika sıkılaştırma sırasında gerçekleşebilir.
- Yeni özellik . Tür, daha önce var olmayan bir nesneyi (yeni bir hizmet süreci gibi) etiketlerken, satıcı kodu daha önce onunla doğrudan etkileşime girmedi, dolayısıyla karşılık gelen bir politika mevcut değil. Türe karşılık gelen yeni özniteliğin önceki sürümde bir özniteliği yoktur ve bu nedenle eşleme dosyasında bu sürümü hedefleyen bir girişe gerek yoktur.
- Politikanın sertleştirilmesi Tür politika sağlamlaştırmayı temsil ettiğinde, yeni tür özniteliğinin öncekine karşılık gelen bir öznitelik zincirine geri bağlanması gerekir (önceki örnekte
/sys/A
sysfs
sysfs_A
değiştirilmesine benzer şekilde). Satıcı kodu,sysfs
erişimi sağlayan bir kurala dayanır ve bu kuralı yeni türün bir özelliği olarak dahil etmesi gerekir.
v1
→ v2
yükseltme yaparken platform politikası şunları içermelidir:
type sysfs_A; -> (type sysfs_A) (in CIL) type sysfs; (type sysfs) (in CIL)
V1 eşleme dosyasında (CIL):
(typeattributeset sysfs_v1 (sysfs sysfs_A))
V2 eşleme dosyasında (CIL):
(typeattributeset sysfs_v2 (sysfs)) (typeattributeset sysfs_A_v2 (sysfs_A))
V1 satıcı politikasında (CIL):
(typeattribute sysfs_v1) (allow … sysfs_v1 …)
V2 satıcı politikasında (CIL):
(typeattribute sysfs_A_v2) (allow … sysfs_A_v2 …) (typeattribute sysfs_v2) (allow … sysfs_v2 …)
Kaldırılan türler
Bu (nadir) senaryo, bir tür kaldırıldığında ortaya çıkar ve temeldeki nesne şu durumlarda gerçekleşebilir:
- Kalır ancak farklı bir etiket alır.
- Platform tarafından kaldırılır.
Politikanın gevşetilmesi sırasında bir tür kaldırılır ve bu türle etiketlenen nesneye, halihazırda var olan farklı bir etiket verilir. Bu, öznitelik eşlemelerinin birleştirilmesi anlamına gelir: Satıcı kodunun, eskiden sahip olduğu öznitelikle temel nesneye hala erişebilmesi gerekir, ancak sistemin geri kalanı artık ona yeni özniteliğiyle erişebilmelidir.
Değiştirildiği öznitelik yeniyse, yeniden etiketleme yeni tür durumundakiyle aynıdır, ancak mevcut bir etiket kullanıldığında eski öznitelik yeni türün eklenmesi, diğer nesnelerin de bu türle etiketlenmesine neden olur. yeni erişilebilir olmak. Bu aslında platform tarafından yapılan şeydir ve uyumluluğu sürdürmek için kabul edilebilir bir ödün olarak kabul edilir.
(typeattribute sysfs_v1) (allow … sysfs_v1 …)
Örnek Versiyon 1: Türleri daraltma (sysfs_A'yı kaldırma)
v1
→ v2
yükseltme yaparken platform politikası şunları içermelidir:
type sysfs; (type sysfs) (in CIL)
V1 eşleme dosyasında (CIL):
(typeattributeset sysfs_v1 (sysfs)) (type sysfs_A) # in case vendors used the sysfs_A label on objects (typeattributeset sysfs_A_v1 (sysfs sysfs_A))
V2 eşleme dosyasında (CIL):
(typeattributeset sysfs_v2 (sysfs))
V1 satıcı politikasında (CIL):
(typeattribute sysfs_A_v1) (allow … sysfs_A_v1 …) (typeattribute sysfs_v1) (allow … sysfs_v1 …)
V2 satıcı politikasında (CIL):
(typeattribute sysfs_v2) (allow … sysfs_v2 …)
Örnek Versiyon 2: Tamamen kaldırma (foo tipi)
v1
→ v2
yükseltme yaparken platform politikası şunları içermelidir:
# nothing - we got rid of the type
V1 eşleme dosyasında (CIL):
(type foo) #needed in case vendors used the foo label on objects (typeattributeset foo_v1 (foo))
V2 eşleme dosyasında (CIL):
# nothing - get rid of it
V1 satıcı politikasında (CIL):
(typeattribute foo_v1) (allow foo …) (typeattribute sysfs_v1) (allow sysfs_v1 …)
V2 satıcı politikasında (CIL):
(typeattribute sysfs_v2) (allow sysfs_v2 …)
Yeni sınıf/izinler
Bu senaryo, bir platform yükseltmesi önceki sürümlerde bulunmayan yeni ilke bileşenlerini tanıttığında ortaya çıkar. Örneğin, Android, ekleme, bulma ve listeleme izinlerini oluşturan servicemanager
nesne yöneticisini eklediğinde, servicemanager
kaydolmak isteyen satıcı arka plan programlarının mevcut olmayan izinlere ihtiyacı vardı. Android 8.0'da yalnızca platform politikası yeni sınıflar ve izinler ekleyebilir.
Satıcı politikası tarafından oluşturulmuş veya genişletilmiş olabilecek tüm etki alanlarının yeni sınıfı engelleme olmaksızın kullanmasına izin vermek için platform politikasının aşağıdakine benzer bir kural içermesi gerekir:
allow {domain -coredomain} *:new_class perm;
Bu, satıcı imajının erişim kazandığından emin olmak için tüm arayüz (kamu politikası) türleri için erişime izin veren politikayı bile gerektirebilir. Bunun kabul edilemez bir güvenlik politikasıyla sonuçlanması durumunda (servis yöneticisi değişikliklerinde olabileceği gibi), potansiyel olarak satıcı yükseltmesi zorunlu olabilir.
Sınıf/izinler kaldırıldı
Bu senaryo, bir nesne yöneticisi ( ZygoteConnection
nesne yöneticisi gibi) kaldırıldığında ortaya çıkar ve sorunlara neden olmamalıdır. Nesne yöneticisi sınıfı ve izinleri, satıcı sürümü artık onu kullanmayana kadar ilkede tanımlı kalabilir. Bu, tanımların ilgili eşleme dosyasına eklenmesiyle yapılır.
Yeni/yeniden etiketlenen türler için satıcı özelleştirmesi
Yeni satıcı türleri, yeni süreçleri, ikili dosyaları, cihazları, alt sistemleri ve depolanan verileri tanımlamak için ihtiyaç duyulduğundan satıcı politikası geliştirmenin merkezinde yer alır. Bu nedenle satıcı tarafından tanımlanan türlerin oluşturulmasına izin verilmesi zorunludur.
Satıcı politikası her zaman cihazdaki en eski politika olduğundan, tüm satıcı türlerini otomatik olarak politikadaki niteliklere dönüştürmeye gerek yoktur. Platform, satıcı politikasında etiketlenen hiçbir şeye güvenmez çünkü platformun bu konuda hiçbir bilgisi yoktur; ancak platform, bu türlerle etiketlenmiş nesnelerle ( domain
, sysfs_type
vb. gibi) etkileşim kurmak için kullandığı öznitelikleri ve genel türleri sağlayacaktır. Platformun bu nesnelerle doğru şekilde etkileşime girmeye devam etmesi için niteliklerin ve türlerin uygun şekilde uygulanması gerekir ve özelleştirilebilir alanlara ( init
gibi) belirli kuralların eklenmesi gerekebilir.
Android 9 için özellik değişiklikleri
Android 9'a yükseltilen cihazlar aşağıdaki özellikleri kullanabilir ancak Android 9 ile başlatılan cihazlar kullanmamalıdır.
İhlal edenin özellikleri
Android 9, alanla ilgili şu özellikleri içerir:
-
data_between_core_and_vendor_violators
.vendor
vecoredomains
arasında dosyaların yola göre paylaşılmaması gerekliliğini ihlal eden tüm alan adları için özellik. Platform ve satıcı işlemleri iletişim kurmak için diskteki dosyaları kullanmamalıdır (kararsız ABI). Öneri:- Satıcı kodu
/data/vendor
kullanmalıdır. - Sistem
/data/vendor
kullanmamalıdır.
- Satıcı kodu
-
system_executes_vendor_violators
. Satıcı ikili dosyalarının yürütülmeme gerekliliğini ihlal eden tüm sistem etki alanlarına (init
veshell domains
hariç) ilişkin öznitelik. Satıcı ikili dosyalarının yürütülmesinde kararsız API var. Platform, satıcı ikili dosyalarını doğrudan yürütmemelidir. Öneri:- Satıcı ikili dosyalarına olan bu tür platform bağımlılıkları HIDL HAL'lerin arkasında olmalıdır.
VEYA
- Satıcı ikili dosyalarına erişmesi gereken
coredomains
, satıcı bölümüne taşınmalı ve bu nedenlecoredomain
olmayı bırakmalıdır.
- Satıcı ikili dosyalarına olan 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 olduğu düşünülenler dışında HwBinder hizmetlerine erişimi olmamalıdır (aşağıdaki güvenli hizmetlere bakın). Bunun iki ana nedeni şunlardır:
- HwBinder sunucuları istemci kimlik doğrulaması gerçekleştirmez çünkü HIDL şu anda arayanın UID bilgilerini açığa çıkarmaz. HIDL bu tür verileri açığa çıkarmış olsa bile birçok HwBinder hizmeti ya uygulamaların (HAL'ler gibi) altında bir seviyede çalışır ya da yetkilendirme için uygulama kimliğine güvenmemelidir. Bu nedenle, güvenli olmak için, varsayılan varsayım, her HwBinder hizmetinin tüm müşterilerine, hizmet tarafından sunulan işlemleri gerçekleştirme konusunda eşit yetkili olarak davrandığıdır.
- HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi),
system/core
bileşenlerine göre daha yüksek güvenlik sorunlarına sahip kod içerir ve yığının alt katmanlarına (donanımlara kadar) erişime sahiptir, böylece Android güvenlik modelini atlama fırsatları artar .
Güvenli hizmetler
Güvenli hizmetler şunları içerir:
-
same_process_hwservice
. Bu hizmetler (tanım gereği) istemcinin sürecinde çalışır ve dolayısıyla sürecin çalıştığı istemci etki alanıyla aynı erişime sahiptir. -
coredomain_hwservice
. Bu hizmetler 2 numaralı nedenden kaynaklanan riskler oluşturmaz. -
hal_configstore_ISurfaceFlingerConfigs
. Bu hizmet, herhangi bir alan adı tarafından kullanılmak üzere özel olarak tasarlanmıştır. -
hal_graphics_allocator_hwservice
. Bu işlemler aynı zamanda uygulamaların erişmesine izin 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
. Buhal_omx_hwservice
daha yeni bir sürümüdür.
Kullanılabilir özellikler
Güvenli sayılmayan tüm hwservices
untrusted_app_visible_hwservice
özniteliğine sahiptir. İlgili HAL sunucuları untrusted_app_visible_halserver
özelliğine sahiptir. Android 9 ile başlatılan cihazlar, untrusted
özelliklerden herhangi birini KULLANMAMALIDIR.
Öneri:
- Güvenilmeyen uygulamalar bunun yerine satıcı HIDL HAL ile konuşan bir sistem hizmetiyle iletişim kurmalıdır. Örneğin, uygulamalar
binderservicedomain
ile konuşabilir, ardındanmediaserver
(bu birbinderservicedomain
) ile dehal_graphics_allocator
ile konuşabilir.VEYA
-
vendor
HAL'lerine doğrudan erişime ihtiyaç duyan uygulamaların kendi satıcı tanımlı sepolicy etki alanına sahip olması gerekir.
Dosya öznitelik testleri
Android 9, belirli konumlardaki tüm dosyaların uygun özniteliklere sahip olmasını (örneğin, sysfs
tüm dosyaların gerekli sysfs_type
özniteliğine sahip olması gibi) sağlayan derleme zamanı testleri içerir.
Platform-kamu politikası
Platform genel politikası, yalnızca v1 ve v2'deki platform politikalarının birliğini korumadan Android 8.0 mimari modeline uymanın temelidir. Satıcılar, daha sonra satıcı politikasının bir parçası haline gelen, kullanılabilir türleri ve nitelikleri ve bu türler ve niteliklere ilişkin kuralları içeren bir platform politikası alt kümesine maruz kalır (ör. vendor_sepolicy.cil
).
Türler ve kurallar, satıcı tarafından oluşturulan politikada otomatik olarak attribute_v N
çevrilir, böylece platform tarafından sağlanan tüm türler sürümlendirilmiş öznitelikler olur (ancak öznitelikler sürümlendirilmez). Platform, satıcı politikasının işlemeye devam etmesini ve belirli bir sürüm için sağlanan kuralların dahil edilmesini sağlamak için sağladığı somut türlerin uygun niteliklerle eşleştirilmesinden sorumludur. Platform-genel politika ve satıcı politikasının birleşimi, bağımsız platform ve satıcı yapılarına izin veren Android 8.0 mimari modeli hedefini karşılıyor.
Özellik zincirlerine eşleme
İlke sürümleriyle eşlemek için öznitelikler kullanıldığında, bir tür bir öznitelikle veya birden çok öznitelikle eşleşir ve türle etiketlenen nesnelere, önceki türlerine karşılık gelen öznitelikler aracılığıyla erişilebilmesi sağlanır.
Sürüm bilgisini ilke yazarından gizleme hedefini sürdürmek, sürümlendirilmiş özniteliklerin otomatik olarak oluşturulması ve bunların uygun türlere atanması anlamına gelir. Statik türlerin genel durumunda bu basittir: type_foo
type_foo_v1
ile eşleşir.
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 politikasını sürdürenlerin, nesneler ve onlara atanan etiketler arasındaki ilişkinin anlaşılmasını ve bunun ne zaman gerçekleşeceğinin belirlenmesini gerektiren, nesneler için geçiş noktalarında eşlemenin nasıl oluşturulacağını belirlemesi gerekir. Geriye dönük uyumluluk için bu karmaşıklığın, yükselebilecek tek bölüm olan platform tarafında yönetilmesi gerekir.
Sürüm yükseltmeleri
Basitlik açısından, Android platformu, yeni bir sürüm dalı kesildiğinde bir sepolicy sürümü yayınlar. Yukarıda açıklandığı gibi sürüm numarası PLATFORM_SEPOLICY_VERSION
bulunur ve MM.nn
biçimindedir; burada MM
SDK değerine karşılık gelir ve nn
/platform/system/sepolicy.
Örneğin, Kitkat için 19.0
, Lollipop için 21.0
, Lollipop-MR1 için 22.0
Marshmallow için 23.0
, Nougat için 24.0
, Nougat-MR1 için 25.0
, Oreo için 26.0
, Oreo-MR1 için 27.0
ve Android 9 için 28.0
. Uprev'ler değildir. her zaman tam sayılar. Örneğin, bir sürümdeki MR artışı system/sepolicy/public
uyumsuz bir değişiklik gerektiriyor ancak bir API artışı gerektirmiyorsa bu sepolicy sürümü şu şekilde olabilir: vN.1
. Bir geliştirme dalında mevcut olan sürüm, nakliye cihazlarında asla kullanılmayan 10000.0
sürümüdür.
Android, güncelleme sırasında en eski sürümü kullanımdan kaldırabilir. Bir sürümün ne zaman kullanımdan kaldırılacağına ilişkin girdi sağlamak için Android, satıcı politikalarına sahip, o Android sürümünü çalıştıran ve hâlâ önemli platform güncellemelerini alan cihazların sayısını toplayabilir. Sayı belirli bir eşiğin altındaysa o sürüm kullanımdan kaldırılır.
Birden çok özelliğin performans etkisi
https://github.com/SELinuxProject/cil/issues/9 adresinde açıklandığı gibi, bir türe atanan çok sayıda öznitelik, politika önbelleğinin kaçırılması durumunda performans sorunlarına neden olur.
Bunun Android'de bir sorun olduğu doğrulandı, bu nedenle politika derleyicisi tarafından politikaya eklenen özelliklerin yanı sıra kullanılmayan özellikleri kaldırmak için Android 8.0'da değişiklikler yapıldı . Bu değişiklikler performans gerilemelerini çözdü.
System_ext genel ve ürün genel politikası
Android 11'den başlayarak, system_ext ve ürün bölümlerinin, belirlenen genel türlerini satıcı bölümüne aktarmalarına izin verilmektedir. Platform genel politikası gibi, satıcı da otomatik olarak versiyonlanmış özniteliklere çevrilen türleri ve kuralları kullanır; örneğin type
type_ N
; burada N
, satıcı bölümünün oluşturulduğu platformun sürümüdür.
system_ext ve ürün bölümleri aynı platform sürümü N
temel aldığında, yapı sistemi, system_ext/etc/selinux/mapping/ N .cil
ve product/etc/selinux/mapping/ N .cil
için kimlik içeren temel eşleme dosyaları oluşturur. type
type_ N
eşlemeler. Satıcı, type_ N
sürümlü niteliğiyle type
erişebilir.
Yalnızca system_ext ve ürün bölümlerinin güncellenmesi durumunda, örneğin N
N+1
(veya daha sonra) satıcı N
kalırken, satıcı system_ext ve ürün bölümleri türlerine erişimini kaybedebilir. Kırılmayı önlemek için, system_ext ve ürün bölümleri, dosyaların somut türlerden type_ N
niteliklerine eşlenmesini sağlamalıdır. Her iş ortağı, N+1
(veya üzeri) system_ext ve ürün bölümleriyle N
satıcıyı destekleyecekse, eşleme dosyalarının bakımından sorumludur.
Bunu yapmak için ortaklardan beklenenler:
- 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 üzeri) system_ext ve ürün bölümlerine yükleyin.
Örneğin, N
system_ext'in foo_type
adında bir ortak türe sahip olduğunu varsayalım. Daha sonra N
system_ext bölümündeki system_ext/etc/selinux/mapping/ N .cil
şöyle görünecektir:
(typeattributeset foo_type_N (foo_type)) (expandtypeattribute foo_type_N true) (typeattribute foo_type_N)
N+1
system_ext'e bar_type
eklenirse ve N
satıcı için bar_type
foo_type
ile eşlenmesi gerekiyorsa, N .cil
şu adresten güncellenebilir:
(typeattributeset foo_type_N (foo_type))
ile
(typeattributeset foo_type_N (foo_type bar_type))
ve ardından N+1
system_ext'in bölümüne kuruldu. N
satıcı, N+1
system_ext'in foo_type
ve bar_type
öğelerine erişmeye devam edebilir.
SELinux bağlamları etiketlemesi
Platform ve satıcı politikası arasındaki ayrımı desteklemek için sistem, SELinux içerik dosyalarını ayrı tutacak şekilde farklı şekilde oluşturur.
Dosya bağlamları
Android 8.0, file_contexts
için aşağıdaki değişiklikleri getirdi:
- Önyükleme sırasında aygıtta ek derleme yükünü önlemek için,
file_contexts
ikili formdaki varlığı sona erer. Bunun yerine,{property, service}_contexts
(7.0 öncesi oldukları gibi) gibi okunabilir, düzenli ifade metin dosyalarıdırlar. -
file_contexts
iki dosya arasında bölünmüştür:-
plat_file_contexts
- Sepolicy dosyalarının düzgün çalışmasını sağlamak için tam olarak etiketlenmesi gereken
/vendor
bölümünün etiketleme parçaları dışında, cihaza özel etiketleri olmayan Android platformufile_context
. - Cihazdaki
/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ştirilmesiyle oluşturulan cihaza özelfile_context
. -
vendor
bölümünde/vendor/etc/selinux/vendor_file_contexts
konumuna kurulmalı ve başlangıçtainit
tarafındanfile_context
platformuyla birlikte yüklenmelidir.
- Cihazın
-
Mülk bağlamları
Android 8.0'da property_contexts
iki dosya arasında bölünmüştür:
-
plat_property_contexts
- Cihaza özel etiketi olmayan Android platformu
property_context
. -
/system/etc/selinux/plat_property_contexts
adresindekisystem
bölümünde bulunmalı ve satıcıproperty_contexts
ile birlikte başlangıçtainit
tarafından yüklenmelidir.
- Cihaza özel etiketi 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 platformproperty_context
ile birlikte başlangıçtainit
tarafından 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 özelservice_context
.service_context
cihaza özel etiketleri yoktur. -
/system/etc/selinux/plat_service_contexts
adresindekisystem
bölümünde bulunmalı ve satıcıservice_contexts
ile birlikte başlangıçtaservicemanager
tarafından 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 özelservice_context
. -
/vendor/etc/selinux/vendor_service_contexts
adresindekivendor
bölümünde bulunmalı veservice_contexts
platformuyla birlikte başlangıçtaservicemanager
tarafından yüklenmelidir. -
servicemanager
önyükleme sırasında bu dosyayı arasa da, tamamen uyumlu birTREBLE
aygıtı için,vendor_service_contexts
mevcut OLMAMALIDIR. Bunun nedeni,vendor
vesystem
işlemleri arasındaki tüm etkileşiminhwservicemanager
/hwbinder
üzerinden geçmesi GEREKLİDİR.
- Cihazın
-
plat_hwservice_contexts
- Cihaza özel etiketleri olmayan
hwservicemanager
içinhwservice_context
Android platformu. -
/system/etc/selinux/plat_hwservice_contexts
adresindekisystem
bölümünde bulunmalı ve başlangıçtavendor_hwservice_contexts
ile birliktehwservicemanager
tarafından yüklenmelidir.
- Cihaza özel etiketleri olmayan
-
vendor_hwservice_contexts
- Cihazın
Boardconfig.mk
dosyalarındaBOARD_SEPOLICY_DIRS
tarafından işaret edilen dizinlerde bulunanhwservice_contexts
birleştirilmesiyle oluşturulan cihaza özelhwservice_context
. -
/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ştirilmesiyle 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
Seapp bağlamları
Android 8.0'da seapp_contexts
iki dosya arasında bölünmüştür:
-
plat_seapp_contexts
- Cihaza özel hiçbir değişikliği olmayan Android platformu
seapp_context
. - /system/etc/selinux/plat_seapp_contexts adresindeki
system
bölümünde bulunmalıdır/system/etc/selinux/plat_seapp_contexts.
- Cihaza özel hiçbir değişikliği 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şturulmuş,seapp_context
platformuna yönelik cihaza özel uzantı. -
/vendor/etc/selinux/vendor_seapp_contexts
konumundakivendor
bölümünde bulunmalıdır.
- Cihazın
MAC izinleri
Android 8.0'da mac_permissions.xml
iki dosyaya bölünmüştür:
-
mac_permissions.xml
platformu- Cihaza özel hiçbir değişikliği olmayan Android platformu
mac_permissions.xml
. - /system/etc/selinux/ adresindeki
system
bölümünde bulunmalıdır/system/etc/selinux/.
- Cihaza özel hiçbir değişikliği 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