問題は、途中に美味しそうな店があるためにかえってカロリーが増えないかどうか。アジャンタはやっぱり気になるよねぇ…(ごくり)

挫折多いなあ…orz

お昼は久しぶりにRTでキーマカレー。以前2回の時の味が今一すぎて、前回など色味すら変化していたために見限っていたのだが、久しぶりにランチを食べたところ、メニューのセット構成こそ変化しているものの、味は十分満足できる内容だった。ここのキーマは好みなので、また適度に通うとしよう。

その後、新宿に出てテルマエ・ロマエの映画を見にいこうとしたら、見事なまでに満席で負ける。公開から大分たっているはずなのだが、まだ予約を入れてからいったほうが良い時期だったらしい。

仕方がないので、新宿タカノのフルーツパーラーで、季節物のマンゴーのパフェを楽しむ。

深大寺蕎麦を食べようと松葉茶屋にいってみたら、丁度混む時間のようでいつもよりも大分長い待ち時間となっていた。メニューも天麩羅が20分待ちなどかなりの品が無く、いつもはあまり頼まないおろし蕎麦にしてみた。

その後は、神代植物園の薔薇フェスタでひたすら花や草木の間を散歩。広い空間に薔薇が咲き乱れているので、とにかく場所ごとの香りがすごい。野薔薇中心の場所に行くと、恐しいほどの違いを感じられる。

日差しが強い日だったので、早々に退散。

いくつか内見した結果、氷川台に近い物件があり、条件も悪くなかったので決定した。彼女が転勤辞令を受けないとこちらに来れないので、当初は私だけ引っ越す予定。できるだけ開始を遲くしてもらう予定だけれど、準備はしておかないと。

…夜になって微妙にトラブル。礼儀作法についてはより慎重な態度が必要だ。

どっと疲れたのでvivo!でビールを頼んで、やけ酒気味に飲む…としなくても飲みすぎそうな位に色々なビールが美味な店でした。フードもなかなか良い感じで、ビネガーだばだばで食べるフィッシュアンドチップスが美味しい。

戻った途端にぱたりと倒れてダウン。ああ疲れた。

名前を伏せたいそうなのでお相手はここでは書きませんが、今後ともよろしくお願いします。

何故かMoney形式でのエクスポートが廃止されていたらしい。代わりにCSVになっていたのだが、Moneyと相性が悪く色々と悪化してしまった。

まず、エクスポートの日付が前回からとできなくなったので、前回の取り込み日を調べて直接指定するしかなくなった。そして致命的なことに金額が3ケタ狂う。どうやらMoneyで区切りの,を.に誤認識(そういう国もあるから仕方ない)するので、正しい金額が入らない。仕方がないので手動で置き換え。CSVだとどの項目が何かわからないので、全部インポートの度に手動で設定する必要がある。

不便になったなあ。これは何か別の方策を考えないと続かないか…。

• [COMIC] 乙嫁語り 4巻 (森薫)
• [COMIC] あまあま (志摩時緒)

あまあまは、なんとなく紹介を見て気になったので購入。確かに破壊力抜群でした…壁はどこだー

STOWAWAYには、Android 2.2のPermissoon Mapがある^[1]。これは、どのAPIを呼び出せばどのパーミッションが必要かわかるマップだが、いかんせん情報量が多くてわかりにくい。また、基本は同じとはいえAPI levelにより多少変化もしている。

そこで、整理のために論文”Android Permissions Demystified”(PDF)を元にして、おおまかな区別を抜き出してメモとする。

まず最初に触れておきたいのは、結局統一したPermissionのポリシーなど無い、ということだ。以下に説明するようにあちこちで権限が持ちだされ、チェックされ、あるいは無視されている。中には無駄にチェックするAPIもあるらしい。よって、現状のAPI Levelでは食い違っている箇所がでることを前提とする。

最初に、Permissionは3種類の脅威レベルに分けられる。

1. Normal Permission: 壁紙の変更など、APIへのアクセスを制限するもの。
2. Dangerous Permission: SMS送信など、API呼び出しにより潜在的に危険をもたらすもの。
3. Signature/System Permission: 署名されたアプリケーションでだけ使えるもの。バックアップやアプリケーションのインストールなど、特に危険なもの。
4. (他、各アプリケーションが独自に定めるPermission)

Android API frameworkの構造は「APIライブラリ」「システムプロセス中のAPI実装」の二つのパートに分割できる。「APIライブラリ」は各アプリケーションの仮想マシンで動作するもの。当然、アプリケーションと同様の制限を受ける。それに対し「システムプロセス中のAPI実装」に制限はない。ライブラリが構文糖としてユーザからのリクエストを代理で受け、裏でシステム側で実行する、といった感じになる。

APIの呼び出しは三ステップで行われる。まず、アプリケーションはライブラリのAPIをinvokeする。次に、ライブラリはライブラリ中のprivate interfaceをinvokeする。このprivate interfaceはRPC stubになっていて、最後にRPCリクエストがシステムプロセスとして、システムサービスに誰が処理してくれるか尋ねる。この仕組みはJavaのreflectionが使われている。

例えば、ClipboardManager.getText()は、IClipboard$Stub$Proxyに引き渡され、システムのClipboardServiceが呼ばれる。

さて、肝心のPermissionのチェックだが、統一ポリシーなどは存在せず、実に色々な箇所で行われる。システムプロセス中のAPI実装でチェックするものもあれば、ライブラリ中で随時チェックするものもある。極一部の権限(INTERNET, WRITE_EXTERNAL_STORAGE, BLUETOOTHなど)は、Unix groupで制御されている。この場合、API側は何もチェックせず、ただinvokeするだけである。

Android NDKで開発できるNative Codeでは、直接にはシステムのPermissionを制御できない。、ソケットやファイルにアクセスする場合、Java wrapperを用意して行うことになる。

Content Providerは、単独のアプリケーションとしてインストールされて他のシステムプロセスやAPIライブラリからは切り離され、抱える情報の保護のために静的/動的なPermissionチェックを行う。アクセス先は、read/writeといった定義と、”content://a/b”のようなpathにより指定される^[2]。

Intentは、全てシステムサービスのActibityManagerServiceを通じて送信される。二つのテクニックによりIntentの送信は制限されている。一つは、Permissionを持っているアプリケーションにだけ送信する仕組みである。もう一つは、システムのIntentはUIDがマッチするプロセスにしか送信しない仕組みである。受信の場合もだいたいはPermissionが必要であり、OSが送信するIntentの受取先を制限している。

(論文では、この後もテストコードを暮ろうとしたらAndroid側が色々アレで大変でしたという話や、APIの分析結果が続きますが、省略。)

1. 一応、本命はapkをアップロードして余分な権限を宣言していないか解析を行えるStowawayの方、のはず。
2. 余談だが、BlackHatなどで発表されたMercuryという「うっかりContent ProviderやServiceに権限をつけ忘れて、publicになっていないか」というチェックを行うためのツールが存在し、最新のAndroguardと組み合わせて使うこともできるらしい(AREには未収録)。