avc-deniedの設定SELinuxポリシーの解決

[Description]
Android KK 4.4以降、GoogleはデフォルトでSELinuxを有効にし、kernel logまたはandroid log(Lバージョン)にSELinuxレビュー異常を印刷します.対応するキーワードは「avc:denied」または「avc:denied」のような行LOGです.

<5>[ 17.285600].(0)[503:idmap]type=1400 audit 
(1356999072.320:202): avc:  denied  { create } for  pid=503  
comm="idmap" name="overlays.list" scontext=u:r:zygote:s0  
tcontext=u:object_r:resource_cache_data_file:s0 tclass=file 

すなわちidmapというprocessを示し、zygoteのsource contextを使用して/data/resource_にアクセスするCacheディレクトリ、ファイル作成時にSELinuxによってアクセスが拒否されました.
[Keyword]
android, SELinux, avc: denied, audit
[Solution]
KKバージョンでは、Googleは、netd、installd、zygote、vold、およびそれらが直接forkから出たchild processに対してenforcing modeを使用することを制限するのみであるが、zygote forkの一般的なappは含まれない.Lバージョンでは、GoogleがSELinuxを全面的にオープンし、ほとんどのprocessがenforcing modeに影響を与え、影響面が非常に広い.
現在、すべてのSELinux checkが失敗しており、kernel logまたはandroid log(Lバージョン以降)に対応する「avc:denied」または「avc:denied」のLOGが対応している.逆に、このLOGがあれば、直接失敗するわけではないが、当時のSELinuxのパターンがenforcing modeなのかpermissve modeなのかを確認する必要がある.まず、対応するプロセスがシステムリソースにアクセスしているかどうかを確認し、必要かどうかを確認します.それ自体が異常な不正アクセスであれば、自分でアクセスを消去します.次に、アクセスが必要で正常であることを確認すると、対応するprocess/domainに新しいpolicyを追加する.
1). 簡略化された方法
1.1すべてのavc LOGを抽出する.例えばadb shell「cat/proc/kmsg|grep avc」>avc_log.txt 1.2 audit 2 allow toolを用いてpolicyを直接生成する.audit2allow -i avc_log.txtで生成されたpolicy 1.3を自動的に出力し、対応するpolicyをselinux policyルールに追加します.MTK Solutionに対応して、KK:mediatek/custom/common/sepolicy、L:device/mediatek/common/sepolicyの下に追加できます.

  allow zygote resource_cache_data_file:dir rw_dir_perms;
  allow zygote resource_cache_data_file:file create_file_perms;
  ===> mediatek/custom/common/sepolicy/zygote.te (KK)
  ===> device/mediatek/common/sepolicy/zygote.te (L)

注意audit 2 allow自動機械的にLOGをpolicyに変換するのに役立ち、あなたの操作の本当の意図を知ることができず、権限拡大の問題が発生する可能性があり、policyがコンパイルできないことがよくあります.
2). オンデマンド確認方法
この方法は工程員がSELinuxの基本原理及びSELinux Policy Languageについて理解する必要がある.2.1どのプロセスがどのリソースにアクセスするか、具体的にどのアクセス権限が必要かを確認します.read?write ? exec ? create ? search ? 2.2現在のプロセスでpolicyファイルが作成されていますか?通常はプロセスの実行ファイルである.te,親プロセスであるsource contextが対応するリソースにアクセスする必要がない場合,新しいteファイルを作成する.Lバージョンでは、Googleはzygote、netd、installd、vold、ueventdなどのキープロセスを他のプロセスと共有することを厳禁するなど、キーsecurity contextの一意性を維持することを要求している.2.3ファイルを作成した後、その実行ファイルをfile_に関連付けるcontextsでは、関連する実行ファイルを関連付ける.たとえば/system/bin/idmapは/system/bin/idmap u:object_r:idmap_exec:s 0 2.4関連するteファイルにpolicyを記入元の親プロセスのteファイルをそのまま使用すると、直接追加する.新しいファイルの場合は、まず次のようにします.

  #==============================================
  # Type Declaration
  #==============================================
  type idmap, domain;
  type idmap_exec, exec_type, file_type;

  #==============================================
  # Android Policy Rule
  #==============================================
  #permissive idmap;
  domain_auto_trans(zygote, idmap_exec, idmap);

次に新しいpolicyを追加します

  # new policy
  allow idmap resource_cache_data_file:dir rw_dir_perms;
  allow idmap resource_cache_data_file:file create_file_perms;

3). 権限拡大処理
avc:deniedのLOGに直接従ってSELinux Policyを変換すると、権限拡大の問題が生じることが多い.たとえば、あるデバイスにアクセスするため、このデバイスがSELinux Labelを細分化していない場合、次のようになります.

  <7>[11281.586780] avc:  denied { read write } for pid=1217 
comm="mediaserver" name="tfa9897" dev="tmpfs" ino=4385 
scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0 
tclass=chr_file permissive=0

このLOGに従ってSELinux Policy:allow mediaserver device:chr_を直接変換するとfile {read write}; メディアサーバがすべてのデバイスを読み書きする権限を解放します.Googleはこのような状況を防ぐためにneverallow文を使用して制約し、sepolicyをコンパイルするときにコンパイルできません.このような権限拡大を回避するためには,アクセス先(Object)のSELinux Labelを細分化し,オンデマンドで申請する必要がある.通常、3.1定義に関するSELinux typeは3ステップで構成する.例えば、上記の例では、device/mediatek/common/sepolicy/device.te追加

   type tfa9897_device, dev_type;

3.2ファイルとSELinux typeをバインドする.例えば、上記の例では、device/mediatek/common/sepolicy/file_contexts追加/dev/tfa9897(/.*)? u:object_r:tfa9897_device:s0
3.3プロセス/domainに対するアクセス権限を追加する.例えば、上記の例では、device/mediatek/common/sepolicy/mediaserver.te追加allow mediaserver tfa9897_device:chr_file { open read write };
では、このようなアクセスオブジェクトは通常どのようなものに遭遇しますか?(Lバージョンを例に)*device–タイプ定義:external/sepolicy/device.te;device/mediatek/common/sepolicy/device.te–タイプバインド:external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts

Fileタイプ:–タイプ定義:external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te–バインドタイプ:external/sepolicy/file_contexts;device/mediatek/common/sepolicy/file_contexts

仮想Fileタイプ:–タイプ定義:external/sepolicy/file.te;device/mediatek/common/sepolicy/file.te–バインドタイプ:external/sepolicy/genfs_contexts;device/mediatek/common/sepolicy/genfs_contexts

Serviceタイプ:–タイプ定義:external/sepolicy/service.te; device/mediatek/common/sepolicy/service.te–バインドタイプ:external/sepolicyservice_contexts;device/mediatek/common/sepolicy/service_contexts

Propertyタイプ:–タイプ定義:external/sepolicy/property.te;device/mediatek/common/sepolicy/property.te–バインドタイプ:external/sepolicy/property_contexts;device/mediatek/common/sepolicy/property_contexts; Google defaultのpolicyを更新することに強く反対しています.mediatekの下のpolicyを更新することができます.

記事内容はMTKオンラインから入手し、再編集しました.