私はいくつかの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通常の動作中に処理する他の失敗したシステムコールの数の複雑さによって多少異なります。