SELinuxに付属の特定のROMを「許可」モードでインストールしました。これは私のデバイスに適切に適合する唯一の（良い）ROMであり、SELinuxの状態を変更する方法はありません。

今、私はそのような決定の結果が何であるか本当にわからないので、誰かがそれを説明できたら幸いです（私はそれをグーグルで調べて、理論的には何を知っている...ただ実際にではありません）。このROMのルートは「無効」であるため、デバイスはルート化されていないはずですが、SELinuxにどのように適合するのかはわかりません。

TL; DR：必要に応じて、下の結論に直接ジャンプしてください:)！

SELinuxの目標は、特権のないユーザーと特権のあるユーザーの両方から可能なアクションを制限する必須ポリシーを適用することにより、特権のエスカレーションを防ぐことです。

ここでの「ユーザー」という用語には、すべてのプロセスが何らかのシステム「ユーザー」アカウントを使用して実行されているため、物理的なユーザーアクション（人間、あなた;））に直接関係するデバイスで実行されているプロセスも含まれます。

歴史的に、Unixベースのシステムのアクセス許可は、いわゆる随意アクセス制御（DAC）システムを使用して処理されます。このモデルでは：

• ファイルなどのリソースには、所有するリソースのアクセス権を定義できる所有者がいます。これにより、特定のリソースをプライベートにするか（所有者のみがアクセスできるか）、または他のユーザーと共有するかどうかを決定できます。
• さらにroot、管理ユーザーであり、システム上のすべてにアクセスできるスーパーユーザー（Unixベースのシステムで呼び出されます）がいます。このアカウントは、人間（通常はシステム管理者）がデバイスを保守または修復するために対話的に使用できますが、通常、このアカウントは主に、デバイスドライバー、ネットワーク構成サービス、サービスなどの特権レベルを必要とするバックグラウンドまたは低レベルのサービスで使用されますすべてのユーザーのファイルにアクセスする必要があるか、内部ユーザー間通信を処理します。

これは非常に便利で、すでに優れたセキュリティを提供しています。ただし、次のような状況はどうでしょうか。

1. 実行中のサービスでバグrootが発見され、攻撃者がそのようなサービスをallowして任意のコードを実行できるようになる場合はどうなりますか？そのような攻撃者は、デバイスへの完全なアクセスを取得します。いくつかの具体的な例を挙げると、特別に細工されたネットワーク構成情報（DHCP）またはMMSを電話に送信することにより、このようなバグが引き起こされる可能性があります。
2. 一部のユーザーがプライベートリソースを正しく保護しないとどうなりますか？次に、これらのリソースは、他の非特権ユーザーによって悪意を持ってアクセス（読み取り、場合によっては変更または削除）される可能性があります。これは通常、悪意のあるアプリケーションが携帯電話で実行されているときに持っているものです（インストールにだまされた場合でも、別の非特権アプリケーション、ブラウザ、またはメールクライアントのバグを使用して自分でここに来た場合でもインスタンス）、およびこの悪意のあるアプリケーションは、他のアプリケーションのデータまたはストレージの場所に直接アクセスしようとします（通常はアクセスできないデータにアクセスするか、削除を困難にするためにいくつかの場所に自分自身をインストールします）。

SELinuxが登場します。

SELinuxは必須アクセス制御（MAC）システムです。前述のDACシステムでは、ユーザーは自分のリソースに適切な権利を設定する責任がありましたが、MACシステムでは、システム全体のポリシー（オペレーティングシステムに付属）が特権ユーザーと非特権ユーザーの両方に適用されます。

これにより、上記の2つの問題が次の方法で解決されます。

1. 先ほど言ったように、このポリシーは特権ユーザーにも適用されます。これは、適切に設計されたポリシーでは、デバイスのネットワーク構成を処理するように設計されたサービスは他に何もできないことを意味します。たとえば、SMSにアクセスできず、SMSを処理するサービスはネットワーク構成にアクセスできません、両方ともスーパーユーザーアカウントを使用して実行されているにもかかわらず、どちらもユーザーのデータにアクセスできません。
2. Androidには最近、SELinuxによって実施されるマルチユーザー機能が組み込まれ、ユーザーが他のユーザーのデータにアクセスできないようにしています。しかし、それを超えて、SELinuxポリシーは許可されたアプリケーションの動作を記述することにも責任があります。また、DACシステムを使用して一部のリソースが適切に保護されない場合でも、SELinuxが助けになり、悪意のあるアプリケーションがそれらに直接アクセスすることを防ぎます。

DACシステムとMACシステムは相互に排他的ではありませんが、逆にMACシステム（SELinux）はDACシステムの背後にある2番目の防御層として機能します（従来のUnixライクな権限）。SELinuxの仕事は、ポリシーに反するアクティビティをブロックすることです。これは、DACシステムのみが与えられた場合に受け入れられます。

トリッキーなことは、そのようなポリシーを書くのは非常に複雑になる可能性があるということです。実際には、あらゆる状況で考えられるあらゆる使用法に対して、すべてのデバイスのコンポーネントをカバーする必要があります。実際、あなたの状況で何らかのアクションが合法であるかどうかに関係なく、ポリシーに含まれていない場合は禁止されています。したがって、適切に設計されていないポリシーは、アプリケーションのクラッシュ、使用できない機能などのランダムな結果をもたらす可能性があります。

そのため、SELinuxを出荷するAndroidの最初のバージョンには、デフォルトで「許可」モードが含まれていました。このモードでは、SELinuxはポリシー違反をログに記録しますが、関連するアクティビティをブロックしようとしません。結果のログファイルを分析することにより、残りのポリシー違反のみが実際に悪意のあるまたは望ましくない動作になるまで、ポリシーを修正および強化することが可能になります。この時点で、SELinuxは「強制」モードに変更できます。ログを記録するだけでなく、問題のあるアクションをすべてブロックするようになります。

結論

SELinuxは緩和技術です。攻撃者が電話に侵入するのを防ぐことはできませんが、一度そこに侵入すると、できる限り少ないことを行うことができます。

ROMが古いほど、そのようなアクセスを開くセキュリティバグの数が多くなります。SELinuxは、これらの既知の脆弱性にもかかわらず最小限の安全性を維持するための効率的な方法ですが、SELinuxが適切に機能するには複雑なポリシーに依存します。

ROMがデフォルトで「許可」モードのSELinuxで提供されている場合、これはおそらく、その中に含まれるポリシーが「強制」モードに安全に切り替えられるほど信頼性が低いことを意味します。

あなたが十分に熟練しており、電話ログにアクセスできる場合（dmesg少なくとも、しかし通常はそれらもコピーされlogcatます：後者を見ることができるアプリケーションがありますが、Androidのバージョンによってはrootアクセスが必要な場合があります）、 「avc」エントリを見つけます。これらは、SELinuxがポリシーに反するアクションを検出したことを伝えるメッセージです。

CyanogenModのWebサイトから取得したこのようなエントリの例を次に示します。

type=AVC msg=audit(1363289005.532:184): avc: denied { read } for pid=29199 comm="Trace" 
name="online" dev="sysfs" ino=30 scontext=staff_u:staff_r:googletalk_plugin_t 
tcontext=system_u:object_r:sysfs_t tclass=file

存在しない場合、それらのうちのごく一部、または何らかの理由で電話を使用できないと思われる場合は、SELinuxを「強制」モードに切り替えてみてください。古いCyanogenMod ROMでは、これはGUIの隠しオプションを使用するだけで簡単で可能です（電話をルート化したり、特定のアプリケーションをインストールする必要はありません）。 tagあなたがラッキーかもしれないと思う;）。