☰

Androidでdac_overrideの原因を特定する方法は？

tag-icon • tag-icon android selinux
Androidでdac_overrideの原因を特定する方法は？

私はいくつかのAndroidのカスタマイズ作業をしていますが、私が作成している限り、アプリケーションdac_overrideでdmesgの結果が次のように表示されます。

type=1400 audit(499405.329:16): avc: denied { dac_override } for 
pid=1103 comm="my_tool" capability=1 scontext=u:r:my_tool:s0
tcontext=u:r:my_tool:s0 tclass=capability permissive=1

私は問題を引き起こす実行可能ファイル（my_tool）を知っています。これは、dac_override実行可能ファイルに操作を実行するための既存のLinux権限がないことを意味しますが、どの操作が試行され、どのファイルが試行されたのかわかりません。どのように答えを見つけることができますか？

dac_overrideまた、付随的な質問でSELinux名と動作が既存のLinux権限違反を処理できると思いますか？

答え1

体系的なアプローチは

1）SELinuxを通過するように設定しますsetenforce 1。 SELinux違反のため、システムコールはmy_tool失敗するはずです。これを使用してgetenforce成功を確認できます。

2）失敗したシステムコールを識別するために、次のようにmy_tool実行します。stracestrace my_tool 2>&1 | grep '= -'

私の場合は、次の違反があります。type=1400 msg=audit(4816808.488:3): avc: denied { dac_override } for pid=123 comm="my_tool" capability=1 scontext=u:r:my_tool:s0 tcontext=u:r:my_tool:s0 tclass=capability permissive=0

strace my_tool 2>&1 | grep '= -'走る

openat(AT_FDCWD, "/some/file", some_mode) = -1 EINVAL (Invalid argument)

実行時にユーザーがファイルを所有していることls -l /some/file、およびファイルに対するDAC権限のために他のユーザーがそのファイルにアクセスできないことを確認してください。もちろん、ユーザーはこの制限を迂回しますが、SELinuxでは違反が発生します（systemmy_toolrootrootdac_overwrite引用する）。したがって、最後の質問に関しては、SELinuxは既存のDAC権限のバイパスを許可しませんが、ユーザーにこれらの権限を適用するためにも使用できますroot。

もちろん、このアプローチの効率は、my_tool通常の動作中に処理する他の失敗したシステムコールの数の複雑さによって多少異なります。

答え2

一般的なアドバイスフルシステムコール監査の有効化一部のパス情報を取得するには、このタイプのAVCを使用してください。しかし、Androidはサポートしていないようです。したがって、straceシステムコールを使用または追跡して、perf trace失敗したファイルに関連するシステムコールを見つけることが最適です。

また、見ることができます

DAC_OVERRIDE デバッグ（Androidで）、2019年にリリースされ、AVCが発生したときにいくつかの呼び出しスタックを取得するためにAndroidカーネルを変更する方法について説明します。これはもちろん、少し侵害的でアクセスできない場合にのみ価値があるようです。同様の情報を得るために探知機を設置できる人がいるからですperf。perf

関連情報