JSSECさんへパプコメ送ってみた

JSSECさんのサイトで公開されてるpdf『Android アプリのセキュア設計・セキュアコーディングガイド』【6月1日版】を読んでみて、気になった所をメールで送ってみました。パブコメの応募期間を考えると、次の版はおそらく【8月x日版】以降になりそうです。次版に意見が反映されるかどうかは分かりません*1が、とりあえずはてダの方にも転載しておきます。ほぼそのまま転載してるので「pochi-p→JSSEC」方向のメッセージとして読み進めてください。
なお件のpdf閲覧時に多分テキスト検索が快適には動かないと思われるので、当エントリと見比べて読まれる場合はAcrobatの「しおり」機能でpdfの該当箇所を探すことをオススメします。6/11に公開されたPDFがコピー禁止設定になっていて、その際PDF内検索にも悪影響が出ていたようです。現在は(翌日の6/12から？)コピー禁止解除版に差し替えられており、pdfの検索もサクサク出来るようになっています。同じ不具合に遭遇してる方はPDFを再DLしてみてください。

前提

当方はAndroid SDKのエミュレーターでの動作確認を行っており、バージョンは1.6・2.1・2.2・2.3.1・2.3.3・4.0.3です。そちら（＝JSSEC）の検証環境ともしかしたら挙動が違うかもしれませんが、『当方の環境でpdfを読み進めた』結果の指摘だとご理解ください。

「5.2.2.3. 独自定義のDangerous Permissionは利用してはならない」の内容が納得いかない

（※「独自定義のDangerous Permissionは利用してはならない」というルールそのものには賛成です）
当方がエミュレータで確認したAndroidの挙動と、該当項目で書かれてる内容が全くかみ合いませんでした。

『UserApp→ProtectedApp』のインストール順では、UserAppに権限はgrantされません。「うまくいかないケース」の挙動は本来ありえないのではないでしょうか？
『UserApp→ProtectedApp』の順でUserAppのuses-permissionに権限がgrantされるのは、特定バージョンのsignature/signatureOrSystemに限られる筈です。

そのあたりの挙動はこのエントリの『パーミッションはインストール順によって面倒が一杯』にまとめています。

『エミュレータ側の問題』という可能性も考えられますが、一度ご確認お願いします。

権限の許可がアンインストール時に剥奪されない仕様の想定漏れ？

2.1以前の環境での挙動を想定漏れされているように見受けられました。
pdfの

「4.1.1.4. 自社限定Activityを作成する」
「4.5.1.4. 自社限定Content Providerを作成する」

には「パートナー限定公開」と同じような呼び出し元アプリのチェック処理を追加するか、「Android2.2以降に限る」といった注意書きをもうけるべきだと思われます。（チェックは単純にPackageManager#checkSignaturesで呼び出し元／先の署名一致を確認するだけで十分でしょう）
理由は以下の通りです。

このエントリの『実は2.1以前のprotectionLevel=signatureには抜け穴がある。』での記述通りだと、『権限定義は想定通り』『しかし第三者アプリに権限がgrantされている』という状態がありえるからです。

自社限定公開のアプリでも（少なくとも2.1以前では）コンポーネント呼び出し元アプリの署名のチェックが必要と考えられます。

独自権限の定義場所について

pdfの

「5.2.2. ルールブック」
「5.2.2.4. 独自定義PermissionはComponentの提供側アプリだけでなく利用側アプリでも定義する」

にて書かれている『インストール順序を考慮し、すべてのアプリで独自定義Permissionを定義する』というルールについて気になる点があります。

このルールの効果と制定理由、よく分かります。私もそれがベストかなと以前まで思ってました。しかし『最初にインストールされ権限定義を担当したアプリが、他のアプリインストール後に真っ先にアンインストールされた』場合、権限が未定義状態になります。
絶対にアンインストールされない事が保証されるなら問題ありませんが、プリインストールアプリ以外ではまず現実的では無いでしょう。

今のところベストな代案は私も思いついていませんが、とりあえずはpdfの方に「アンインストール順についての注意」を追記しておくべきかと思われます。
そして関連するサンプルコードの権限チェック処理は「権限未定義＝権限定義がおかしい」と扱っているようですので、その対策も何かしら必要だと思います。

apkの改ざん（≒再署名）対策について

pdfの

「5.2.3.2. ユーザーがAndroidManifest.xmlを改ざんする」

にてAndroidManifest.xmlの定義を改ざんされていないかチェックする記述がありましたが、他にもアプリ自身の署名確認処理をActivity#onCreate時などで統一的に行う形にするのはどうでしょうか？
安易にAPKのリソース書き換え（≒再署名）される事によるsignature Permissionへの悪影響*2を考えると、自己署名チェックは付いている方が無難だと思います。
勿論ユーザー自身の責任と放置するのも一つの解かもしれませんが。

またサードパーティ製マーケットで（再署名した上で）無断転載された場合にも、結果的に簡易チェックが役立つケースもあるかもしれません。

勿論コード上の比較値を直接書き換え、apkの再署名する証明書のフィンガープリントと一致させてしまえば無効化される簡易チェックでしかありませんけども…。

コンポーネント呼び出し側の権限チェック処理をする『位置を明記』するとベター？

Android 2.2以降のsignature permission用の挙動により、起動中に権限変更がありえるので、pdfの

「4.2.1.4. 自社限定Activityを利用する」
「4.6.1.4. 自社限定ContentProviderを利用する」

のルールに「呼び出し側での権限のチェック処理は、権限を行使するタイミングでチェックする」の記述を追加した方がベターではないかと思います。
間違ってActivity#onCreateでだけチェックする事が無いように明記してあげるというお話です。
（現行のサンプルコードのチェック位置が『ベスト』という事です）

その他

他には『検証環境のバージョン情報の明記』『PDFファイルのフォーマットについて』『パブコメ募集フォーマットについて』『パートナー限定コンポーネントのホワイトリストで、デバッグ判定を個別にした方が良くね？』等を一緒にメールしました。

*1:私の指摘が間違ってて反映されない可能性も勿論あります(^^;)。このエントリ見て間違いに気づいた方はコメントください〜。

*2:『本来署名が違うのでgrantされなかった権限が、APK再生成＆再インストール時に権限をgrantされ得る』という悪影響。 http://d.hatena.ne.jp/pochi-p/20120701#p1 で解説しています。