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|| |
|okunabilir|| |
|Sadece oku|| |
|kalici|| |
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:
| ||Platform tarafından sağlanan etiket||Etikete bağlı olarak platform işlemleri|
| || || Framework, |


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,
vendorbö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
vendorbölümüne eklenen tüm yeni
exec_types,
vendor_file_typeözniteliğine sahip olmalıdır. Bu, Neverallows aracılığıyla uygulanır.
- Gelecekteki platform/çerçeve güncellemeleriyle çakışmaları önlemek için
vendorbölümünde
exec_typesdışındaki dosyaları etiketlemekten kaçının.
- AOSP tarafından tanımlanan aynı işlem HAL'leri için tüm kitaplık bağımlılıkları,
same_process_hal_file.
Procfs (/proc)
/proc içindeki dosyalar sadece
genfscon etiketi kullanılarak etiketlenebilir. Android 7.0'da, hem platform hem de satıcı politikası,
genfscon içindeki dosyaları etiketlemek için
procfs .
Öneri: Yalnızca platform ilkesi etiketleri
/proc .
vendor süreçlerinin
/proc içindeki ve şu anda varsayılan etiketle (
proc ) etiketlenmiş dosyalara erişmesi gerekiyorsa, satıcı politikası bunları açıkça etiketlememeli ve bunun yerine satıcı etki alanları için kurallar eklemek için genel
proc türünü kullanmalıdır. Bu, platform güncellemelerinin,
procfs aracılığıyla açığa çıkan gelecekteki çekirdek arabirimlerini barındırmasına ve gerektiğinde bunları açıkça etiketlemesine olanak tanır.
Debugfs (/sys/kernel/debug)
Debugfs hem
file_contexts hem de
genfscon içinde etiketlenebilir. Android 7.0 ila Android 10'da hem platform hem de satıcı etiketi
debugfs .
Android 11'de
debugfs üretim cihazlarına erişilemez veya bunlar yüklenemez. Cihaz üreticileri
debugfs kaldırmalıdır.
Tracef'ler (/sys/kernel/debug/tracing)
Tracefs hem
file_contexts hem de
genfscon içinde etiketlenebilir. Android 7.0'da, yalnızca platform
tracefs etiketler.
Öneri:
tracefs yalnızca platform etiketleyebilir.
Sysfs (/sys)
/sys içindeki dosyalar hem
file_contexts hem de
genfscon kullanılarak etiketlenebilir. Android 7.0'da hem platform hem de satıcı,
sysfs içindeki dosyaları etiketlemek için
file_contexts ve
genfscon kullanır.
Öneri: Platform, cihaza özgü olmayan
sysfs düğümlerini etiketleyebilir. Aksi takdirde, yalnızca satıcı dosyaları etiketleyebilir.
tmpfs (/dev)
/dev içindeki dosyalar
file_contexts içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket dosyaları burada.
Öneri: Satıcı yalnızca
/dev/vendor içindeki dosyaları etiketleyebilir (örneğin,
/dev/vendor/foo ,
/dev/vendor/socket/bar ).
Kökler (/)
/ içindeki dosyalar
file_contexts içinde etiketlenebilir. Android 7.0'da hem platform hem de satıcı etiket dosyaları burada.
Öneri:
/ içindeki dosyaları yalnızca sistem etiketleyebilir.
Veri (/veri)
Veriler,
file_contexts ve
seapp_contexts kombinasyonu aracılığıyla etiketlenir.
Öneri:
/data/vendor dışında satıcı etiketlemesine izin vermeyin. Yalnızca platform
/data data'nın diğer kısımlarını etiketleyebilir.
Uyumluluk özellikleri
SELinux ilkesi, belirli nesne sınıfları ve izinleri için kaynak ve hedef türleri arasındaki bir etkileşimdir. SELinux ilkesinden etkilenen her nesne (işlemler, dosyalar, vb.) yalnızca bir türe sahip olabilir, ancak bu türün birden çok özniteliği olabilir.
Politika çoğunlukla mevcut türler açısından yazılır:
allow source_type target_type:target_class permission(s);
Bu işe yarar çünkü politika her türden bilgiyle yazılmıştır. Ancak, satıcı ilkesi ve platform ilkesi belirli türleri kullanıyorsa ve belirli bir nesnenin etiketi bu ilkelerden yalnızca birinde değişiyorsa, diğeri daha önce güvenilen erişimi kazanmış veya kaybetmiş olan ilkeyi içerebilir. Örneğin:
File_contexts: /sys/A u:object_r:sysfs:s0 Platform: allow p_domain sysfs:class perm; Vendor: allow v_domain sysfs:class perm;
Şu şekilde değiştirilebilir:
File_contexts: /sys/A u:object_r:sysfs_A:s0
Satıcı ilkesi aynı kalacak olsa da, yeni
sysfs_A türü için ilke eksikliği nedeniyle
v_domain erişimi kaybedecekti.
Öznitelikler açısından bir ilke tanımlayarak, temel alınan nesneye hem platform hem de satıcı kodu için ilkeye karşılık gelen bir özniteliğe sahip bir tür verebiliriz. Bu, somut tiplerin asla kullanılmadığı bir nitelik politikası oluşturmak için tüm tipler için yapılabilir. Uygulamada, bu yalnızca, satıcı ilkesinin bir parçası olarak oluşturulan platform genel ilkesi olarak tanımlanan ve sağlanan, platform ve satıcı arasında örtüşen ilke bölümleri için gereklidir.
Kamu politikasını sürümlü nitelikler olarak tanımlamak, iki ilke uyumluluğu hedefini karşılar:
- Satıcı kodunun platform güncellemesinden sonra çalışmaya devam etmesini sağlayın . Erişimi koruyarak, satıcı kodunun dayandığı nesnelere karşılık gelen nesneler için somut türlere nitelikler ekleyerek elde edilir.
- Politikayı kullanımdan kaldırma yeteneği . İlke kümelerini, karşılık gelen sürüm artık desteklenmez kaldırılabilir özniteliklere açıkça tanımlayarak elde edilir. Geliştirme, platformda devam edebilir, eski politikanın satıcı politikasında hala mevcut olduğunu ve yükseltildiğinde/eğer yükseltilirse otomatik olarak kaldırılacağını bilerek.
Politika yazılabilirliği
Politika geliştirme için belirli sürüm değişiklikleri bilgisi gerektirmeme hedefini karşılamak için Android 8.0, platform-kamu politikası türleri ve bunların nitelikleri arasında bir eşleme içerir.
foo türü,
foo_v N özniteliğine eşlenir; burada
N , hedeflenen sürümdür.
vN ,
PLATFORM_SEPOLICY_VERSION yapı değişkenine karşılık gelir ve
MM.NN biçimindedir; burada
MM , platform SDK numarasına karşılık gelir ve
NN , platform güvenlik ilkesine özel bir sürümdür.
Genel ilkedeki öznitelikler sürümlendirilmemiştir, bunun yerine iki bölüm arasındaki arabirimi sabit tutmak için platform ve satıcı ilkesinin oluşturulabileceği bir API olarak bulunur. Hem platform hem de satıcı politikası yazarları, bugün yazıldığı gibi politika yazmaya devam edebilir.
allow source_foo target_bar: class perm ; satıcı politikasının bir parçası olarak dahil edilmiştir. Derleme sırasında (ilgili sürümü içerir), cihazın satıcı kısmına gidecek olan ilkeye dönüştürülür (dönüştürülmüş Ortak Ara Dilde (CIL) gösterilir):
(allow source_foo_vN target_bar_vN (class (perm)))
Satıcı politikası hiçbir zaman platformun ilerisinde olmadığından, önceki sürümlerle ilgilenmemelidir. Bununla birlikte, platform ilkesinin satıcı ilkesinin ne kadar geride olduğunu bilmesi, türlerine öznitelikler eklemesi ve sürümlü özniteliklere karşılık gelen ilkeyi ayarlaması gerekir.
Politika farklılıkları
Her türün sonuna
_v N ekleyerek otomatik olarak öznitelikler oluşturmak, öznitelikleri sürüm farklarındaki türlerle eşlemeden hiçbir şey yapmaz. Android, öznitelikler için sürümler arasında bir eşleme ve bu özniteliklerle türlerin eşleştirilmesini sağlar. Bu, (CIL) gibi ifadelerle yukarıda belirtilen eşleme dosyalarında yapılır:
(typeattributeset foo_vN (foo))
Platform yükseltmeleri
Aşağıdaki bölüm, platform yükseltmeleri için senaryoları detaylandırmaktadır.
aynı tipler
Bu senaryo, bir nesne ilke sürümlerinde etiketleri değiştirmediğinde ortaya çıkar. Bu, kaynak ve hedef türleri için aynıdır ve tüm sürümlerde
binder_device olarak etiketlenen
/dev/binder ile görülebilir. Dönüştürülen politikada şu şekilde temsil edilir:
binder_device_v1 … binder_device_vN
v1 →
v2 yükseltme yaparken, platform ilkesi şunları içermelidir:
type binder_device; -> (type binder_device) (in CIL)
v1 eşleme dosyasında (CIL):
(typeattributeset binder_device_v1 (binder_device))
v2 eşleme dosyasında (CIL):
(typeattributeset binder_device_v2 (binder_device))
v1 satıcı politikasında (CIL):
(typeattribute binder_device_v1) (allow binder_device_v1 …)
v2 satıcı politikasında (CIL):
(typeattribute binder_device_v2) (allow binder_device_v2 …)
Yeni türler
Bu senaryo, platform yeni bir tür eklediğinde ortaya çıkar; bu, yeni özellikler eklenirken veya ilke katılaştırması sırasında gerçekleşebilir.
- Yeni özellik . Tür, daha önce var olmayan bir nesneyi etiketlediğinde (yeni bir hizmet süreci gibi), satıcı kodu daha önce onunla doğrudan etkileşime girmediğinden, karşılık gelen bir politika yoktur. Türe karşılık gelen yeni öznitelik, önceki sürümde bir özniteliğe sahip değildir ve bu nedenle, eşleme dosyasında o sürümü hedefleyen bir girişe ihtiyaç duymaz.
- Politika sertleştirme . Tür, ilke katılaştırmasını temsil ettiğinde, yeni tür özniteliği, öncekine karşılık gelen bir öznitelik zincirine geri bağlanmalıdır (
/sys/Aöğesinin
sysfs
sysfs_Aolarak değiştirilmesine benzer bir önceki örneğe benzer). Satıcı kodu,
sysfseriş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.
vendorve ana etki alanları arasında yola göre dosya paylaşmama gereksinimini ihlal eden tüm etki alanları için
coredomains. Platform ve satıcı süreçleri, iletişim kurmak için diskteki dosyaları kullanmamalıdır (kararsız ABI). Öneri:
- Satıcı kodu
/data/vendorkullanmalıdır.
- Sistem
/data/vendorkullanmamalı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ı (
initve
shell domainshariç) 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
coredomainsgereken ç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/corebileşenlerine göre güvenlik sorunlarının görülme oranı daha yüksek olan kodlar içerir ve yığının alt katmanlarına (donanımdan donanıma kadar) erişime sahiptir, böylece Android güvenlik modelini atlama fırsatlarını artırır .
Güvenli hizmetler
Güvenli hizmetler şunları içerir:
-
same_process_hwservice. Bu hizmetler (tanım gereği) istemci sürecinde çalışır ve dolayısıyla sürecin çalıştığı istemci etki alanıyla aynı erişime sahiptir.
-
coredomain_hwservice. Bu hizmetler neden #2 ile ilişkili riskler oluşturmaz.
-
hal_configstore_ISurfaceFlingerConfigs. Bu hizmet, herhangi bir etki alanı tarafından kullanılmak üzere özel olarak tasarlanmıştır.
-
hal_graphics_allocator_hwservice. Bu işlemler ayrıca, uygulamaların erişmesine izin verilen
surfaceflingerBinder hizmeti tarafından da sunulmaktadır.
-
hal_omx_hwservice. Bu, uygulamaların erişmesine izin verilen
mediacodecBinder hizmetinin HwBinder sürümüdür.
-
hal_codec2_hwservice. Bu,
hal_omx_hwservicedaha 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
binderservicedomainile konuşabilir, ardından
mediaserver(bir
binderservicedomainolan) sırayla
hal_graphics_allocatorile konuşur.
VEYA
-
vendorHAL'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:
-
Nsystem_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_contextsikili 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_contextsiki dosya arasında bölünür:
-
plat_file_contexts
-
/vendorbölümünün, sepolicy dosyalarının düzgün çalışmasını sağlamak için tam olarak etiketlenmesi gereken bölümlerinin etiketlenmesi dışında, cihaza özel etiketlere sahip olmayan Android platformu
file_context.
-
/system/etc/selinux/plat_file_contexts
systembölümünde bulunmalı ve
inittarafından, satıcı
file_contextile birlikte yüklenmelidir.
-
-
vendor_file_contexts
- Aygıtın
Boardconfig.mkdosyalarında
BOARD_SEPOLICY_DIRStarafından gösterilen dizinlerde bulunan
file_contextsbirleştirilmesiyle oluşturulan aygıta özgü
file_context.
- Satıcı bölümünde /
vendor
/vendor/etc/selinux/vendor_file_contextsve
inittarafından
file_contextplatformuyla 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_contextsadresindeki
systembölümünde bulunmalı ve satıcı
property_contextsile birlikte başlangıçta
inittarafından yüklenmelidir.
- Cihaza özel etiketleri olmayan Android platformu
-
vendor_property_contexts
- Cihazın
Boardconfig.mkdosyalarında
BOARD_SEPOLICY_DIRStarafından işaret edilen dizinlerde bulunan
property_contextsbirleştirilmesiyle oluşturulmuş cihaza özel
property_context.
-
/vendor/etc/selinux/vendor_property_contexts
vendorbölümünde bulunmalı ve başlangıçta platform
property_contextile birlikte
inittarafı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
-
servicemanageriçin Android platformuna özel
service_context.
service_contextcihaza özel etiketi yok.
-
/system/etc/selinux/plat_service_contexts
systembölümünde bulunmalı ve başlangıçta
servicemanagertarafından satıcı
service_contextsile birlikte yüklenmelidir.
-
-
vendor_service_contexts
- Cihazın
service_contextdosyalarında
BOARD_SEPOLICY_DIRStarafından gösterilen dizinlerde bulunan
service_contextsbirleştirilmesiyle oluşturulan cihaza özel
Boardconfig.mk.
-
/vendor/etc/selinux/vendor_service_contexts
vendorbölümünde bulunmalı ve başlangıçta
servicemanagertarafından
service_contextsplatformuyla birlikte yüklenmelidir.
-
servicemanagerönyükleme sırasında bu dosyayı arasa da, tam uyumlu bir
TREBLEaygıtı için
vendor_service_contextsOLMAMALIDIR. Bunun nedeni,
vendorve
systemsüreçleri arasındaki tüm etkileşimin
hwservicemanager/
hwbindergeçmesi ZORUNLUDUR.
- Cihazın
-
plat_hwservice_contexts
- Cihaza özel etiketlere sahip olmayan
hwservicemanageriçin Android platformu
hwservice_context.
-
/system/etc/selinux/plat_hwservice_contextsadresindeki
systembölümünde bulunmalı ve başlangıçta hwservicemanager tarafından
hwservicemanagerile birlikte
vendor_hwservice_contexts.
- Cihaza özel etiketlere sahip olmayan
-
vendor_hwservice_contexts
- Cihazın
hwservice_contextdosyalarında
BOARD_SEPOLICY_DIRStarafından gösterilen dizinlerde bulunan
hwservice_contextsbirleştirilmesiyle oluşturulan cihaza özel
Boardconfig.mk.
-
/vendor/etc/selinux/vendor_hwservice_contexts
vendorbölümünde bulunmalı ve başlangıçta hwservicemanager tarafından
hwservicemanagerile birlikte
plat_service_contexts.
- Cihazın
-
vndservice_contexts
- Cihazın
service_context
vndservicemanagertarafından gösterilen dizinlerde bulunan
vndservice_contextsbirleştirilmesiyle oluşturulan
BOARD_SEPOLICY_DIRSiçin cihaza özel
Boardconfig.mk.
- Bu dosya
/vendor/etc/selinux/vndservice_contexts
vendorbölümünde bulunmalı ve başlangıçta
vndservicemanagertarafı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.adresindeki
systembölümünde bulunmalıdır.
- Cihaza özel değişiklik içermeyen Android platformu
-
vendor_seapp_contexts
- Cihazın
Boardconfig.mkdosyalarında
BOARD_SEPOLICY_DIRStarafından işaret edilen dizinlerde bulunan
seapp_contextsbirleştirilmesiyle oluşturulmuş
seapp_contextplatformuna yönelik cihaza özel uzantı.
-
/vendor/etc/selinux/vendor_seapp_contextsadresindeki
vendorbö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/.adresindeki
systembölümünde bulunmalıdır.
- Cihaza özel değişiklik içermeyen Android platformu
- Platform
mac_permissions.xml
- Cihazın
Boardconfig.mkdosyalarında
BOARD_SEPOLICY_DIRStarafından gösterilen dizinlerde bulunan
mac_permissions.xmloluşturulmuş platform
mac_permissions.xmliçin cihaza özel uzantı.
-
/vendor/etc/selinux/.adresindeki
vendorbölümünde bulunmalıdır.
- Cihazın