Android Açık Kaynak Projesi (AOSP), tüm Android cihazlarda ortak olan uygulamalar ve hizmetler için sağlam bir temel politika sağlar. AOSP'ye katkıda bulunanlar bu politikayı düzenli olarak geliştirmektedir. Çekirdek politikanın nihai cihaz politikasının yaklaşık %90-95'ini oluşturması ve cihaza özel özelleştirmelerin kalan %5-10'unu oluşturması bekleniyor. Bu makale, cihaza özel bu özelleştirmelere, cihaza özel politikanın nasıl yazılacağına ve bu süreçte kaçınılması gereken bazı tuzaklara odaklanmaktadır.
Cihaz açma
Cihaza özel politika yazarken şu adımları izleyin.
İzinli modda çalıştır
Bir cihaz izinli moddayken , reddetmeler günlüğe kaydedilir ancak zorunlu tutulmaz. İzinli mod iki nedenden dolayı önemlidir:
- İzinli mod, ilke getirmenin diğer erken cihaz açma görevlerini geciktirmemesini sağlar.
- Zorla yapılan bir inkar, diğer inkarları maskeleyebilir. Örneğin, dosya erişimi genellikle bir dizin araması, dosya açma ve ardından dosya okuma işlemlerini içerir. Zorlama modunda, yalnızca dizin arama reddi gerçekleşir. İzinli mod, tüm reddetmelerin görülmesini sağlar.
Bir aygıtı izinli moda sokmanın en basit yolu çekirdek komut satırını kullanmaktır. Bu, cihazın BoardConfig.mk dosyasına eklenebilir: platform/device/<vendor>/<target>/BoardConfig.mk . Komut satırını değiştirdikten sonra, make clean gerçekleştirin, ardından make bootimage ve yeni önyükleme görüntüsünü flaşlayın.
Bundan sonra, izin verilen modu şu şekilde onaylayın:
adb shell getenforce
İki hafta, küresel izinli modda olmak için makul bir süre. Reddetmelerin çoğunu ele aldıktan sonra, zorlama moduna geri dönün ve hatalar ortaya çıktıkça bunları giderin. Hâlâ reddetme üreten veya hala yoğun geliştirme aşamasında olan hizmetler geçici olarak izin verilen moda alınabilir, ancak bunları mümkün olan en kısa sürede zorlama moduna geri getirin.
Erken uygula
Zorlama modunda, reddetmeler hem günlüğe kaydedilir hem de uygulanır. Cihazınızı mümkün olduğunca erken zorlama moduna almak en iyi uygulamadır. Cihaza özel politika oluşturmayı ve uygulamayı beklemek, genellikle hatalı bir ürüne ve kötü bir kullanıcı deneyimine neden olur. Test sürümüne katılmak için yeterince erken başlayın ve gerçek dünya kullanımında işlevselliğin tam test kapsamını sağlayın. Erken başlamak, güvenlik endişelerinin tasarım kararlarını bilgilendirmesini sağlar. Tersine, yalnızca gözlemlenen reddetmelere dayalı izinler vermek güvenli olmayan bir yaklaşımdır. Bu süreyi, aygıtın güvenlik denetimini gerçekleştirmek ve izin verilmemesi gereken davranışlara karşı hataları dosyalamak için kullanın.
Mevcut politikayı kaldırın veya silin
Yeni bir cihazda sıfırdan cihaza özel politika oluşturmak için birkaç iyi neden vardır ve bunlar arasında şunlar bulunur:
- Güvenlik denetimi
- Aşırı izin veren politika
- Politika boyutu küçültme
- Ölü politika
Temel hizmetlerin reddini ele alın
Temel hizmetler tarafından oluşturulan retler, genellikle dosya etiketleme ile giderilir. Örneğin:
avc: denied { open } for pid=1003 comm=”mediaserver” path="/dev/kgsl-3d0”
dev="tmpfs" scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0
tclass=chr_file permissive=1
avc: denied { read write } for pid=1003 name="kgsl-3d0" dev="tmpfs"
scontext=u:r:mediaserver:s0
tcontext=u:object_r:device:s0 tclass=chr_file permissive=1
/dev/kgsl-3d0 düzgün şekilde etiketlenerek tamamen ele alınır. Bu örnekte, tcontext , device . Bu, daha spesifik bir etiket atanmadıkça /dev içindeki her şeyin “ cihaz ” etiketini aldığı varsayılan bir bağlamı temsil eder. Burada Audit2allow'un çıktısını basitçe kabul etmek, yanlış ve aşırı müsamahakar bir kurala neden olur.
Bu tür bir sorunu çözmek için dosyaya bu durumda gpu_device olan daha spesifik bir etiket verin. Mediaserver, gpu_device'a erişmek için çekirdek politikada zaten gerekli izinlere sahip olduğundan başka izne gerek yoktur.
Çekirdek politikada önceden tanımlanmış türlerle etiketlenmesi gereken diğer cihaza özel dosyalar:
- cihazları engelle
- ses cihazları
- video cihazları
- sensörler
- nfc
- gps_device
- /sys içindeki dosyalar
- /proc içindeki dosyalar
Genel olarak, varsayılan etiketlere izin vermek yanlıştır. Bu izinlerin çoğuna Neverallow kuralları tarafından izin verilmez, ancak açıkça izin verilmediğinde bile en iyi uygulama, belirli bir etiket sağlamaktır.
Yeni hizmetleri etiketleyin ve reddetmeleri ele alın
Başlatılan hizmetlerin kendi SELinux etki alanlarında çalışması gerekir. Aşağıdaki örnek, hizmeti "foo"yu kendi SELinux etki alanına yerleştirir ve ona izinler verir.
Hizmet, cihazımızın init. device .rc dosyası olarak:
service foo /system/bin/foo
class core
- Yeni bir "foo" etki alanı oluşturun
Aşağıdaki içeriklerle
device/ manufacturer / device-name /sepolicy/foo.tedosyasını oluşturun:# foo service type foo, domain; type foo_exec, exec_type, file_type; init_daemon_domain(foo)
Bu, yürütülebilir dosya tarafından gerçekleştirilen belirli işlemlere dayalı olarak kurallar ekleyebileceğiniz foo SELinux etki alanı için ilk şablondur.
- Etiket
/system/bin/fooAşağıdakileri
device/ manufacturer / device-name /sepolicy/file_contexts:/system/bin/foo u:object_r:foo_exec:s0
Bu, yürütülebilir dosyanın doğru şekilde etiketlenmesini sağlar, böylece SELinux hizmeti uygun etki alanında çalıştırır.
- Önyükleme ve sistem görüntülerini oluşturun ve flashlayın.
- Etki alanı için SELinux kurallarını hassaslaştırın.
Gerekli izinleri belirlemek için reddetmeleri kullanın. Audit2allow aracı iyi yönergeler sağlar, ancak bunu yalnızca politika yazımını bilgilendirmek için kullanır. Sadece çıktıyı kopyalamayın.
Zorlama moduna geri dön
İzinli modda sorun gidermede sorun yok, ancak mümkün olduğunca erken zorlama moduna geri dönün ve orada kalmaya çalışın.
Yaygın hatalar
Cihaza özel politikalar yazarken meydana gelen yaygın hatalara yönelik birkaç çözümü burada bulabilirsiniz.
Olumsuzlamanın aşırı kullanımı
Aşağıdaki örnek kural, ön kapıyı kilitleyip pencereleri açık bırakmak gibidir:
allow { domain -untrusted_app } scary_debug_device:chr_file rw_file_permsAmaç açıktır: Üçüncü taraf uygulamalar dışındaki herkesin hata ayıklama cihazına erişimi olabilir.
Kural birkaç yönden kusurlu. Tüm uygulamalar isteğe bağlı olarak isolated_app etki alanında hizmetleri çalıştırabileceğinden, untrusted_app hariç tutulması önemsizdir. Benzer şekilde, AOSP'ye üçüncü taraf uygulamalar için yeni alan adları eklenirse, bu kişilerin de scary_debug_device erişimi olacaktır. Kural aşırı müsamahakar. Çoğu alan, bu hata ayıklama aracına erişimden yararlanamaz. Kural, yalnızca erişim gerektiren etki alanlarına izin verecek şekilde yazılmış olmalıdır.
Üretimde hata ayıklama özellikleri
Hata ayıklama özellikleri, üretim yapılarında veya politikalarında bulunmamalıdır.
En basit alternatif, hata ayıklama özelliğine yalnızca adb root ve adb shell setenforce 0 gibi eng/userdebug yapılarında SELinux devre dışı bırakıldığında izin vermektir.
Başka bir güvenli alternatif, hata ayıklama izinlerini bir userdebug_or_eng ifadesine dahil etmektir.
İlke boyutu patlaması
SEAndroid Politikalarını Vahşi Doğada Karakterize etmek , cihaz politikası özelleştirmelerinin büyümesinde ilgili bir eğilimi açıklar. Cihaza özel politika, bir cihazda çalışan genel politikanın %5-10'unu oluşturmalıdır. %20+ aralığındaki özelleştirmeler, neredeyse kesinlikle aşırı ayrıcalıklı alanlar ve ölü politika içerir.
Gereksiz yere büyük politika:
- İlke ramdisk'te oturduğundan ve ayrıca çekirdek belleğe yüklendiğinden belleğe çift vuruş yapar.
- Daha büyük bir önyükleme görüntüsü gerektirerek disk alanını boşa harcar.
- Çalışma zamanı ilkesi arama sürelerini etkiler.
Aşağıdaki örnek, üreticiye özel politikanın, cihaz üzerindeki politikanın %50'sini ve %40'ını oluşturduğu iki cihazı göstermektedir. İlkenin yeniden yazılması, aşağıda gösterildiği gibi işlevsellikte herhangi bir kayıp olmaksızın önemli güvenlik iyileştirmeleri sağladı. (Karşılaştırma için AOSP cihazları Shamu ve Flounder dahildir.)
Şekil 1 . Güvenlik denetiminden sonra cihaza özel ilke boyutunun karşılaştırılması.
Her iki durumda da, politika hem boyut hem de izin sayısı açısından önemli ölçüde azaltıldı. Politika boyutundaki azalma, neredeyse tamamen, çoğu muhtemelen audit2allow tarafından oluşturulan ve politikaya gelişigüzel eklenen kurallar olan gereksiz izinlerin kaldırılmasından kaynaklanmaktadır. Ölü alanlar da her iki cihaz için de bir sorundu.
dac_override yeteneğinin verilmesi
dac_override reddi, soruna neden olan işlemin yanlış unix kullanıcı/grup/dünya izinlerine sahip bir dosyaya erişmeye çalıştığı anlamına gelir. Uygun çözüm, neredeyse hiçbir zaman dac_override iznini vermemektir. Bunun yerine dosya veya işlemdeki unix izinlerini değiştirin . init , vold ve installd gibi birkaç etki alanı, diğer işlemlerin dosyalarına erişmek için gerçekten unix dosya izinlerini geçersiz kılma yeteneğine ihtiyaç duyar. Daha ayrıntılı bir açıklama için Dan Walsh'ın bloguna bakın.