Politika Uyumluluğu

Bu makalede, Android'in politika uyumluluğu sorunlarını nasıl ele aldığı açıklanmaktadır. yeni platform SELinux ayarlarının eski tedarikçiden farklı olabileceği platform OTA'ları ile SELinux ayarları.

Treble tabanlı SELinux politika tasarımı, ikili ayrımı dikkate alır platform ve tedarikçi firma politikası arasında; şema, tedarikçi bölümlerinin bağımlılıklar oluşturması durumunda daha karmaşık hale gelir. platform < vendor < oem.

Android 8.0 ve sonraki sürümlerde, SELinux genel politikası özel ve genel bileşenler. Herkese açık bileşenler politikadan ve politikadan oluşur altyapıyı güçlendirmek için de kullanılabilir. Bu politika, tedarikçilerin tarafından sağlanan bir tedarikçi firma politikası dosyası. cihaz için tamamen işlevsel bir politika sağlar.

  • Sürüm belirleme işlemi için dışa aktarılan herkese açık platform politikası şu şekilde yazılır: özellikler hakkında daha fazla bilgi edinin.
  • Politika yazma kolaylığı için dışa aktarılan türler sürümlü özellikleri kullanabilirsiniz. Herkese açık tedarikçinin sağladığı etiketleme kararlarında doğrudan kullanılabilir. bağlam dosyalarını da kullanabilirsiniz.

Android, platformda dışa aktarılan beton türleri arasında eşleme sağlar politikası ve her platform için karşılık gelen sürüm özellikleri sürümü) tıklayın. Bu, nesneler bir türle etiketlendiğinde, Platformun genel politikasında belirtilen davranışı ihlal etmediğinden, sürümünü değil. Bu eşleme, her platform sürümü için ayrı bir platform sunar. Her platform sürümü için özellik üyeliği bilgilerini tutar. Genel politikada dışa aktarılan tür.

Nesne sahipliği ve etiketleme

Android 8.0 ve sonraki sürümlerde politika özelleştirilirken sahiplik açıkça tanımlanmalıdır. her nesnenin arka arka planını değiştirebilirsiniz. Örneğin, tedarikçi firma /dev/foo, platformu da etiketler /dev/foo sonraki bir OTA'da tanımlanmamış davranış olacaktır. Örneğin, SELinux'ta, bu durum bir etiketleme çakışması olarak ortaya çıkar. Cihaz düğümünde yalnızca bir tek bir etiket vardır. Bu, en son uygulanan etikete çözümlenir. Sonuç olarak:

  • Başarısız bir şekilde uygulanan etikete erişimi gereken işlemler, kaynağa erişimi kaybeder.
  • Dosyaya erişim sağlayan işlemler, yanlış cihaz düğümü oluşturuldu.

Sistem özellikleri de sistemde tanımlanmamış davranış (ve SELinux etiketlemesi) hakkında daha fazla bilgi edinin. Çarpışmalar SELinux'a sahip herhangi bir nesne için platform ve satıcı etiketleri arasında oluşabilir etiketi özellikleri, hizmetleri, işlemleri, dosyaları ve yuvaları içerir. Kaçınılması gerekenler bu öğelerin sahipliğini açıkça tanımlamanız gerekir.

Etiket çakışmalarına ek olarak SELinux tür/özellik adları da çakışabilir. Tür/özellik adı çakışması, her zaman politika derleyici hatasına neden olur.

Tür/özellik ad alanı

SELinux, aynı tür/özelliğe sahip birden fazla bildirime izin vermez. Politika derlenemez. Dosya yazarken kullanılan özellik adı çakışmaları olduğunda, tüm tedarikçi firma bildirimleri ad alanı olmalıdır. vendor_ ile başlıyor. 

type foo, domain; → type vendor_foo, domain;

Sistem özelliği ve işleme etiketleme sahipliği

Etiketleme çakışmalarının önlenmesinde en iyi çözüm, mülk ad alanları kullanılarak çözülür. Alıcı: platform özelliklerini kolayca tanımlayabilir ve yeniden adlandırma sırasında ya da dışa aktarılan platform özelliklerini eklemek, tüm tedarikçi firma özelliklerinin kendi önekleri:

Mülk türü Kabul edilebilir ön ekler
kontrol özellikleri ctl.vendor.
ctl.start$vendor.
ctl.stop$vendor.
init.svc.vendor.
okunabilir vendor.
salt okunur ro.vendor.
ro.boot.
ro.hardware.
kalıcı persist.vendor.

Tedarikçiler ro.boot.* (çekirdekten gelen) kullanmaya devam edebilir cmdline) ve ro.hardware.* (donanımla ilgili bariz bir özellik).

init rc dosyalarındaki tüm tedarikçi firma hizmetlerinde vendor. olmalıdır for services init rc files in init rc files of non-sistem dışı bölümlerin init rc dosyaları. Benzer kurallar satıcı özellikleri (vendor_) için SELinux etiketlerine uygulandı (tedarikçi firma özellikleri için).

Dosya sahipliği

Dosyalar için çakışmaları önlemek zordur, çünkü platform ve tedarikçi firma politikası da genellikle tüm dosya sistemleri için etiketler sağlar. Tür adlandırmadan farklı olarak ve bunların çoğu Google Analytics 4.3.2017 tarafından kernel'e gidin. Bu çakışmaları önlemek için dosya sistemlerinin adlandırma kılavuzunu uygulayın ele alacağız. Android 8.0 için bunlar teknik olmayan önerilerdir yaptırımı. Gelecekte bu öneriler Tedarikçi Firma Test Paketi (VTS).

Sistem (/system)

/system bileşen için etiketler yalnızca sistem görüntüsü tarafından sağlanmalıdır file_contexts, service_contexts vb. aracılığıyla. Etiketler /system bileşen /vendor politikasına eklendi. OTA güncellemesi yapılamayabilir.

Tedarikçi firma (/vendor)

AOSP SELinux politikası, vendor bölümünün bazı bölümlerini zaten etiketliyor platform etkileşime girer. Bu, platform için SELinux kurallarının yazılmasını sağlar vendor ürününün belirli kısımlarında konuşma ve/veya bunlara erişme işlemlerini bölüm. Örnekler:

/vendor yol Platform tarafından sağlanan etiket Platform, etikete bağlı olarak işlenir
/vendor(/.*)? vendor_file Çerçevedeki tüm HAL müşterileri, 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, belirli kurallara uyulması gerekir ( vendor içindeki ek dosyalar etiketlenirken neverallows) bölüm:

  • vendor_file , şuradaki tüm dosyalar için varsayılan etiket olmalıdır: vendor bölüm. Platform politikası uyarınca geçişli HAL uygulamalarını ele alacağız.
  • Tüm yeni exec_types, vendor bölümüne eklendi aracılığıyla iletilecek satıcı SEPolicy, vendor_file_type özelliğine sahip olmalıdır. Bu asla izin vermeyerek zorlanır.
  • Gelecekteki platform/çerçeve güncellemeleriyle çakışma olmaması için etiketlemeden kaçının vendor bölümünde exec_types dışındaki dosyalar.
  • AOSP tarafından tanımlanan aynı işlem HAL'leri için tüm kitaplık bağımlılıkları same_process_hal_file. olarak etiketlendi

Procf'ler (/proc)

/proc klasöründeki dosyalar yalnızca genfscon kullanılarak etiketlenebilir etiket. Android 7.0'da hem platform ve tedarikçi firma politika procfs klasöründeki dosyaları etiketlemek için genfscon kullanıldı.

Öneri: Yalnızca platform politikası etiketleri /proc. vendor işlemin /proc ürününde şu dosyalara erişmesi gerekiyorsa: şu anda varsayılan etiketle (proc), tedarikçi firma politikasıyla etiketlenmiştir açık bir şekilde etiketlenmemeli ve onun yerine Tedarikçi firma alanlarına kural eklemek için proc türünü kullanın. Bu, platformun gelecekteki çekirdek arayüzlerini kapsayacak şekilde güncelleme yapmak için procfs ve gerektiğinde açıkça etiketleyin.

Debugf'lar (/sys/kernel/debug)

Debugfs hem file_contexts hem de genfscon. Android 7.0 ile Android 10 arasındaki sürümlerde hem platform hem de satıcı etiketi debugfs

Android 11'de debugfs, Bunlar üretim cihazlarına eklenir. Cihaz üreticileri, debugfs öğesini kaldır

Tracef'ler (/sys/çekirdek/debug/izleme)

Tracefs hem file_contexts hem de genfscon. Android 7.0'da yalnızca platform etiketleri tracefs

Öneri: tracefs yalnızca platform tarafından etiketlenebilir.

Sysf'ler (/sys)

/sys klasöründeki dosyalar hem file_contexts kullanılarak etiketlenebilir ve genfscon. Android 7.0'da hem platform hem de satıcı kullanımı Dosyaları etiketlemek için file_contexts ve genfscon sysfs.

Öneri: Platform, sysfs şeklinde etiketleyebilir. düğümlere dokunun. Aksi takdirde, dosyaları yalnızca tedarikçi firma etiketleyebilir.

geçici dosya depolama noktaları (/dev)

/dev klasöründeki dosyalar file_contexts etiketinde etiketlenmiş olabilir. İçinde Android 7.0, hem platform hem de satıcı etiketi dosyalarını burada bulabilirsiniz.

Öneri: Tedarikçi firma yalnızca /dev/vendor (ör. /dev/vendor/foo, /dev/vendor/socket/bar) tıklayın.

Rootflar (/)

/ klasöründeki dosyalar file_contexts etiketinde etiketlenmiş olabilir. Android'de 7.0 sürümünü yükleyebilirsiniz.

Öneri: / içindeki dosyaları yalnızca sistem etiketleyebilir.

Veri (/veri)

Veriler, file_contexts ve seapp_contexts.

Öneri: dışında tedarikçi firma etiketlemeye izin vermeyin /data/vendor. Yalnızca platform diğer bölümlerini etiketleyebilir /data

Uyumluluk özellikleri

SELinux politikası, belirli kullanıcılar için kaynak ve hedef türleri arasındaki nesne sınıfları ve izinleri. Etkilenen her nesne (işlemler, dosyalar vb.) by SELinux politikası yalnızca bir türe sahip olabilir, ancak bu tür birden çok özellikleri hakkında daha fazla bilgi edinin.

Politika daha çok mevcut türler bağlamında yazılır: 

allow source_type target_type:target_class permission(s);

Politika her türden bilgi kullanılarak yazıldığı için bu yöntem işe yarar. Ancak, Tedarikçi firma politikası ve platform politikası belirli türleri kullanıyorsa ve yalnızca birinde belirli nesne değişiklikleri söz konusu olduğunda, diğerinde erişimi kaybeden veya kaybedilen politika. Örnek: 

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

Tedarikçi firma politikası aynı kalacak olsa da v_domain yeni sysfs_A ile ilgili politika eksikliği nedeniyle erişimi kaybedecek türü.

Özellikler açısından bir politika tanımlayarak, temel alınan nesneye türü, hem platform hem de politika ile ilgili politikaya karşılık gelen bir özelliğe sahip olmalıdır. tedarikçi kodudur. Bu tüm türler için, etkili bir şekilde attribute-policy. Pratikte, bu yalnızca politikanın platformla çakışan kısımları için gereklidir platform genel politikası olarak tanımlanan ve sağlanan tedarikçi firma bu, tedarikçi firma politikasının bir parçası olarak oluşturulur.

Genel politikanın sürümlü özellikler olarak tanımlanmasının iki politikaya uyması gerekir uyumluluk hedefleri:

  • Platform güncellemesinden sonra tedarikçi kodunun çalışmaya devam ettiğinden emin olun. Şuna karşılık gelen nesneler için somut türlere özellikler eklenerek elde edildi: erişimi koruyan tedarikçi firma kodunun güvendiği tedarikçiler için geçerlidir.
  • Politikayı kullanımdan kaldırma yetkisi. Açık bir şekilde elde edildi kullanıma sunulduğu anda kaldırılabilecek özelliklere göre karşılık geldiği sürüm artık desteklenmiyor. Geliştirme eski politikanın hala yürürlükte olduğunu bilerek hâlâ platformda ve yeni sürüme geçirildiğinde otomatik olarak kaldırılacaktır.

Politika yazılabilirliği

Google Analytics 4'teki belirli sürüm değişiklikleri hakkında bilgi sahibi olma politika geliştirmede, Android 8.0'da platform ile herkese açık politika türlerini ve özelliklerini ele aldık. foo türü eşlendi foo_vN özelliğine eklemek için (burada N değeri, sürüm hedeflendi. vN, PLATFORM_SEPOLICY_VERSION derleme değişkeni MM.NN; burada MM, platform SDK numarasına karşılık gelir NN ise platforma özel bir sürümdür.

Genel politikadaki özellikler için sürüm oluşturulmaz, ancak özellikler şurada bir API olarak bulunur: bu ikisi arasındaki arayüzü korumak için hangi platformun ve tedarikçi politikasının oluşturabileceği sabit bölümlendirir. Hem platform hem de tedarikçi politikası yazarları yazmaya devam edebilir olarak değiştirilmelidir.

allow source_foo target_bar:class perm; olarak dışa aktarılan platforma açık politika, tedarikçi firma politikasına dahildir. Etkinlik sırasında compilation (derleme) sürümüne) gider. Dönüştürülmesinden sonra da satıcı bölümü (dönüştürülen Ortak Ara Dil (CIL): 

 (allow source_foo_vN target_bar_vN (class (perm)))

Tedarikçi politikası hiçbir zaman platformun önünde olmadığından kontrol edebilirsiniz. Ancak platform politikasının, tedarikçi firmanın ne kadar eskiye politika özelliklerini ayarlamak, türleriyle ilgili özellikleri eklemek ve sürüm özellikleri

Politika farklılıkları

Sona _vN ekleyerek özellikler otomatik olarak oluşturuluyor sürümdeki türlerle özellikler eşleştirilmeden hiçbir şey yapmaz. farklar. Android, özellikler ve eşleme yöntemini kullanabilirsiniz. Bu, yukarıda bahsedilen eşlemede yapılır. (CIL) gibi ifadeler içeren dosyalar: 

(typeattributeset foo_vN (foo))

Platform yükseltmeleri

Platform yükseltmeleriyle ilgili senaryolar aşağıdaki bölümde ayrıntılı olarak açıklanmaktadır.

Aynı türler

Bu senaryo, bir nesne politika sürümlerindeki etiketleri değiştirmediğinde ortaya çıkar. Bu, kaynak ve hedef türleri için aynıdır ve Tüm konumlarda binder_device olarak etiketlenmiş /dev/binder yayınlar. Dönüştürülen politikada şu şekilde temsil edilir: 

binder_device_v1 … binder_device_vN

v1 → v2 sürümünden yükseltme yaparken platform politikası içerir: 

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 tedarikçi politikasında (CIL): 

(typeattribute binder_device_v1)
(allow binder_device_v1 …)

v2 tedarikçi 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. .

  • Yeni özellik. Tür, mevcut olmayan (örneğin, yeni bir hizmet işlemi) tedarikçi kodu karşılık gelen bir politika olmaması nedeniyle söz konusu ürünle doğrudan etkileşime giremezsiniz. Yeni türe karşılık gelen özellik önceki ve bu nedenle, sürümünü değil.
  • Politika sağlamlaştırma. Tür, politikayı temsil ettiğinde sağlamlaştırması durumunda, yeni type özelliği tekrar bir öznitelik zincirine bağlanmalıdır. (önceki örneğe benzer şekilde) /sys/A, sysfs - sysfs_A). Tedarikçi kodu, sysfs erişimi sağlayan bir kurala dayanır ve değerini ekleyin.

v1 → v2 sürümünden yükseltme yaparken platform politikası içerir: 

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 tedarikçi politikasında (CIL): 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute sysfs_A_v2)
(allow … sysfs_A_v2 …)
(typeattribute sysfs_v2)
(allow … sysfs_v2 …)
Kaldırılan türler

Bu (nadiren) senaryo, bir tür kaldırıldığında ortaya çıkar. temel nesne:

  • Kalır ancak farklı bir etiket alır.
  • Platform tarafından kaldırılır.

Politika gevşetme sırasında bir tür kaldırılır ve nesne bu türle etiketlenir farklı, zaten var olan bir etiket verilir. Bu, üst yönetimin özellik eşlemeleri: Tedarikçi firma kodu, temel alınan bilgilere erişmeye devam nesnesini tanımlarken, sistemin geri kalanının yeni özelliğiyle erişebilir.

Geçiş yapılan özellik yeniyse yeniden etiketleme yeni tür ile aynıdır ancak mevcut bir etiket kullanıldığında yeni türdeki eski özelliğin eklenmesi, diğer nesnelerin de etiketlenmesine neden olur. yeni erişilebilir olmasını sağlayın. Bu işlem temel olarak korunmasını sağlamak için makul bir zıtlık uyumluluk. 

(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

Örnek Sürüm 1: Daraltılabilen türler (sysfs_A kaldırılıyor)

v1 → v2 sürümünden yükseltme yaparken platform politikası içerir: 

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 tedarikçi politikasında (CIL): 

(typeattribute sysfs_A_v1)
(allow … sysfs_A_v1 …)
(typeattribute sysfs_v1)
(allow … sysfs_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute sysfs_v2)
(allow … sysfs_v2 …)

Örnek Sürüm 2: Tamamen kaldırma (foo türü)

v1 → v2 sürümünden yükseltme yaparken platform politikası içerir: 

# 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 tedarikçi politikasında (CIL): 

(typeattribute foo_v1)
(allow foo …)
(typeattribute sysfs_v1)
(allow sysfs_v1 …)

v2 tedarikçi politikasında (CIL): 

(typeattribute sysfs_v2)
(allow sysfs_v2 …)
Yeni sınıf/izinler

Bu senaryo, platform yükseltme işlemi yeni politika bileşenleri içerdiğinde gerçekleşir yeni sürümler oluşturun. Örneğin, Android Ekleme, bulma ve listeleme işlemlerini oluşturan servicemanager nesne yöneticisi kaydolmak isteyen tedarikçi arka plan programları, servicemanager, şu olmayan izinlere ihtiyaç duyuyordu: kullanılabilir. Android 8.0'da yalnızca platform politikası yeni sınıflar ekleyebilir ve izin verir.

Tedarikçi firma politikası tarafından oluşturulmuş veya genişletilmiş olabilecek tüm alan adlarına izin vermek için engel olmadan kullanmak için platform politikasında şuna benzer kural: 

allow {domain -coredomain} *:new_class perm;

Bu, tüm arayüzlere erişim izni veren bir politika bile gerektirebilir (genel politika) farklı türlerde filtreleme yapabilir. Bu durum, kabul edilemez (hizmet yöneticisi değişiklikleriyle birlikte olabileceğinden) zorlanabilir.

Sınıf/izinler kaldırıldı

Bu senaryo, bir nesne yöneticisi kaldırıldığında (örneğin, ZygoteConnection nesne yöneticisi) oluşturur ve sorunlara neden olmaz. İlgili içeriği oluşturmak için kullanılan nesne yöneticisi sınıfı ve izinleri, satıcı sürümü artık bunu kullanmıyor. Bu, söz konusu terim için açıklama dosyasıyla ilişkilendirin.

Şunun için tedarikçi özelleştirmesi: yeni/yeniden etiketlenmiş türler

Yeni tedarikçi türleri, ihtiyaca göre tedarikçi politikası geliştirme sürecinin merkezinde yer almaktadır yeni süreçleri, ikili programları, cihazları, alt sistemleri ve depolanan verileri tanımlamaktadır. Farklı bu nedenle tedarikçi tarafından tanımlanan türlerin oluşturulmasına izin vermek zorunludur.

Tedarikçi firma politikası her zaman cihazdaki en eski politika olduğundan tüm tedarikçi firma türlerini politikadaki özelliklere otomatik olarak dönüştürür. Platform ilgili platforma sahip olmadığı için tedarikçi politikasında etiketlenen hiçbir şeye dayanmaz. bilgi sahibi olması gerekir. ancak platform, gerekli özellikleri ve herkese açık bu türlerle etiketlenmiş nesnelerle (ör. domain, sysfs_type vb.). Platformun şunları sağlaması için: özellikleri ve türleri ile doğru şekilde etkileşime girmesini adımlarının uygun şekilde uygulanması ve belirli kuralların özelleştirilebilir alanlar (init gibi) kullanabilirsiniz.

Android 9 için özellik değişiklikleri

Android 9'a geçen cihazlarda aşağıdaki özellikler kullanılabilir ancak Android 9 ile lansman bunu yapmamalıdır.

İhlal eden özellikler

Android 9'da alanla ilgili şu özellikler bulunur:

  • data_between_core_and_vendor_violators. Şu tarihe kadar dosya paylaşmama koşulunu ihlal eden tüm alanların özelliği: vendor ile coredomains arasındaki yol. Platform ve tedarikçi işlemleri iletişim için disk üzerindeki dosyaları kullanmamalıdır (kararsız ABI). Öneri:
    • Tedarikçi firma kodu /data/vendor kullanmalıdır.
    • Sistemde /data/vendor kullanılmamalıdır.
  • system_executes_vendor_violators. Öznitelik tüm sistem alanları için (init ve shell domains hariç) gerekliliklerini ihlal eden bir hizmetten oluşur. Yürütme işlemi tedarikçi firma ikili programları kararsız API'ye sahip. Platform, tedarikçi ikili programlarını yürütmemelidir doğrudan ekleyebilirsiniz. Öneri:
    • Tedarikçi ikili programlarına bu tür platform bağımlılıkları, HIDL HAL'lerin arkasında olmalıdır.

      VEYA

    • Tedarikçi ikili programlarına erişmesi gereken coredomains satıcı bölümüne taşındığından coredomain olarak ayarlandı.

Güvenilmeyen özellikler

Rastgele kod barındıran güvenilmeyen uygulamalar HwBinder'a erişemez. hizmetleri (bu tür uygulamalardan erişim için yeterince güvenli kabul edilenler hariç) (aşağıdaki güvenli hizmetlere bakın). Bunun başlıca iki nedeni şunlardır:

  1. HIDL şu anda HIDL olduğundan HwBinder sunucuları istemci kimlik doğrulaması yapmaz: arayan UID bilgilerini açığa çıkarmaz. HIDL bu tür verileri açığa çıkarmış olsa bile çoğu HwBinder hizmetleri, uygulamaların düzeyinden daha düşük bir düzeyde (HAL gibi) çalışır veya . Bu nedenle, herhangi bir sorun yaşamamak için her HwBinder hizmetinin, tüm müşterilerine eşit davrandığı ve hizmet tarafından sunulan işlemleri gerçekleştirmek için yetkilendirilmiş olmalıdır.
  2. HAL sunucuları (HwBinder hizmetlerinin bir alt kümesi) daha yüksek system/core bileşene göre güvenlik sorunlarının görülme oranı yığının alt katmanlarına (donanıma kadar) erişebilirler. Böylece, Android güvenlik modelini atlama fırsatları da artıyor.

Güvenli hizmetler

Güvenli hizmetler şunlardır:

  • same_process_hwservice Bu hizmetler (tanımı gereği) sahip olması ve böylece web sitesindeki istemci alan adıyla aynı bu aşamaya geçelim.
  • coredomain_hwservice Bu hizmetler risk teşkil etmez 2. nedenle ilişkilidir.
  • hal_configstore_ISurfaceFlingerConfigs Bu hizmet tüm alan adlarında kullanılmak üzere özel olarak tasarlanmıştır.
  • hal_graphics_allocator_hwservice Bu işlemler aynı zamanda surfaceflinger Bağlayıcı hizmeti tarafından sunulmaktadır (uygulamalara izin verilir) tıklayın.
  • hal_omx_hwservice Bu, mediacodec Uygulamaların erişmesine izin verilen Bağlayıcı hizmeti.
  • hal_codec2_hwservice Bu hal_omx_hwservice.

Kullanılabilir özellikler

Güvenli olarak kabul edilmeyen tüm hwservices öğeleri şu özelliğe sahip: untrusted_app_visible_hwservice. İlgili HAL sunucularında untrusted_app_visible_halserver özelliği. Başlatılan cihazlar Android 9 kullanan kişiler aşağıdakilerden birini KULLANMAMALIDIR untrusted özelliği için de kullanılmaktadır.

Öneri:

  • Güvenilmeyen uygulamalar, HIDL HAL. Örneğin, uygulamalar binderservicedomain ile, ardından mediaserver ile konuşabilir (bir binderservicedomain) ise hal_graphics_allocator ile konuşur.

    VEYA

  • vendor HAL'ye doğrudan erişmesi gereken uygulamaların kendi tedarikçi firma tarafından tanımlanan sepolicy alan adına sahip olmak

Dosya özelliği testleri

Android 9, belirli dosyalardaki tüm dosyaların sağlandığından emin olan derleme süresi testleri içerir konumun uygun özelliklere sahip olması (örneğin, sysfs, zorunlu sysfs_type özelliğine sahip).

Platform herkese açık politikası

Android 8.0'a uygunluğun temeli, platforma açık politikadır. platform politikaları birleşimini sürdürmeden mimari modeli v1 ve v2'den başlar. Tedarikçi firmalara uygulanan platform politikasının bir alt kümesi Bu türler ve özelliklerde kullanılabilir türler, özellikler ve kurallar içerir Bu, satıcı politikasının bir parçası haline gelir (ör. vendor_sepolicy.cil) bilgileri gösterilir.

Tedarikçi firma tarafından oluşturulan politikada türler ve kurallar otomatik olarak çevrilir Böylece, platform tarafından sağlanan tüm türleri attribute_vN sürümlü özelliklerdir (ancak özellikler sürümlü değildir). Platform sağladığı somut türlerin uygun ekonomiye haritalanmasından özelliklerini kullanarak tedarikçi politikasının çalışmaya devam etmesini ve kuralların, belirtilen tüm özellikler dahil edilmiş olmalıdır. Şunların kombinasyonu platform genel politikası ve satıcı politikası, Android 8.0 mimarisine uygundur bağımsız platform ve tedarikçi derlemelerine izin verme şeklinde bir model hedefimiz var.

Özellik zincirleriyle eşleme

Politika sürümleriyle eşlemek için özellikleri kullanırken tür, bir özellik veya türle etiketlenmiş nesnelere erişilebilmesini sağlayarak özellikleri gösterilir.

Sürüm bilgilerini politika yazarından gizleme hedefi, sürümlü özellikleri otomatik olarak oluşturmak ve bunları, uygun türlerde kullanılabilir. Statik türlerde yaygın olarak kullanılan bir yöntemde bu oldukça basittir: type_foo, type_foo_v1 ile eşleşiyor.

sysfs → sysfs_A veya mediaserver → audioserver, bu eşlemeyi oluşturma sıradan değildir (ve yukarıdaki örneklerde açıklanmıştır). Platform politikası bakıcıları nesneler için geçiş noktalarında eşlemenin nasıl oluşturulacağını belirlemesi gerekir: nesneler ve bu nesneler arasındaki ilişkiyi anlamayı gerektirir. ve bunun ne zaman gerçekleşeceğini belirlemek için gereklidir. Geriye dönük uyumluluk açısından karmaşıklığın platform tarafında yönetilmesi gerekir. Bu, platformun bu da yükselebilir.

Sürüm yükseltmeleri

Yeni bir güncelleme olduğunda Android platformu, kolaylık sağlamak amacıyla bir sepolicy sürümü yayınlar. kesme dalı kesildi. Yukarıda açıklandığı gibi, sürüm numarası PLATFORM_SEPOLICY_VERSION ve MM.nn biçiminde, Burada MM, SDK değerine, nn ise bir özel değer /platform/system/sepolicy. için korunuyor örnek, Kitkat için 19.0, Lollipop için 21.0, Marshmallow için Lollipop-MR1 23.0 için 22.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. Artışlar her zaman tam sayı değildir. Örneğin, bir sürüme tampon ya da MR reklamların bir versiyona yansıması system/sepolicy/public fakat API patlaması yoksa sürüm şu olabilir: vN.1. Geliştirme aşamasındaki sürüm şubesi, gönderim cihazlarında hiçbir zaman kullanılmayan 10000.0 kategorisi.

Android, sürümü yükseltirken en eski sürümü kullanımdan kaldırabilir. Ne zaman yapılacağıyla ilgili giriş için bir sürümü kullanımdan kaldırmadan önce Android, farklı bir sürümün yüklü olduğu Android sürümünü çalıştıran ve ana platformu almaya devam eden politikalar güncellemelerine göz atın. Sayı belirli bir eşikten azsa o sürüm desteği sonlandırıldı.

Performansa etkisi birden çok özellik

https://github.com/SELinuxProject/cil/issues/9 adresinde açıklandığı gibi, bir türe çok sayıda özellik atanması, şu süreçlerde performans sorunlarına neden olur: tespit edememesi söz konusu olabilir.

Bunun Android'de bir sorun olduğu onaylandı. Bu nedenle değişiklikler tarafından politikaya eklenen özelliklerin kaldırılması için Android 8.0'da politika derleyicinin yanı sıra kullanılmayan özellikleri kaldırmak için de kullanılır. Bu değişiklikler çözümlendi performans regresyonları gibidir.

Sistem uzantısı herkese açık ve ürün genel politikası

Android 11'den itibaren system_ext ve ürün bölümlerinin atanan herkese açık türleri tedarikçi firma bölümüne aktarabilir. Platform gibi tedarikçi firma, herkese açık bir politikaya göre otomatik olarak sürüm özellikleri, ör. type dilinden şu dile: type_N, burada N olan sürümdür temel alınan tedarikçi firma bölümü.

system_ext ve ürün bölümleri aynı platform sürümüne dayalı olduğunda N, derleme sistemi temel eşleme dosyalarını system_ext/etc/selinux/mapping/N.cil ve Kimlik içeren product/etc/selinux/mapping/N.cil type ile type_N arasında eşlemeler var. Tedarikçi, type sürümüne erişmek için sürümlü type_N özelliğini kullanma.

Yalnızca system_ext ve ürün bölümlerinin güncellenmesi durumunda, N - N+1 (veya üzeri) arasında, N adresinde kalırsa tedarikçi system_ext ve ürün bölümlerinin türlerini paylaştık. Bozukluğu önlemek için system_ext ve ürün bölümleri, betondan eşleme dosyaları sağlamalıdır type_N özelliklerine ayrılır. Her iş ortağı, eşleme dosyalarını desteklemekten ve N+1 (veya daha yeni) ile N tedarikçi firma system_ext ile ürün bölümlerini de içermelidir.

Bu amaçla iş ortaklarının şunları yapması beklenir:

  1. N öğesinden oluşturulan temel eşleme dosyalarını kopyalayın system_ext ve ürün bölümleri .
  2. Eşleme dosyalarında gereken değişiklikleri yapın.
  3. "dosyaları N+1 (veya daha yeni) system_ext ile eşleme ve ürün bölümleri için de geçerli.

Örneğin, N system_ext öğesinde bir herkese açık öğe bulunduğunu varsayalım foo_type adlı tür. system_ext/etc/selinux/mapping/N.cil sonra N system_ext bölümü aşağıdaki gibi görünür: 

(typeattributeset foo_type_N (foo_type))
(expandtypeattribute foo_type_N true)
(typeattribute foo_type_N)

bar_type, N+1 system_ext'e eklenirse ve bar_type, şunun için foo_type ile eşlenmelidir: N tedarikçi firma, N.cil şuradan güncellenebilir: 

(typeattributeset foo_type_N (foo_type))

- 

(typeattributeset foo_type_N (foo_type bar_type))

ve ardından N+1 system_ext bölümüne yüklendi. N tedarikçi firma, N+1 hizmetine erişmeye devam edebilir system_ext foo_type ve bar_type.

SELinux bağlamlarını etiketleme

Platform ve tedarikçi firma politikası arasındaki farkı 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 kullanıma sundu:

  • Başlatma sırasında cihaz üzerinde ek derleme yükünden kaçınmak için file_contexts artık ikili biçimde yok. Bunun yerine {property, service}_contexts gibi okunabilir, normal ifade metin dosyalarından oluşmalıdır (7.0'dan önceki haliyle).
  • file_contexts iki dosya arasında bölünür:
    • plat_file_contexts
      • Hiçbir özelliğe sahip olmayan Android platformu file_context cihaz özel etiketleri hariç, Şu şekilde etiketlenmesi gereken /vendor bölümü: sepolicy dosyalarının düzgün çalışmasını sağlamak.
      • Şu konumdaki system bölümünde yer almalıdır: Cihazda /system/etc/selinux/plat_file_contexts ve başlangıçta init tarafından ve tedarikçi firma file_context.
    • vendor_file_contexts
      • Cihaza özel file_context modeli birleştirme işlemiyle oluşturulur tarafından işaret edilen dizinlerde file_contexts bulundu Cihazın: BOARD_SEPOLICY_DIRS Boardconfig.mk dosya.
      • Şu konuma yüklenmelidir: /vendor/etc/selinux/vendor_file_contexts inç vendor bölümlendirme ve init tarafından şu saatte yüklenecektir: file_context platformuyla başlayalım.

Tesis bağlamları

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

  • plat_property_contexts
    • Hiçbir özelliğe sahip olmayan Android platformu property_context izin verir.
    • Şu konumdaki system bölümünde yer almalıdır: /system/etc/selinux/plat_property_contexts ve yüklenecek önce, tedarikçi firmayla birlikte init tarafından property_contexts.
  • vendor_property_contexts
    • Cihaza özel property_context modeli birleştirme işlemiyle oluşturulur tarafından işaret edilen dizinlerde property_contexts bulundu Cihazdaki BOARD_SEPOLICY_DIRS Boardconfig.mk dosya.
    • Şu konumdaki vendor bölümünde yer almalıdır: /vendor/etc/selinux/vendor_property_contexts ve başlangıçta init tarafından platformla birlikte yüklenir property_context

Hizmet bağlamları

Android 8.0'da service_contexts, şu cihazlar arasında bölünür: dosyalar:

  • plat_service_contexts
    • Android platformuna özel service_context servicemanager. service_context, sahip olduğu izin verir.
    • Şu konumdaki system bölümünde yer almalıdır: /system/etc/selinux/plat_service_contexts ve şu kadar yükleyecek: tedarikçiyle birlikte başlangıçta servicemanager service_contexts.
  • vendor_service_contexts
    • Cihaza özel service_context modeli birleştirme işlemiyle oluşturulur tarafından işaret edilen dizinlerde service_contexts bulundu Cihazın: BOARD_SEPOLICY_DIRS Boardconfig.mk dosya.
    • Şu konumdaki vendor bölümünde yer almalıdır: /vendor/etc/selinux/vendor_service_contexts ve yüklenecek başlangıçta servicemanager tarafından platformla birlikte service_contexts.
    • servicemanager, başlatma sırasında bu dosyayı arasa da tamamen uyumlu TREBLE cihaz için vendor_service_contexts OLMAMALIDIR. Çünkü vendor ile system arasındaki tüm etkileşimler GEÇMELİDİR hwservicemanager/hwbinder.
  • plat_hwservice_contexts
    • Android platformu hwservice_context Cihaza özel etiketi olmayan hwservicemanager.
    • Şu konumdaki system bölümünde yer almalıdır: /system/etc/selinux/plat_hwservice_contexts ve şu kadar yükleyecek: başında hwservicemanager ve vendor_hwservice_contexts.
  • vendor_hwservice_contexts
    • Cihaza özel hwservice_context modeli birleştirme işlemiyle oluşturulur tarafından işaret edilen dizinlerde hwservice_contexts bulundu Cihazın: BOARD_SEPOLICY_DIRS Boardconfig.mk dosya.
    • Şu konumdaki vendor bölümünde yer almalıdır: /vendor/etc/selinux/vendor_hwservice_contexts ve başlangıçta hwservicemanager tarafından ve plat_service_contexts.
  • vndservice_contexts
    • Cihaza özel service_context vndservicemanager, birleştirilerek oluşturuldu tarafından işaret edilen dizinlerde vndservice_contexts bulundu Cihazın: BOARD_SEPOLICY_DIRS Boardconfig.mk.
    • Bu dosya aşağıdaki konumda vendor bölümünde bulunmalıdır: /vendor/etc/selinux/vndservice_contexts ve şu kadar yükleyecek: başlangıçta vndservicemanager.

Seapp bağlamları

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

  • plat_seapp_contexts
    • Cihaza özgü bir özelliği olmayan Android platformu seapp_context anlamına gelir.
    • Şu konumdaki system bölümünde yer almalıdır: /system/etc/selinux/plat_seapp_contexts.
  • vendor_seapp_contexts
    • seapp_context platformu için cihaza özel uzantı oluşturuldu dizinlerde bulunan seapp_contexts birleştirilerek üzerinde BOARD_SEPOLICY_DIRS tarafından işaretlenen Boardconfig.mk dosya.
    • Şu konumdaki vendor bölümünde yer almalıdır: /vendor/etc/selinux/vendor_seapp_contexts.

MAC izinleri

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

  • mac_permissions.xml. platform
    • Hiçbir özelliğe sahip olmayan Android platformu mac_permissions.xml cihaza özgü değişiklikler olabilir.
    • Şu konumdaki system bölümünde yer almalıdır: /system/etc/selinux/.
  • Platform dışı mac_permissions.xml
    • Platform için cihaza özel uzantı mac_permissions.xml başlangıç noktası tarafından işaret edilen dizinlerde mac_permissions.xml bulundu Cihazın: BOARD_SEPOLICY_DIRS Boardconfig.mk dosya.
    • Şu konumdaki vendor bölümünde yer almalıdır: /vendor/etc/selinux/.