macOSのPrivacy & Security設定を信用できない理由

 (eclecticlight.co)
1 ポイント 投稿者 GN⁺ 19 일 전 | 1件のコメント | WhatsAppで共有
  • macOSのPrivacy & Security設定が実際のアクセス権限の状態を反映できていない問題が確認された
  • Documentsフォルダへのアクセスがブロックされた状態でも、Insentアプリが依然としてファイルを読み取れる現象が発生
  • ユーザーがフォルダを直接選択すると、TCCシステムがそれを意図的なアクセスと見なして制約を解除する
  • 設定画面ではブロックされたように表示されるが、実際にはサンドボックス制約が解除されてアクセスが継続して許可される
  • アクセス権限を完全に遮断するにはターミナルコマンドと再起動が必要であり、これはユーザーの制御権喪失につながるおそれがある

macOS Privacy & Security設定の信頼性の問題

  • macOS Privacy & Security設定が実際のアクセス権限の状態を正確に反映しない事例が確認された
    • Insentというシンプルなアプリを使って、Documentsフォルダのアクセス権限が設定上はブロックされていても実際にはアクセス可能になる現象が発生
    • この問題はmacOS 13.5以降のバージョンでも同様に再現可能

  • Insentアプリの動作方式

    • Open by consentボタンは、ユーザーの同意を経てDocumentsフォルダ内の任意のテキストファイルを開いて表示する
    • Open from folderボタンは、ユーザーがフォルダを直接選択すると、その中のファイルを開いて表示する
    • 後者の場合、ユーザーの意図(intent) がアクセス許可と見なされ、TCC(Transparency, Consent, and Control) システムが別途の同意なしにアクセスを許可する

  • 実験手順と結果

    • Documentsへのアクセスを許可した後、Insentが正常にファイルを読み取ることを確認
    • その後、Privacy & Security設定でInsentのDocumentsアクセスを無効化するとアクセスがブロックされる
    • しかし、Open from folderでDocumentsを選択すると再びアクセス可能になり、その後はOpen by consentも制限なく動作する
    • 設定画面では依然としてアクセスがブロックされたように表示されるが、実際にはInsentがDocumentsフォルダへ引き続きアクセス可能
    • アクセスを完全に遮断するには、tccutil reset All co.eclecticlight.Insentコマンドを実行し、Macを再起動する必要がある

  • 内部動作の分析

    • Insentは通常の公証(notarized) アプリであり、サンドボックスや特殊権限は使用していない
    • System Integrity Protection(SIP) が有効な状態では、一部の処理がサンドボックス化される
    • sandboxdがファイルアクセス要求を横取りしてTCCに承認を求め、ユーザーが同意するとアクセスが許可される
    • アクセスが無効化された後はTCCがアクセスを拒否するが、ユーザーがOpen/Saveパネルを通じてフォルダを選択すると、sandboxdがそれ以上要求を横取りしない
    • その結果、TCCがアクセスを制御できなくなり、サンドボックス制約が解除された状態でフォルダアクセスが可能になる

  • 問題の原因

    • ユーザーの意図に基づくアクセスが発生すると、そのフォルダに対するサンドボックス制約が取り除かれる
    • この変更はPrivacy & Security設定UIに反映されないため、設定上はブロックされたように見えても実際にはアクセスが許可された状態が維持される
    • 他の保護フォルダ（例: Desktop、Downloads）は正常に動作し、問題はフォルダごとに独立して発生する

  • 結論

    • Files & Folders項目のアクセス制限表示は実際の適用状態を信用できない

      • アプリが一覧に表示されない、またはブロックされたように見えても、実際には保護フォルダにアクセスできる場合がある
      • いったんアクセス権限が付与されると、ターミナルコマンドと再起動なしには解除されず、ユーザーがアクセス制御を失うおそれがある

  • 追加議論（コメント要約）

    • 実験後、Documentsフォルダにcom.apple.macl拡張属性が追加され、Insentのアクセスを許可する役割を持つと推定される
    • tccutil resetコマンドはデータベースのmacl項目を削除するが、xattr（拡張属性） は残るため、アクセスが維持される可能性がある
    • SIPが有効な状態ではこの属性を削除しにくく、復旧モードでxattr -d com.apple.macl path/to/Documentsコマンドを使った場合にのみ削除可能
    • このためユーザーは、アプリの実際のアクセス状態を確認または制御しにくい状況に置かれる

関連記事

1件のコメント

 
GN⁺ 19 일 전
Hacker Newsの意見

  • 自分には単純な問題に見える。アプリにフォルダへのアクセス権を与えれば、そのフォルダ内のファイルにもアクセスできるのは当然だと予想していた

    • 文書をよく読む必要がある。Files & Folders設定は実際の権限状態を正確に反映していない。UIではブロックされているように見えても、アプリは依然としてDocumentsフォルダに無制限にアクセスできる
    • 核心は「権限を付与してからUIで解除したのに、なおアクセス可能」という点だ
    • 記事の冒頭でも「セキュリティ設定がアプリの実際のアクセス状態を誤って表示する可能性がある」と明記されている
    • macOSがすでにUIに紐づいたフォルダを認識し、バックエンドで連携してくれるものと期待していたが、単なるパス例外として処理されるためUIが無効化される問題だ。こういうのはフィードバックレポートとして提出したはず。筆者はGatekeeperやTCC関連の問題をよく扱う人なので共感できる
    • 記事があまりに曖昧に書かれている。権限解除後にも残るメカニズムが何なのか説明不足だ

  • 記事を読んだ後、すべてのフォルダ権限を解除してテストしたが、InsentがUIで「None」と表示されていてもDocumentsを読めた。透明性の失敗に見える

    • アプリはそもそもデフォルトでユーザーのホームフォルダにアクセスできるのでは、という疑問が湧く

  • GUI中心OSの皮肉だ。Documentsフォルダへのアクセスを完全に遮断するには、ターミナルで
    tccutil reset All co.eclecticlight.Insent
    コマンドを実行して再起動しなければならない

    • Jobsも墓場で寝返りを打つレベルだ。NeXT時代にもこういうGUIとCLIの衝突は多かったらしい
    • GUIまわりの奇妙な現象もある。Wi‑Fiをオフにした状態で終了したのに、起動後のログイン時にWi‑Fiアイコンが一瞬有効になったように見えてから無効表示に戻る。単なるUIバグなのか、実際に一瞬オンになっているのか分からない

  • タイトルは「macOSアプリは、ユーザーが解除してもフォルダアクセスを維持する」くらいに変えるのが正確だ

    • ただ実際には、ユーザーが特定のアクセスを解除したのではなく、一般的なフォルダアクセスを解除しただけだ。詳細なアクセスを個別に解除する方法がない

  • MacのsandboxシステムはWindows UACを思い出させる。ユーザーの疲労感を増すだけの構造だ。
    *nixの選択的コンテナ方式のほうがずっと良いと思う。
    Terminalで実行されたバックグラウンドプロセスが、親プロセスが死んでも権限を維持するのは特に奇妙だ。権限体系全体が形式的に見える

    • Appleは昔の広告を見直すべきだ (YouTubeリンク)
    • 参考までに、UACはセキュリティ境界ではない。したがってUAC-bypassは権限昇格の脆弱性として扱われない
    • より大きな問題は、いまだに多くの開発者が「すべてのものがすべてにアクセスできる」という古いパラダイムに留まっていることだ。macOSのUXが完璧ではないとしても、無制限アクセスがデフォルトである方がさらに危険だ
    • しかもAppleは自社アプリには例外を設けている。ユーザー体験を損なわないためだ
    • これはMacのsandboxではなくTCCシステムだ。App Sandboxを使うアプリはDocumentsアクセスのプロンプトすら表示できない。その代わり、Security Scoped Bookmarkという方式でアクセスを維持できる (参考リンク)

  • tccutil reset 以外にも、セキュリティ設定で権限をオンにしてからオフにする方法でも初期化できる。
    UIがバグで状態を誤表示しているだけで、実際の権限は正常に機能している。
    チェックボックスの色もフォーカスの有無で変わるので紛らわしい。Sequoiaバージョンでもまだ残っている。
    外付けドライブにインストールされたゲームが「removable volumes」へのアクセスを要求して一覧に大量に出てくるのも興味深い

  • これがバグなのか、セキュリティ脆弱性なのか、単なるミスなのか判断に迷う。すべてのアプリに対してresetコマンドを実行したほうがよいのか悩む

    • 単なるUI上の欠落だ。内部システムは正常に動作している
    • こういうものはセキュリティUIバグに分類される。ユーザーが権限状態を認識できなくなるので、CVE対象になり得る
    • Appleの形式的なセキュリティ手続きと、実際のファイルアクセス構造が衝突した事例だ。設定で権限状態を明確に表示し、解除後の再付与を難しくすべきだ。そしてアプリ再起動を要求する権限は、もういい加減なくすべきだ

  • 最新のmacOSでも似たようなセキュリティUIの混乱がある。
    「Full Disk Access」項目では、一部のアプリがグレー表示されるが、オンとオフの区別がつかない。
    これがバグなのか、実際に権限があるのか分からない

    • Appleの説明は曖昧だ。「Files & Folders」の一覧は単に権限要求の履歴を表示しているだけだ。
      Full Disk Accessをオフにしても、一部の機微なフォルダだけが保護され、一般フォルダ（Desktop、Documentsなど）には依然としてアクセス可能だ (Apple文書)

  • 問題の原因は、Documentsフォルダに設定されたcom.apple.macl拡張属性にある。SIPのため削除できない

    • これはバグではなく、2つのセキュリティシステム間のUI不一致だ。実際の保護は機能しているが、UIがそれを表現できていない

  • iOSでも同じ現象があるのか気になる

    • iOSではアプリがファイル選択ツールや自分のフォルダの外部にアクセスできないため、同じ問題は発生しない