ABC2015summerのLT大会で発表した資料です。 @aki_sh_7

1. これからの
「パーミッション」の話をしよう
2015/7/20
塩田 明弘

2. 自己紹介
株式会社NTTデータ所属
メインの仕事はセキュリティ
2014/4より社内向けのAndroidセキュリティガイドラ
イン作成やサポートに従事

3. 自己紹介
株式会社NTTデータ所属
メインの仕事はセキュリティ
2014/4より社内向けのAndroidセキュリティガイドラ
イン作成やサポートに従事
今日パーミッションの話をする三人目…

4. 今回の資料はAndroid M Developer Preview 2ベースです。
最終版では異なる仕様になっている可能性があります。

5. Androidが抱える課題のひとつ

6. インストール時に許可した
パーミッションを後から変更できない
(すべて許可しないと使えない)
Androidが抱える課題のひとつ

7. 許可したら許可しっぱなし
インストール時
連絡帳の読取 位置情報へのアクセス
ショートカットの作成
連絡帳の読取インストール後
連絡帳を読み取らせたくなくても、その機能だけ使わせないようにはできない

8. でも

9. Android Mから
新パーミッションモデルが採用

10. 新しいパーミッションモデルの特徴
インストール時ではなく、利用時に許可を求める
許可を与えても後から変更が可能

11. 新しいパーミッションモデルの特徴
 インストール時には変更可能なパーミッションは許可されていない状態
 変更可能なもの以外のパーミッションは以下のファイルで管理される
/data/system/packages.xml
インストール時

12. 新しいパーミッションモデルの特徴
連絡帳の読取
利用時
 「連絡帳の読取」が必要な機能を使うときに、
パーミッションをチェックして個別に許可する
 設定画面からも変更可能で与えていた許可を取り
消したり、要求がなくても許可を与えることが出来る
 変更可能なパーミッションは一度操作すると個別に
以下のファイルで管理される
/data/system/user/{userId}/runtime-permissions.xml
<pkg name="com.android.musicfx">
<item name="android.permission.BLUETOOTH" granted="true" flags="0" />
</pkg>

13. 旧バージョン向けのアプリのケース
インストール時
連絡帳の読取 位置情報へのアクセス
ショートカットの作成
 インストール時にすべて許可を与えるが、後から取り消せる
 パーミッションは全て次のファイルで管理される(/data/system/packages.xml)
連絡帳の読取インストール後

14. 不許可設定での挙動(新)
 パーミッションがないとして終了
→checkSelfPermissionで要確認

15. 不許可設定での挙動(旧)
 APIに応じた挙動を示す(空の値が返る等、「パーミッションがない」とはならない)
 checkSelfPermissionでの確認は通過する

16. コレって似たのなかったっけ？

17. コレって似たのなかったっけ？
App Ops

18. App Ops
Android4.3から搭載されている隠し機能
許可を与えても後から変更が可能
4.4.2以降では要root化

19. Runtime Permissionは
App Opsの正式リリース版？

20. Runtime Permissionは
App Opsの正式リリース版？

21. App Opsは
Runtime Permissionと
密接に関係しつつ
別に存在している

22. 旧バージョン向けはApp Opsが制限
設定画面で許可を変更すると、App Opsの設定に反映される
設定は次のファイルで管理される。(/data/system/appops.xml)
Packeges.xml中のパーミッション自体は取り消されない
M向けは許可を取り消されると、granted=“false”となって、
パーミッション自体が取り消される
M向けアプリも許可を与えたうえでApp Opsを設定すれば、
App Opsで制限される
連絡帳の読取
読み取りさせないための別機能が働く
実際の動き
パーミッションは与えられたまま

23. App Opsと比べて、
Runtime Permissionに
不満を感じる部分もある

24. Runtime PermissionとApp Ops
の比較
インストール時のパー
ミッション要求
インストール後の
権限管理
権限の操作単位
Runtime
Permission
○
要求予告
○
機能使用時の要求と
設定画面での操作
△
Permission
groups単位
App Ops ×
要求されたものは全
て許可
△
設定画面での操作
○
Permission単位
(例外有り)

25. Permission group単位で
許可を与えることによる問題
パーミッション グループ パーミッション
android.permission-group.CONTACTS android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.READ_PROFILE
android.permission.WRITE_PROFILE
コミュニケーション系アプリで以下の機能を想定
A) 既存ユーザを探すために、連絡帳の情報を利用
要：android.permission.READ_CONTACTS
B) サービス上のユーザを連絡帳に追加
要：android.permission.WRITE_CONTACTS
いずれもandroid.permission-group.CONTACTSに所属
deprecated

26. Permission group単位で
許可を与えることによる問題
ユーザは機能Aを許可したつもりでも、機能Bも実行される
①機能A利用の要求
③パーミッショングループへの許可要求
④パーミッショングループへの許可
⑤パーミッショングループへ
の許可の付与
②パーミッションチェック
(READ_CONTACTS)
ユーザ アプリ・端末
⑥機能Aの利用
⑦機能B利用の要求
⑧パーミッションチェック
(WRITE_CONTACTS)
⑨機能Bの利用
ここでREAD_CONTACTSだけでなく、
WRITE_CONTACTSにも許可が与えら
れる

27. 問題の緩和策
 公式のベストプラクティスには、パーミッションの要求を
行う前に、「パーミッションがなぜ必要か説明を行う」
とある。(もしくはチュートリアルでの説明など)
 しかし、Permission Group単位で権限が与えら
れることを考慮すると、「機能を使うためにパーミッショ
ンが必要という説明」だけではなく、「パーミッション(グ
ループ)を許可することによる、アプリ全体への影響の
説明」も必要と思われる。

28. まとめ
 AndroidのパーミッションモデルはAndroid Mで新しい
モデルにとなり柔軟に
 旧バージョン向けのアプリのパーミッションモデルは同じよう
に見えるが制御方法が異なる(App Ops利用)
 App Opsとは異なり、グループ単位での設定のため融
通の効かない部分もあり
(出来ればパーミッション単位でも設定したい)
 パーミッション要求時には「なぜ必要か」だけでなく、アプリ
全体で「許可したらどうなるか」の説明もあるとよい

29. 本資料の著作権は、講演者(塩田 明弘)に帰属します。