ハクソク

世界を動かす技術を、日本語で。

macOSのプライバシーとセキュリティ設定は信頼できない

30日前原文(eclecticlight.co)

概要

  • macOSのPrivacy & Security設定 は、アプリのフォルダアクセス状況を正確に反映しない場合がある現象のデモ解説
  • Insentアプリ を使い、実際のアクセス制御の裏側を検証
  • ユーザーの明示的な操作 によって、設定上はブロックされていてもアクセスが可能になるケース
  • 設定画面の表示と実際のアクセス制御の 不一致 を指摘
  • アクセス権のリセットには 特殊なコマンドと再起動 が必要

macOSのPrivacy & Security設定の“魔法”の裏側

  • macOS 13.5以降 で、Privacy & Security設定の Files & Folders 表示と実際のアクセス権限の不一致現象
  • Insent というシンプルなアプリを用いたデモンストレーション
  • Open by consent ボタン：ユーザーの同意を求めてDocumentsフォルダ内のテキストファイルを表示
  • Open from folder ボタン：ユーザーがフォルダを選択し、その意図によって同意なしでファイル表示
  • TCC（Transparency, Consent, and Control）によるアクセス制御の挙動検証

デモ手順と現象

  • Insentをダウンロード・インストール後、 Open by consent でDocumentsアクセスを許可
  • 設定画面で Documentsアクセスが許可されていること を確認
  • 一度許可すると、再度の同意なしでアクセス可能
  • 設定画面でDocumentsアクセスを 無効化
  • Open by consentでアクセス不可となるが、 Open from folder でDocumentsを選択すると再びアクセス可能
  • その後、 設定画面では依然としてアクセス不可表示 なのに、実際はアクセス継続
  • 唯一のリセット方法 は、ターミナルでtccutil reset All co.eclecticlight.Insentを実行し、Macを再起動すること

技術的な詳細

  • Insentは 通常のノータライズ済みアプリ、特別なトリックは不使用
  • SIP（System Integrity Protection）有効時は一部操作がサンドボックス化
  • Open by consent ではサンドボックスがTCCへアクセス要求を中継し、ユーザー同意が必要
  • Open from folder でユーザーがフォルダを選択した場合、サンドボックスの制約が解除される
  • この解除は 設定画面に反映されず、TCCのFiles & Folders表示は実際の権限を示さない

問題点と考察

  • 設定画面の表示は信頼できない ため、実際にはアプリが制限なくフォルダへアクセス可能な場合がある
  • 多くのアプリは初期化時にアクセス権を取得しようとするが、ユーザー操作による“意図”で制御が上書きされる可能性
  • アクセス権の解除が困難 で、ユーザーが容易に管理・防御できない点が問題
  • この挙動は意図的というより設計上の抜け穴であり、ユーザーのコントロールを損なうリスク

結論：macOSのプライバシー設定の落とし穴

  • Files & Foldersの表示は実際のアクセス制御と一致しない 場合がある
  • アプリがユーザー操作を経由して 恒久的に保護フォルダへアクセス可能 となる現象
  • アクセス権の完全なリセットにはコマンド操作と再起動が必須
  • セキュリティ運用上、 設定画面だけに頼らず管理する必要性

Hackerたちの意見

Macのサンドボックスシステムの問題は、WindowsのUACを思い出させるところだよ。小さな問題に対する解決策を作り出してるけど、結局ユーザーに許可疲れを与えてる気がする。個人的には、伝統的な*nixモデルがかなり良い働きをしてきたと思うし、コンテナを使った選択的なサンドボックス（Dockerみたいな）はかなりいいと思う。Macのサンドボックスモデルは普通のユーザーには大丈夫かもしれないけど、パワーユーザーには時々イライラすることがある。Macを何度も再起動したり、いろんなプロセスを立ち上げたり（そして、スコープが足りないことに気づいたらまた再起動）。Macが全ユーザーをサンドボックスシステムに強制してるのは、macOSをアップグレードしてからの一番嫌な影響の一つだと思う。macOSがどんどん使いにくくなってる。最もクレイジーなのは、Terminal/iTermから始まったバックグラウンドプロセス（tmuxなど）が、TerminalやiTermがもう動いていなくても、その昇格されたステータスを引き継いでしまうこと。だから、親プロセスや祖父プロセスが動いていないのに、昇格されたプロセスがたくさんあるってことになる。全体の権限の仕組みが、実際に役立つというよりもパフォーマンス的なものに感じる。

└

Appleの誰かは昔の広告を見た方がいいよ。 https://www.youtube.com/watch?v=8CwoluNRSSc

└

macOSではほとんどコンテナを使える気がする。*nixではコンテナを使う感覚が違うのかな？それともmacOS特有のソフトウェアの罠を指してるの？任意のコードを段階的に権限を上げながら実行できるようにしたいな。（例えば、iOS/androidのようにもっと柔軟性があって逃げ道がある感じ。macOSもそこに近づいてるけど、かなりでこぼこした道のりだね）。今はランダムなGitHubリポジトリをダウンロードしたら、Dockerコンテナに入れてポートやボリュームを設定する感じ。

└

最悪のケースの一つは、新しいMacにログインした直後や、アップグレードした後に起こるよね。インストールされてるアプリからの権限リクエストの嵐にすぐに襲われる。初めてのユーザー体験としては最悪で、Appleの誰かがこれを承認したのが信じられない。昔は広告でWindowsをバカにしてたけど、UACは俺の経験ではこんなにひどくなかったよ。

└

それに、Appleは自社のアプリにはたくさんの権限を免除してるんだよね（顧客にとって受け入れられないユーザー体験になるから）。

└

これは「Macのサンドボックスシステム」じゃなくて、TCCなんだ。これは重要な違いで、適切なApp Sandboxにオプトインしたアプリはこれをできないからね…Documents/への直接アクセスのためのプロンプトを表示することすらできない。App Sandboxでは、ファイルピッカーを使ってファイルを開くたびにサンドボックス拡張が発行される。これらはアプリが再起動されるまでしか持続しない。注意点として、「Security Scoped bookmarks」（基本的に署名されたbase64の塊 [1]）を保存して、アクセスを保持するためにそれを渡すことはできるけど、あまり一般的ではない。 [1] https://www.mothersruin.com/software/Archaeology/reverse/boo...

└

TCCは別のものだよ。サンドボックスアプリは違う動作をするから、TCCのダイアログは必要ないんだ。

└

Macの権限（LinuxやWindowsも）については逆の感覚だな。ほとんど何も聞いてこないし、すべてがすべてにアクセスできるみたい。でも結論は同じで、信頼できないものには明示的にサンドボックスをかけたい。

└

確かにパフォーマティブだね。ファイルとフォルダはブロックされてるって言ってる。オープンパネルのアクセスはまだ機能してる。パネルは一つのパスしか知らないみたい。

└

もっと大きな問題は、まだ「何でもいつでもすべてにアクセスできる」という非常に古い考え方にこだわっている開発者が多すぎることだと思う。このモデルは、特に独自のソフトウェアを使っている人にとっては、何度も機能しないことが証明されているのにね。macOSの権限管理がユーザーにプロンプトを出す方法は、もしかしたら間違ったUXかもしれないけど、デフォルトで全てのプログラムに自由にアクセスを許可するのも絶対に解決策じゃない。特に、何千人もの人が使うソフトウェアを開発・公開している私たちにとっては危険だよ。私たちは魅力的な標的で、便利さの名のもとに保護を無効にして、無制限にアクセスできるランダムなサードパーティのソフトウェアを軽率に実行することは、火遊びしているようなもの。セキュリティを確保することに対するソフトウェアエンジニアの軽薄な態度には、いつも驚かされる。自分たちが賢すぎて被害者になることはないと思っているのは、完全に間違っているよ。

もしかして俺がバカなのかもしれないけど、ここでのポイントは「アプリにフォルダへのアクセスを許可したら、そのフォルダ内のファイルにもアクセスできる」ってことだよね？それが普通だと思うんだけど？

└

もっと注意深く読んだ方がいいよ。特に： “8. InsentのDocumentsアクセスがFiles & Foldersでまだ無効になっていることを確認してください。” “9. 今何をしても、アプリはDocumentsへの完全なアクセスを保持します。Files & Foldersで表示されていることや設定されていることに関わらず。” […] “プライバシーとセキュリティ設定に表示されるアクセス制限、特にFiles & Folders内の保護された場所への制限は、実際に適用されているものを正確に反映しているわけではありません。アプリがFiles & Foldersでアクセスをブロックされていると表示されていても、1つ以上の保護されたフォルダに無制限にアクセスできることもありますし、そのリストに全くエントリーがないこともあります。”

└

ポイントは「許可を与えたけど、UIで許可を取り消したのに、まだ許可がある」ってことだね。

└

TFAのイントロ（強調は俺の）：> 今週の金曜日のマジックデモでは、プライバシーとセキュリティ設定で見えることが誤解を招くことがあることを示すよ。アプリが保護されたフォルダにアクセスできないと言っても、実際にはアクセスできることがあるんだ。

└

ほんとにひどい文章だね。全部読んでも、取り消された権限がどうして残ってるのか全然わからない。そこが一番興味深いところなのに。

└

macOSが「すでにUIが関連付けられたフォルダを選択した」って認識して、バックエンドでUIを通じて処理してくれればいいのに。単純なパス例外を作ってUIが機能しなくなるのはおかしいよね。フィードバック報告を出すだけだったけど、ここでの歴史的文脈からすると、そういう怒りのフレーミングは普通なんだ。彼らはGatekeeperやTCCの問題について広範に投稿してて、他の人よりもずっと頻繁に遭遇してるみたいだし、デバッグをサポートするためのいろんなツール（今日のも含めて）をリリースしてるから、確かに共感するよ！

驚きの発見だね。記事を読んでから、すべてのフォルダの権限を取り消してテストしたら、UIが「なし」と表示してもInsentはDocumentsをまだ読み取ってる。これは深刻な信頼の失敗だよ；透明性がその設定パネルの本来の目的のはずなのに。

└

ユーザーアカウントで動いてるアプリは、デフォルトでユーザーのホームフォルダにアクセスできるんじゃないの？

これがGUI優先のOSの魅力だよね！ > "InsentによるDocumentsフォルダへのアクセスを防ぐ唯一の方法は、ターミナルで次のコマンドを実行することです：tccutil reset All co.eclecticlight.Insent その後、Macを再起動してください。"

└

GUIの奇妙さについて言えば、比較的新しいMacBookが、Wi-Fiを無効にした状態でシャットダウンした後、起動時にログインするとWi-FiアイコンがWi-Fiスキャンモードを表示するのを見たことがある。まるでWi-Fiが有効になってネットワークを探しているかのように。その後、Wi-Fi無効の表示アイコンに戻るんだけど。これはGUIのバグなのか、それとも起動時にWi-Fi無効設定が一瞬オーバーライドされてるのか？詳しく調べてないけど、後者だとしたらかなり心配だね。

└

ジョブズが墓の中で転がってるよ。NeXTやMac OS Xでのこの対立に関する話はたくさんあって、GUIを使わないで簡単に修正できることが、彼を激怒させた要因の一つだったんだ。

最新のmacOSにも「セキュリティUI」の問題があって、少なくとも数バージョン前からあるんだ。「プライバシーとセキュリティ」に行って、「フルディスクアクセス」を見ると、いくつかのアプリ（Anki、Fission、Microsoft Autoupdate、WhatsApp）が勝手に追加されてる。トグルは無効になってて、私は一度も有効にしたことがない。まあ、どうでもいいけど。でも「ファイルとフォルダ」に行くと、そのアプリの下に「フルディスクアクセス」がグレーで表示されてる。フルディスクアクセスが有効になってるアプリは同じ見た目で、「フルディスクアクセス」がグレーになってる。これ、どう解釈すればいいの？バグなの？フルディスクアクセスがあるの？UIはそのアプリがフルディスクのトグルだけで制御されていて、デスクトップやドキュメントの細かい権限を要求できないって意味？それとも、要求できるけどまだしてないの？もしかして、要求したけど、私はそれを見れないだけ？誰がわかるんだ？

このアクセスを元に戻すための難解なターミナルコマンドは何？

これはバグなのか、セキュリティの脆弱性なのか、それとも単なる見落としなのか、はっきりしないな。予防策として、すべてのアプリに対してそのリセットコマンドを実行するのはいいアイデアかな？

タイトルは「macOSアプリがユーザーによってアクセスが削除された後もフォルダへのアクセスを保持する」みたいな感じにすべきだね。

└

いや、ユーザーは自分が与えたアクセスを取り消しているわけじゃない。フォルダへの一般的なアクセスを取り消しているけど、特定のアクセスを取り消す方法がないから、何も起こらないんだ。

これがアップルが昨日アップデートを推進した理由なのかな？

いくつかのテストをした後のメモ: 1) これはすごいmacOSのバグだ！ 2) 記事にあった「tccutil reset All co.eclecticlight.Insentをやって再起動」という提案は、私には実際には効果がなかった。でも、最初にプライバシーとセキュリティのシステム設定からInsentのリストを削除したのが、何か影響したかもしれない？ 3) SIPを無効にした別のボリュームからTahoeボリューム全体をプレーンテキストで検索しても、この永続的なアクセスがどこに保存されているかはわからなかった。標準のTCC.dbファイルには絶対にない。もしかしたら、どこかで権限が暗号化されているのかな？ 4) 記事のコメントでは、com.apple.maclの拡張属性が原因だと言われていたけど、そうじゃない。すべてのmacl属性を削除しても変わらない。 5) アクセスは特定のファイルではなく、Documentsフォルダ全体に対して行われているようだ。フォルダ内に複数のファイルがあると、Insentアプリは時々一つのファイルの内容を表示し、時々別のファイルの内容を表示することがある。

└

私にはバグには見えないな。単にUIが悪いだけだ。二つの異なるセキュリティシステムが両方とも正常に機能しているけど、保護を示すUIがあるのは一つだけなんだ。