Contenu connexe Similaire à AndroidとSELinux (20) Plus de android sola (16) AndroidとSELinux9. SELinuxを使用しない場合
Process A Linux Kernel
File A
File B
File C
-rw-r--r–- hoge hoge (省略)File A
-rw-r---–- hoge hoge (省略)File B
-rw------– hoge hoge (省略)File C
sola
solaは管理者権限を持たない一般ユーザ
hogeのグループには属していない
solaがProcess Aを実行してFile A, File B, File Cにアクセス(read)する例。
10. SELinuxを使用しない場合
Process A Linux Kernel
File A
File B
File C
-rw-r--r–- hoge hoge (省略)File A
-rw-r---–- hoge hoge (省略)File B
-rw------– hoge hoge (省略)File C
sola
solaは管理者権限を持たない一般ユーザ
hogeのグループには属していない
乗っ取られてProcess Aがroot権限を持ってしまった時は、
File A, File B, File C全てにアクセスされる。
乗っ取り
11. SELinuxを使用した場合
Process A
Linux Kernel
File A
File B
File C
-rw-r--r–- hoge hoge (省略)File A
-rw-r---–- hoge hoge (省略)File B
-rw------– hoge hoge (省略)File C
sola
solaは管理者権限を持たない一般ユーザ
hogeのグループには属していない
SELinuxを使用するとパーミッションによるアクセス制御の他に、
セキュリティポリシーによる制御が行われる。
SELinux
Security
policy
File B, File Cはrootで
あってもアクセス出来な
いようにSecurity policy
を定義する
12. SELinuxを使用した場合
Process A
Linux Kernel
File A
File B
File C
-rw-r--r–- hoge hoge (省略)File A
-rw-r---–- hoge hoge (省略)File B
-rw------– hoge hoge (省略)File C
sola
solaは管理者権限を持たない一般ユーザ
hogeのグループには属していない
乗っ取られてProcess Aがroot権限を持ってしまっても
Security policyの定義に従うので、File BやFile Cを守れる。
SELinux
Security
policy
File B, File Cはrootで
あってもアクセス出来な
いようにSecurity policy
を定義する
乗っ取り
16. TE(Type Enforcement)
TE の記述例
allow ドメインA タイプA アクセスベクタA;
allow ドメインA タイプB アクセスベクタB;
ドメインA がタイプA を read することを許可
ドメインA がタイプB を write することを許可
ドメインA
(プロセス)
タイプA
(リソース)
タイプB
(リソース)
アクセスベクタA(例:read)
アクセスベクタB(例:write)
• 簡単に表現すると、プロセスがファイル等のリソース
に対して出来る事を定義するもの
18. RBAC(Role Base Access
Control)
• RBAC は「ロール」と呼ばれるいくつかのドメインを
束ねたものを設定し、それをユーザに付与する仕組み。
• ユーザは付与されたロール内のドメインの権限でのみ
ファイルにアクセス可能。この機能により各ユーザ毎
に細かく権限を付与、制限することが可能。
21. Linux Kernelの確認
• Linux KernelでSELinuxの機能を有効にする
kernel configでCONFIG_SECURITY_SELINUXをyにする。
Linux Kernelに入っている機能なので、kernel config
で有効にするだけで使用することが出来る。
BSPとして提供された環境では最初は有効になってな
いこともあるので、確認する。
25. Security Policyの作成
• AOSP(Android Open Source Project)に無いものを
自分で作成する
ターゲット毎に異なるデバイス(/dev/***など)
独自の機能(アプリやサービス)
• AOSPにあるSecurity Policyは(基本的に)変更しない
自分のデバイスツリー配下に追加する
(Nexus5だとdevice/lge/hammerhead配下)
vendor配下に置くものはvendor配下に追加する
30. bootanimationのSecurity Policy
bootanim.te
type bootanim, domain;
type bootanim_exec, exec_type, file_type;
init_daemon_domain(bootanim)
binder_use(bootanim)
binder_call(bootanim, surfaceflinger)
allow bootanim gpu_device:chr_file rw_file_perms;
allow bootanim oemfs:dir search;
allow bootanim oemfs:file r_file_perms;
allow bootanim audio_device:dir r_dir_perms;
allow bootanim audio_device:chr_file rw_file_perms;
31. タイプの設定
bootanim.te
type bootanim, domain;
type bootanim_exec, exec_type, file_type;
init_daemon_domain(bootanim)
binder_use(bootanim)
binder_call(bootanim, surfaceflinger)
allow bootanim gpu_device:chr_file rw_file_perms;
allow bootanim oemfs:dir search;
allow bootanim oemfs:file r_file_perms;
allow bootanim audio_device:dir r_dir_perms;
allow bootanim audio_device:chr_file rw_file_perms;
32. タイプの設定
書き方
type ラベル, タイプ...
例1
type bootanim, domain;
bootanimというドメイン名の定義(bootanimationのこと)
例2
type bootanim_exec, exec_type, file_type;
bootanim_execは実行可能ファイルであることの定義。
タイプ...には複数記述出来る。
(実行可能ではない)通常のファイルの場合はfile_typeのみにす
る。
33. TEの記述
bootanim.te
type bootanim, domain;
type bootanim_exec, exec_type, file_type;
init_daemon_domain(bootanim)
binder_use(bootanim)
binder_call(bootanim, surfaceflinger)
allow bootanim gpu_device:chr_file rw_file_perms;
allow bootanim oemfs:dir search;
allow bootanim oemfs:file r_file_perms;
allow bootanim audio_device:dir r_dir_perms;
allow bootanim audio_device:chr_file rw_file_perms;
34. TEの記述
書き方
allow ドメイン タイプ:オブジェクトクラス アクセスベクタ;
ドメインはプロセス
タイプ:オブジェクトクラスはリソース
アクセスベクタはプロセスがリソースに対して行える操作
例
allow bootanim gpu_device:chr_file rw_file_perms;
bootanimがGPUデバイス(gpu_device:chr_file)に対して読み書
きする(rw_file_perms)のを許可する(allow)ルール。
35. TEの記述
例
allow bootanim gpu_device:chr_file rw_file_perms;
bootanimがGPUデバイス(gpu_device:chr_file)に対して読み書
きする(rw_file_perms)のを許可する(allow)ルール。
gpu_device:chr_file
gpu_deviceはfile_contextsというファイルで定義。
AOSPでは/dev/pvrsrvkmというデバイスファイルを指す。
※ターゲット毎に変更する必要有り。方法は後述。
chr_fileはsecurity_classesというファイルで定義。
chr_fileはキャラクタデバイス用。
ブロックデバイスだとblk_fileとなる。
36. TEの記述
例
allow bootanim gpu_device:chr_file rw_file_perms;
bootanimがGPUデバイス(gpu_device:chr_file)に対して読み書
きする(rw_file_perms)のを許可する(allow)ルール。
捕捉
allowで始まるルールは許可するものを書く。
許可したくないものは何も書かないか、neverallowを使用する。
neverallowを書いてるのにもかかわらずallowを書いていた場合、
コンパイル時にエラーとなる。
37. 便利?なマクロ
type bootanim, domain;
type bootanim_exec, exec_type, file_type;
init_daemon_domain(bootanim)
binder_use(bootanim)
binder_call(bootanim, surfaceflinger)
allow bootanim gpu_device:chr_file rw_file_perms;
allow bootanim oemfs:dir search;
allow bootanim oemfs:file r_file_perms;
allow bootanim audio_device:dir r_dir_perms;
allow bootanim audio_device:chr_file rw_file_perms;
39. ドメイン遷移の記述
書き方
type_transition 遷移元 ラベル 遷移先;
遷移元は遷移元のドメイン
ラベルは実行ファイルに設定されたラベル
遷移先は遷移先のドメイン
例
type_transition init bootanim_exec:process bootanim;
initからbootanimが起動する。
このルールがあるとbootanimはbootanimドメインで動作する。
42. 作成したSecurity Policyの組込み
• Security Policyはビルド時にテキストから専用の形式に
変換される。
• ビルド時に以下4つの変数を参照する。
BOARD_SEPOLICY_DIRS
BOARD_SEPOLICY_REPLACE
BOARD_SEPOLICY_UNION
BOARD_SEPOLICY_IGNORE
55. 問題の原因調査
• 解析時の基本、ログの調査。
(dmesg、logcatで同じログが出るので、どちらか)
<36>[ 0.997773] type=1400 audit(1429875733.980:4): avc:
denied { open } for pid=1017 comm="BootAnimation"
name="bootanimation.zip" dev="mtdblock1" ino=21154
scontext=u:r:bootanim:s0
tcontext=u:object_r:system_data_file:s0 tclass=file
permissive=0
<36>[ 0.997963] type=1400 audit(1429875733.980:5): avc:
denied { read } for pid=1017 comm="BootAnimation"
name="bootanime" dev="mtdblock1" ino=21155
scontext=u:r:bootanim:s0
tcontext=u:object_r:system_data_file:s0 tclass=dir
permissive=0
64. bootanimationのSecurity Policy
bootanim.teの内容
type bootanim, domain;
type bootanim_exec, exec_type, file_type;
init_daemon_domain(bootanim)
binder_use(bootanim)
binder_call(bootanim, surfaceflinger)
allow bootanim gpu_device:chr_file rw_file_perms;
allow bootanim oemfs:dir search;
allow bootanim oemfs:file r_file_perms;
allow bootanim audio_device:dir r_dir_perms;
allow bootanim audio_device:chr_file rw_file_perms;
※/data/theme配下へのアクセス許可が存在しないので拒否される
73. 効果の確認
/system/bin/kassy_kzを起動した結果
<4>type=1400 audit(1399014089.820:28): avc: denied
{ open } for pid=1987 comm=“kassy_kz”
name=“cocoa_chino.jpg” dev=“mtdblock1” ino=412
scontext=u:r:kassy_kz:s0
tcontext=u:object_r:system_data_file:s0 tclass=file
permissive=0
/data/picture/gochiusa/cocoa_chino.jpgを覗きに行ったけど、
SELinuxによってアクセスが拒否されたので、Security Policyの設定
に成功した事になります。
この後、必要な操作だけallowを追加していきます。
76. ls -Z
lsの結果にラベル表示してくれる。
shell@jcrom:/ # ls –Z
drwxrwx--x system system u:object_r:system_data_file:s0
data
-rwxr-x--- root root u:object_r:rootfs:s0 init
-rwxr-x--- root root u:object_r:rootfs:s0 init.rc
drwxr-x--x root sdcard_r u:object_r:rootfs:s0 storage
77. ps -Z
psの結果にラベル表示してくれる
shell@jcrom:/ # ps -Z
LABEL USER PID PPID NAME
u:r:init:s0 root 1 0 /init
u:r:shell:s0 shell 66 1 /system/bin/sh
u:r:adbd:s0 shell 67 1 /sbin/adbd
u:r:kernel:s0 root 139 2 kworker/0:2
u:r:system_server:s0 system 376 55 system_server