読者です 読者をやめる 読者になる 読者になる

Creating XPC Services bluteforce 訳 (1)

どうもAppStoreで実現したいことを、他人はあっさり(?)実現しているようなので、いろいろやってみているのだけれど、うまくいかない。。。

 

可能性として考えられるのは、

  1. codesignをmanualでごまかして、Sandboxを迂回してる
  2. SMCにアクセスできるなにか秘密のentitlements keyを発見した
  3. XPCを使うとできる
  4. 開発者がAppleと癒着している、もしくは先駆者特典
  5. 実はAppStoreにでているproductsも実際ラウンチするとアクセスヴァイオレーション(2e2)ではねられて、うまく動かない?(実際買っていないのでそこは分からない)

くらいで、1か4ならそのうち使えなくなるはず、cheat系はハックしても時間の問題で徒労に終わることが多いので、今回は手を出さない。

2は少なくともAppleの公式発表に出ていないkeyを使っていることになるが、いくらググっても出てこない。これもある日使えなくなる可能性があるのであまりやりたくないし、ランダムな文字列で設定を探るなどといったことはしたくない。(いや、してもいいけどクレバじゃない。。。)

5だったら詐欺だけど。。。まさかね。

 

ということで、可能性はそれほど高くはないけど3に照準を絞って、XPCで組んでいるのだが、これが全くもっていうことを聞かない。

XPCのサンプルを持ってきて動かしてはみたのだけれど、さっぱりわからない。そもそもAppleから出ているそのサンプルは、AppleCreating XPC Services というガイドラインに全然則っていない。

 

こういう時、考えられる可能性てのがいくつかあって

  • ガイドラインをちゃんと読めていない
  • なにか勘違いをしている、抜けている
  • 斜め読みに失敗してる

いや、これは。。。3つとも同じ事象について述べているわけだが。

つまりちゃんとドキュメント読もうとおもって、何回かに分けて(これまたテキトーに)全訳してみる。

Markdownで手元に置いといてもいいんだけど、せっかくなので晒します。

 

Creating XPC Services

libSystemの一部であるXPC Service APIはlaunchdとGCD(Grand Central Dispatch)を利用した基本的なプロセス間通信のための軽量なメカニズムを提供している。このサービスによってライトウェイトヘルパーツールをつくることができる。

 

Stability

アプリというものはクラッシュするものである。まぁだいたいコケてほしくないところでコケる。

このコケる場所がアプリに埋め込まれているとこのリスクは増大する。これに対する解答は、アプリのコア部分と、機能を分離することである。こうして分離しておくことで、たとえクラッシュに見舞われてもアプリ全体がコケるということがないように設計することができる。

 

Priviledge Separation

近年アプリはweb pageやメールで送られてきたデータやら、信用ならないデータに頼ることがますます増えてきている。

昔のアプリではバッファオーバーフローなどの脆弱性からアタッカーはユーザー権をのっとることができる。

このリスクを軽減するため、OSXはSandboxを提供している。

Sandbox環境内では、権限を分離することで、アプリの権限を細かく分け、セキュリティを上げることができる。これにより、アプリ全体で適応するよりも各パーツでより厳密なSandboxの適応をさせることができる。

 

アプリケーションを分割する他のメカニズム--NSTaskやposix_spawn(2)--ではそれぞれにSandboxを設定することはできず、権限分離を実装することはできない。XPCサービスは、メインアプリからSandboxの設定を継承したり、もしくは独自で設定することができる。

Understanding the Structure and Behavior

XPCサービスはオンデマンドでそれらをラウンチしたり、クラッシュ時にSIGKILLでターミネイトしたりするlaunchdにより管理される。これはサービスを利用しているアプリに対してサービスがメッセージ処理中にクラッシュした場合をのぞいて、透過性がある。このケースではXPCサービスはlaunchdにより再起動される。XPCサービスはいつでも急停止することができることにより、理想的にはサービスは最小限の機能で設計すべきであり、不可能にしても、できるだけ完全にステートレスであるべきである。

 

一般的に、XPCサービスはsandboxにより最小ファイルシステムアクセスやネットワークアクセスなどできる限り限定された環境で走らせる。また、サービスの権限はrootに設定することはできない。XPCはプライベートであり、メインアプリに含まれている場合にのみ実行可能である。

Choosing an XPC API

 OSX v10.8 でXPCの実装を始めるにおいて、XPCサービスAPIs とNSXPCConnection APIの2種類の異なるAPIが存在する。

NSXPCConnection APIはリモートプロシージャコールを提供するObjective-CベースAPIである。

XPCサービスAPIはサービスヘルパーとクライアントアプリ間での基本的なメッセージサービスを提供するものである。

XPCサービスAPIはOSX10.7との互換性を保ちたい場合やアプリがFoundation frameworkを基板にしていない時に推奨される。

NSXPCConnection APIはアプリがOSX 10.8以降向けでFoundation frameworkを採用している時に推奨されている。

 

まぁ、簡単な仕組みと2系統あるAPI群の使い所