macOSへの移行に関するブログ投稿シリーズの続きとして、macOSのAppサンドボックスについて少しお話ししたいと思います。
まずmacOS App structureのブログ投稿を読むことを強くお勧めします。読者がAppとプロセス（タスク）の違いを理解し、launchdとApp起動の関係について少し知っていることを前提とします。
初めてmacOSサンドボックスについて学んだとき、私は単純に悪意のあるWordマクロを作成しようとしました。
これは（今でも）Windowsエコシステムでは非常に一般的な侵入ベクトルなので、プロセスを起動して好き放題に大混乱を引き起こせるかどうかを確認してみたかったのです。
しかし、macOSではそう簡単にはいきませんでした。例えば、プロセスを実行することはできましたが、それらは大したことはできなかったようです。
ファイルをドロップすると、いつも不可解なOperation not permittedエラーが発生しました。一体何が起きているのでしょうか？
macOSとWordについて少し調べていたところ、Adam Chester（MDSec勤務）によるこの優れたブログ投稿に出会いました。このブログ投稿を読むことを強くお勧めしますが、ここでは調査結果を要約します：
sandbox-execという実用的なユーティリティがありました。非推奨ではありますが、多くのことを明らかにしてくれました。そのマニュアルページを見るとprofileを受け取ることがわかるので、サンドボックスルールはプロファイルで管理されていると結論付けられます。これらのプロファイルは、ファイル、定義済みの名前、あるいはリテラル文字列など、さまざまな形態をとります。/Application/Microsoft Word.app/Contents/MacOS/Microsoft Wordの下にあることがわかりました（これが奇妙に思えたら、私のmacOS App Structureブログ投稿をチェックしてみてください）。codesign：```jbo@McJbo ~ % codesign -dv --entitlements - /Applications/Microsoft\ Word.app/Contents/MacOS/Microsoft\ Word
Executable=/Applications/Microsoft Word.app/Contents/MacOS/Microsoft Word
Identifier=com.microsoft.Word
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=351454 flags=0x10000(runtime) hashes=10972+7 location=embedded
Signature size=8980
Timestamp=Apr 10, 2023 at 8:09:50 AM
Info.plist entries=52
TeamIdentifier=UBF8T346G9
Runtime Version=13.1.0
Sealed Resources version=2 rules=13 files=28766
Internal requirements count=1 size=180
[Dict]
[Key] com.apple.application-identifier
[Value]
[String] UBF8T346G9.com.microsoft.Word
[Key] com.apple.developer.aps-environment
[Value]
[String] production
[Key] com.apple.developer.team-identifier
[Value]
[String] UBF8T346G9
[Key] com.apple.security.app-sandbox
[Value]
[Bool] true
...
[Key] com.apple.security.temporary-exception.files.absolute-path.read-only
[Value]
[Array]
[String] /Library/Preferences/com.microsoft.office.licensingV2.plist
[String] /Library/Application Support/Microsoft/
...
[Key] com.apple.security.temporary-exception.sbpl
[Value]
[Array]
[String] (allow file-read* file-write* (require-all (vnode-type REGULAR-FILE) (regex #"(^|/)~\$[^/]+$")) )
[String] (deny file-write* (subpath (string-append (param "_HOME") "/Library/Application Scripts")) (subpath (string-append (param "_HOME") "/Library/LaunchAgents")) )
[Key] com.apple.security.temporary-exception.shared-preference.read-only
[Value]
[Array]
[String] com.ThomsonResearchSoft.EndNote
...
これは解読すべき情報が多いので、大まかなポイントを見ていきましょう：
-dvフラグを使用しました。これはdisplayとverboseを表します。次に、--entitlementsはAppまたはバイナリに関連付けられたエンタイトルメントを表示します（そうです、codesignは両方に対して動作します）。エンタイトルメントについては別のブログ投稿で詳しく説明しますが、今はそれらがAppの機能を反映していると考えてください。そのうちの1つは、Appがサンドボックス化されていることを示しています（com.apple.security.app-sandboxがブール値のTrueを持っています）。plistについて（また[macOS App Structureブログ投稿]で）熱く語っていたのを覚えている方は、このキーと値の辞書が何らかのプロパティリストの表現であると推測するでしょうが、その通りです。com.apple.security.temporary-exception.files.absolute-path.read-onlyは、Appが読み取りを許可されている絶対パスの配列を示しています。com.apple.security.temporary-exception.sbplの下にある（悪）名高い正規表現もここにあります。これは、Wordがとても好む例の悪名高い~$whatever.docx一時ファイルを作成するためのものです。先ほど言及した2018年のMDSecのブログ投稿では、com.apple.security.temporary-exception.sbplの下にあるdeny file-write*の部分が存在しなかったため、マクロは/Library/LaunchAgents/~$evil.plistのような任意の内容のファイルを作成できました。なぜこれがサンドボックスをエスケープするのでしょうか？
LaunchAgentsとLaunchDaemonsは、macOSではよく知られた（正規の）永続化メカニズムです。以前にも言及しましたが、Windowsの世界から来た方ならサービスとして考えるとよいでしょう。LaunchDaemonsはOSの起動時に開始され（そのためユーザーセッションの外部で動作します）、一方LaunchAgentsはユーザーのログイン時に開始されます。
興味深いことに、どちらも単純なplistファイルで記述されています。私のOneDriveアップデーターの例を以下に示します：
jbo@McJbo ~ % plutil -p /Library/LaunchAgents/com.microsoft.OneDriveStandaloneUpdater.plist
{
"Label" => "com.microsoft.OneDriveStandaloneUpdater"
"Program" => "/Applications/OneDrive.app/Contents/StandaloneUpdater.app/Contents/MacOS/OneDriveStandaloneUpdater"
"ProgramArguments" => [
]
"RunAtLoad" => 1
"StartInterval" => 86400
}
これらのLaunchAgentsとLaunchDaemonsはlaunchd（あのプロセスを覚えていますか？）によって起動されるため、サンドボックスをエスケープします。launchdは、plistがサンドボックス化されたプロセスからドロップされたかどうかを知る術がなかったからです（たとえ知っていたとしても、どのサンドボックスルールを適用すればよいのか、どうやってわかるのでしょうか？）。
launchdを使用してmacOSサンドボックスをエスケープするこの概念は広く使われており、実際、過去に私自身もそれを使用しました。
いくつかのクリックを省略すると、アイデアは次のとおりです：
launchdはmacOS Appを起動します。これらのAppはダブルクリックや他の方法で起動されることがあります。例えば、zipファイルをクリックすると、zipファイルに関連付けられているためArchive Utilityが使用されます。launchdを通じてAppを起動する別の方法は、openコマンドを使用することです。openコマンドは多機能です。Appの選択、開くファイル名の選択、完全なコマンドライン引数の指定といった興味深い機能を使用できます。Python App（新しいmacOSの標準構成デバイスにはもう存在しません）を使用して、stdin引数付きでPythonを起動しました。これは基本的に、私がドロップしたファイル（Wordの制約により~$evil.pyというファイルでした）から標準入力をリダイレクトするものです。launchdがサンドボックス化されていないPython Appインスタンスを実行し、任意のPythonコマンドを含む~$evil.pyから読み取りを開始したため、実質的にサンドボックスをエスケープしました。
他の開示情報にも同様のアイデアがあります（良い例がここにあります）が、アイデアは同じです。まだまだたくさんあると確信しています！
特筆すべきは、によるです。今回はアプリと環境変数の操作に焦点を当てています。ぜひ読んでみてください！MDSecが見つけた問題はOfficeに固有のものであり、より厳格なルールによって修正されました。
LaunchServices（launchdでアプリを起動するためのフレームワーク名）を悪用するものはより一般的であり、そのためAppleはそれらを修正する必要がありました。
私が気づいたことの1つは、Wordによってドロップされたファイルが、現在ではcom.apple.quarantine拡張属性付きで作成されることです。そう、私のGatekeeper入門ブログ投稿で言及したのと同じものです。
結局のところ、このquarantine属性は特定の攻撃に対する堅牢化の一種です。例えば、Terminal Appはその属性付きで作成されたシェルスクリプトの起動を拒否しました。ちなみに、これが私がPythonで--stdinオプションを使用しなければならなかった理由です。
Gergely Kalmanが指摘したように、Appleはこの種のエクスプロイトを堅牢化するためにopenバイナリにさらなるチェックを追加しました。呼び出し元のプロセスがサンドボックス化されている場合、--stdin、--args、その他のコマンドラインフラグは無視されるようです。ただし、openは単にIPCでLaunchServices（launchd内）を呼び出すだけで、そのためのAPIが便利に存在します（例：LSOpenURLsWithRole）。
私はLaunchServices自体も堅牢化されているかどうかは調査していません。もしされていないなら、同様のサンドボックスエスケープは容易に達成できると確信しています。
私たちはもう1つのmacOSテクノロジーであるサンドボックスについて簡単に議論しました。それがどれほど強力で設定可能であり、どのようにして破られるのかを見てきました。
また、いくつかの点を結び付けました。アプリがサンドボックスルールとどのように連携するか、launchdによるアプリ起動がプロセスツリーだけでなくより多くのものを壊すこと、そしてplistファイルが善にも悪にも使用され得ること（今回は永続化、すなわちLaunchAgentsとLaunchDaemonsによるもの）です。
幸いなことに、Gatekeeper入門ブログ投稿のcom.apple.quarantine拡張属性にも言及し、それがサンドボックスエスケープに対する追加の堅牢化としてどのように使用され得るかを説明しました。なかなか良いでしょう！
次のいくつかのブログ投稿では、macOSのさらなるセキュリティメカニズムを探求し、それらを破る戦略についても話すかもしれません。
お楽しみに！
Jonathan Bar Or (https://jonathanbaror.com)
Terminal