🥌 👰🏾 🏴‍☠️ Androidオペレーティングシステムのセキュリティの基本。ネイティブユーザースペース、パート2 📋 🧝 👨🏻‍⚖️

エントリー

今日は、コアより少し上のレベルでセキュリティを検討し続けます。第2部では、system.img、userdata.img、cache.imgがどこから来たのか、およびネイティブユーザー空間でセキュリティがどのように提供されるかを見ていきます。

興味のある方、ようこそ！

記事一覧

このトピックからの私の記事へのリンクは次のとおりです。

ネイティブユーザースペースの意味

ネイティブユーザースペースとは、Dalvik仮想マシンの外部で実行され、Linuxカーネルの一部ではないすべてのユーザースペースコンポーネントを指します。ネイティブユーザースペースは、特定のアーキテクチャ用にコンパイルされた実行可能ファイルです。これらには、initスクリプトから自動的にまたはイベントのイベントで起動される実行可能ファイル、ツールボックスユーティリティ、およびユーザーがシェルの下から実行できる実行可能ファイルが含まれます。

開始する

最初の部分で述べたように、AndroidはLinuxカーネルに基づいています。すべてのLinuxシステムと同様に、Androidのセキュリティはアクセス制御に基づいています。つまり各リソース（ファイルなど）には、このファイルの作成者（所有者（所有者））および所有者（所有者）に属するメイングループ（所有者グループ）に関するメタ情報が含まれています。各プロセスは、一部のユーザー（ユーザー）に代わって起動されます。各ユーザーにはコアグループがあります。さらに、彼は他のグループのメンバーである可能性があります。したがって、リソース（ファイルなど）の読み取り/書き込み/実行が可能なユーザーに関する情報を（rwxrwxrwx形式で）各リソースに添付すると、このファイルへのアクセスを制御できます。たとえば、ファイルにアクセス許可を割り当てることができます。このファイルの所有者（所有者）がこのファイルでできること。所有者グループの一部であるユーザーができること。誰もができること。ここで、これについて詳しく読むことができます。

ただし、Androidにはいくつかの違いがあります。まず、Androidは最初は携帯電話用のオペレーティングシステムです。ご存知のように、これは非常に個人的なものに属し、間違った手に渡したくないものです。つまり、ユーザーが1人だけのオペレーティングシステムとして考えられていました。したがって、セキュリティのためにさまざまなLinuxユーザーを使用することが決定されました（アプリケーションごとに-最初の記事で既に述べたように、個別のユーザー）。第二に、Androidでは、一部のユーザー（ユーザー）とそのUID（識別子）がシステムにハードコーディングされていたため、セキュリティに関係する人々から多くの苦情が寄せられています（正直なところ、このアプローチがなぜ批判されているのか本当にわかりません）。これらのユーザーは、ファイルシステム/core/include/private/android_filesystem_config.hで既に見ています。たとえば、 rootの識別子は0で、 system - 1000です。

すでに述べたように、プロセスは、この新しいプロセスを開始するプロセスと同じユーザー（UID）に代わって開始されます。 UID（calling_process）== UID（called_process）。 Androidで実行される最初のプロセス-init-はルートとして実行されます（UID == 0）。したがって、理論上、すべてのプロセスは同じユーザーに代わって開始する必要があります。おそらくそうだったでしょう。ただし、最初に、特権ユーザー（および特定の機能を持つユーザー）に代わって実行されるプロセスは、UIDを特権の低いユーザーに変更できます。次に、Androidでは、 init.rcスクリプトでデーモンを起動するときに、このプロセスを開始するユーザーとグループの特権を指定することもできます。

... service console /system/bin/sh class core console disabled user shell group log ... service servicemanager /system/bin/servicemanager class core user system group system critical onrestart restart zygote onrestart restart media onrestart restart surfaceflinger onrestart restart drm ... service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc ioprio rt 4 ...

これらのデーモンを介して起動されるすべてのプロセスには、ルート権限がなくなります。

システム、データ、キャッシュ

私はこのトピックを何度も発表しているので、非常に複雑で混乱していると思うでしょう。実際、これはそうではありません。 System.img 、 userdata.imgおよびcache.imgは、Androidオペレーティングシステムをコンパイルした結果です。つまり、システムを組み立てた結果、これらの3つのファイルが取得され、デバイスに書き込まれます。

しかし、最も重要なことはこれではありません。 Androidシステムでは、システムユーザーのユーザー名とUIDがハードコーディングされているため、すでにコンパイル段階で、これらのイメージのさまざまなディレクトリに対するさまざまなシステムユーザーのアクセス権を決定できます。これらの権限は、最初の記事ですでに説明したsystem / core / include / private / android_filesystem_config.hファイルで指定されています。アクセス権は、次のようにディレクトリ（android_dirs []）およびファイル（android_files []）に対して別々に定義されます。

 ... struct fs_path_config { unsigned mode; unsigned uid; unsigned gid; uint64_t capabilities; const char *prefix; }; /* Rules for directories. ** These rules are applied based on "first match", so they ** should start with the most specific path and work their ** way up to the root. */ static const struct fs_path_config android_dirs[] = { { 00770, AID_SYSTEM, AID_CACHE, 0, "cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/dalvik-cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data/data" }, { 00771, AID_SHELL, AID_SHELL, 0, "data/local/tmp" }, { 00771, AID_SHELL, AID_SHELL, 0, "data/local" }, { 01771, AID_SYSTEM, AID_MISC, 0, "data/misc" }, { 00770, AID_DHCP, AID_DHCP, 0, "data/misc/dhcp" }, { 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media" }, { 00775, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/Music" }, { 00771, AID_SYSTEM, AID_SYSTEM, 0, "data" }, { 00750, AID_ROOT, AID_SHELL, 0, "sbin" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/bin" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/vendor" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/xbin" }, { 00755, AID_ROOT, AID_ROOT, 0, "system/etc/ppp" }, { 00777, AID_ROOT, AID_ROOT, 0, "sdcard" }, { 00755, AID_ROOT, AID_ROOT, 0, 0 }, }; /* Rules for files. ** These rules are applied based on "first match", so they ** should start with the most specific path and work their ** way up to the root. Prefixes ending in * denotes wildcard ** and will allow partial matches. */ static const struct fs_path_config android_files[] = { { 00440, AID_ROOT, AID_SHELL, 0, "system/etc/init.goldfish.rc" }, { 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.goldfish.sh" }, { 00440, AID_ROOT, AID_SHELL, 0, "system/etc/init.trout.rc" }, { 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.ril" }, { 00550, AID_ROOT, AID_SHELL, 0, "system/etc/init.testmenu" }, { 00550, AID_DHCP, AID_SHELL, 0, "system/etc/dhcpcd/dhcpcd-run-hooks" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, 0, "system/etc/dbus.conf" }, { 00444, AID_RADIO, AID_AUDIO, 0, "system/etc/AudioPara4.csv" }, { 00555, AID_ROOT, AID_ROOT, 0, "system/etc/ppp/*" }, { 00555, AID_ROOT, AID_ROOT, 0, "system/etc/rc.*" }, { 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app/*" }, { 00644, AID_MEDIA_RW, AID_MEDIA_RW, 0, "data/media/*" }, { 00644, AID_SYSTEM, AID_SYSTEM, 0, "data/app-private/*" }, { 00644, AID_APP, AID_APP, 0, "data/data/*" }, { 00755, AID_ROOT, AID_ROOT, 0, "system/bin/ping" }, /* the following file is INTENTIONALLY set-gid and not set-uid. * Do not change. */ { 02750, AID_ROOT, AID_INET, 0, "system/bin/netcfg" }, /* the following five files are INTENTIONALLY set-uid, but they * are NOT included on user builds. */ { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/su" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/librank" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/procrank" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/procmem" }, { 06755, AID_ROOT, AID_ROOT, 0, "system/xbin/tcpdump" }, { 04770, AID_ROOT, AID_RADIO, 0, "system/bin/pppd-ril" }, /* the following file has enhanced capabilities and IS included in user builds. */ { 00750, AID_ROOT, AID_SHELL, (1 << CAP_SETUID) | (1 << CAP_SETGID), "system/bin/run-as" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/bin/*" }, { 00755, AID_ROOT, AID_ROOT, 0, "system/lib/valgrind/*" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/xbin/*" }, { 00755, AID_ROOT, AID_SHELL, 0, "system/vendor/bin/*" }, { 00750, AID_ROOT, AID_SHELL, 0, "sbin/*" }, { 00755, AID_ROOT, AID_ROOT, 0, "bin/*" }, { 00750, AID_ROOT, AID_SHELL, 0, "init*" }, { 00750, AID_ROOT, AID_SHELL, 0, "charger*" }, { 00750, AID_ROOT, AID_SHELL, 0, "sbin/fs_mgr" }, { 00640, AID_ROOT, AID_SHELL, 0, "fstab.*" }, { 00644, AID_ROOT, AID_ROOT, 0, 0 }, }; ...

また、このファイルの後半で定義されている静的インラインvoid fs_config関数（const char * path、int dir、unsigned * uid、unsigned * gid、unsigned * mode、uint64_t * capabilities）は、所有者、所有者グループ、機能、およびアクセス権の設定を担当します。この関数は、イメージのアセンブリ中に呼び出されます。

一般に、一部のファイルに許可フラグ（setuidおよびsetgid）を設定することを除いて、ここのすべては多かれ少なかれ明確でなければなりません（たとえば、「system / xbin / su」の許可は06755として定義され、最初の6はフラグが設定されることを意味します）ユーザーID（4）を設定し、グループIDを設定するためのフラグ（2）を設定します）。これらのフラグを設定すると、ユーザーは起動されたプロセスの権限をファイルまたは所有者グループ（所有者グループ）の所有者（所有者）のレベルまで増やすことができます。 Androidの場合、各アプリケーションは独自のUIDとGIDを持つユーザーです。したがって、デフォルトでは、アプリケーションからネイティブ実行可能ファイルを実行すると、それを呼び出したアプリケーションと同じUIDおよびGIDで実行されます。これらの許可フラグを設定すると、所有者権限でネイティブ実行可能ファイルを実行できます。この例では、所有者はAID_ROOT（ルート）です。これは、次のsystem / extras / su / su.cで発生します。

 int main(int argc, char **argv) { ... int uid, gid, myuid; ... if(setgid(gid) || setuid(uid)) { ... } ... }

つまり setuidおよびsetgid関数が呼び出されます。この場合、これらの機能が正常に完了すると、プロセスはこのファイルの所有者と所有者グループに代わって作業を開始します。この例では、このプロセスはスーパーユーザーの権利を受け取ります。彼は自分のやりたいことは何でもできます:)そのような無秩序は常に正当化されるとは限らないので、Linuxは能力の概念を導入しました run-asアプリケーションはすべてのスーパーユーザー権限を必要としないため、さまざまなユーザーに代わってアプリケーションを実行するために識別子を変更できる必要があります。ちなみに、機能は最近登場したようです-Android 2.3.xではそれらは見ていません。

安全性

特権プログラム（suなど）の場合、これらのプログラムが呼び出すことができるアプリケーションの範囲を制限する必要があります。それ以外の場合、アプリケーションはスーパーユーザー権限を取得できます。したがって、非常に多くの場合、UID検証はそのようなプログラムに組み込まれています。

 ... #include <private/android_filesystem_config.h> ... int main(int argc, char **argv) { struct passwd *pw; int uid, gid, myuid; /* Until we have something better, only root and the shell can use su. */ myuid = getuid(); if (myuid != AID_ROOT && myuid != AID_SHELL) { fprintf(stderr,"su: uid %d not allowed to su\n", myuid); return 1; } ... }

つまりプログラムは、 getuid（）関数を使用して、呼び出しプロセスが開始された人を最初にチェックします。そして、これらの値をシステムにハードコードされた値と比較します。この場合、ユーザー「system」および「root」に代わって実行されるプロセスのみがsuを使用する権利を持ちます。

おわりに

この記事では、ネイティブユーザー空間レベルでのセキュリティの提供方法の分解を終了しました。次の記事では、許可の仕組みを分析する予定ですが、現在の負荷が大きいため、いつ書き込みを開始するのかわかりません。いつものように、私は追加と修正に非常に満足しています。

PS DevConf @ mobiのレポートの作成に招待されました。アプリケーション開発者に焦点を当てた会議で、聴衆はAndroidオペレーティングシステムのセキュリティに関するレポートに興味があると思いますか？

Androidオペレーティングシステムのセキュリティの基本。ネイティブユーザースペース、パート2

エントリー

記事一覧

ネイティブユーザースペースの意味

開始する

システム、データ、キャッシュ

安全性

おわりに

参照資料

More articles:

Androidオペレーティングシステムのセキュリティの基本。 ネイティブユーザースペース、パート2

エントリー

記事一覧

ネイティブユーザースペースの意味

開始する

システム、データ、キャッシュ

安全性

おわりに

参照資料

More articles:

Androidオペレーティングシステムのセキュリティの基本。ネイティブユーザースペース、パート2