Linuxデスクトップ環境のセキュリティ調査レポート

## 更新履歴 | 日付 | 内容 | |---|---| | 2026-08-15 | 初版作成 | --- ## 1. 調査の背景と目的 2026年8月、Cloudflare のトラフィックデータをもとに「Linux デスクトップの利用が特定の平日に約22%まで急増した」とする趣旨の記事があった[^1]。この記事を出発点として、Linux デスクトップを日常的に利用する立場から、注意すべきセキュリティ対策を整理することが本レポートの目的である。本レポートは概要レベルの調査であり、個別の設定手順書ではない。設定にあたっては各ディストリビューションの公式ドキュメントおよび自環境での検証を前提とする。なお本レポートでは、確認できる**事実**、事実からの**解釈**、根拠が限定的な**推定**を区別して記述する。 > **【筆者注記】利害関係の開示** > 筆者は本稿で取り上げた組織・企業・団体・プロジェクト等との業務上の関係、出資関係、競合関係はない。 > 本稿はいかなる外部主体からの委託・資金援助も受けておらず、独立した調査・分析に基づく。 > **本記事の作成プロセス** > 本記事は、運営者とAIの協働により作成しています。作成プロセスおよび品質管理の詳細は、[[サイトポリシー#1.2 AI の利用について]]をご参照ください。 --- ## 2. 前提の確認：Linux デスクトップ利用は本当に増えているか ### 2.1 報じられた数値（事実）報道および関連報道によれば、以下の数値が示されている[^1][^52]。 | 出典 | 対象 | 数値 | |---|---|---| | StatCounter 2026年7月 | 北米デスクトップOSシェア | Linux 10.65%（前月5.52%） | | StatCounter 2026年7月 | 世界デスクトップOSシェア | Linux 7.53% | | Cloudflare Radar 2026年7月 | 北米デスクトップ | Linux 6.4%（前年同月4.1%） | | Cloudflare Radar 2026年7月6日 | 単日ピーク | 約22% | また、Cloudflare Radar のこの6.4%という値は、ボットを除外して人間のトラフィックのみを数えた場合のものである。報道の原典によれば、**ボットのみを集計対象とした場合の Linux のシェアは19%**であり、人間とボットを合算した場合のシェアは9.7%になる[^1][^52]。 ### 2.2 数値の扱いについて（解釈）これらの数値は測定方法が異なるため、単純比較はできない。StatCounter は計測タグを埋め込んだサイトのページビュー集計であり、Cloudflare Radar は同社ネットワークを通過する HTTP リクエストの集計である[^1]。「22%」は単日のピーク値であり、恒常的なシェアではない。さらに、StatCounter 側の数値には固有の留保が必要である（事実）。北米の Linux シェアは2026年6月の5.52%から7月の10.65%へ、1か月でほぼ倍増した。しかし6月のデータには「Unknown」区分が9.24%存在しており、**その減少と Linux の増加が時期的に一致している**[^52]。当該数値を最初に報じた媒体自身が、増加分の一部は検出・分類方法やサンプル構成の変化によって説明されうると明記している[^52]。加えて StatCounter のデータは公表後一定期間の修正対象であり、月次データでは7月を10.61%とする値も示されている[^53]。したがって、**「複数の独立した測定系が揃って増加を示している」と単純に述べることはできない（解釈）。** Cloudflare Radar 側の4.1%から6.4%への変化は独立した観測として妥当だが、StatCounter 側の急増には分類の不連続が含まれている可能性がある。両者を同列に扱うと、実態より強い論拠に見えてしまう。増加要因として記事が挙げているのは、Windows 10 のサポート終了に伴う移行、AI 開発環境としての適性、Steam Deck 等の Linux ベースゲーム環境の普及である[^1]。 **本レポートにおける重要な含意は、シェアの絶対値ではない。** 増加の主たる担い手が「Windows 10 からの移行者」であるならば、Linux デスクトップの利用者層に、従来のパワーユーザー中心の構成とは異なる、**Linux 固有の運用慣習に不慣れな層が相当数含まれる**ことになる。これは攻撃者から見れば、防御の薄い新規市場の出現を意味する。 --- ## 3. 脅威環境の現状 ### 3.1 「Linux だから安全」という前提の崩壊 Linux が相対的に狙われにくかった主な理由は、デスクトップ市場におけるシェアの低さであった。これは技術的優位ではなく、**経済的合理性の帰結**である。シェアが上がれば、この前提は自動的に失われる。実際、脆弱性の観測数は増加している。Action1 の2025年版レポートによれば、2024年における Linux 関連の脆弱性は前年比967%増と報告された[^2]。ただしこの数値の解釈には注意が必要である。2024年2月に Linux Kernel が CNA（CVE採番機関）として認定された[^54]。カーネル側の文書は、カーネルがシステムの中で占める層の性質上ほとんどのバグが悪用されうる一方で修正時点では悪用可能性が判然としないため、CVE 採番チームは過度に慎重となり、特定したあらゆるバグ修正に CVE 番号を割り当てると述べている[^54]。この方針により、CVE 発行数が構造的に急増している。すなわち、**967%という増加率は、実際の危険度がそれだけ増したことを意味するわけではない。** 計測対象の定義が変わったことによる増分が、相当程度含まれている。数値の解釈には慎重さが必要だが、脅威インテリジェンス側の観測も同方向を示している。Huntress は2026年の脅威展望において、Linux エンドポイントへの脅威が現実のものであり、Windows・macOS と同等のセキュリティ水準が必要だと指摘している[^3]。 ### 3.2 ソフトウェアサプライチェーン：最も現実的な脅威 Linux デスクトップにおいて、**現時点で最も現実的かつ深刻な攻撃経路はパッケージ配布経路である。** #### 事例：Arch User Repository（AUR）の侵害 2025年7月16日、AUR に `librewolf-fix-bin`、`firefox-patch-bin`、`zen-browser-patched-bin` の3パッケージがアップロードされ、これらが CHAOS RAT（リモートアクセス型トロイの木馬）をインストールすることが判明した。パッケージは2日以内に削除されている[^4]。さらに2026年6月、AUR に登録された400以上のパッケージから、認証情報やアクセストークンを標的とする Linux ルートキットおよび情報窃取型マルウェアが拡散されていたことが報告された[^5][^6]。報告によれば、攻撃者は信頼できるパブリッシャーを偽装した新規メンテナーとして活動し、侵害されたパッケージには悪性 npm パッケージをダウンロード・実行するプリインストールスクリプトが埋め込まれていた。ペイロードは root 権限がある場合に限り eBPF ルートキット機能を持つ認証情報窃取マルウェアとされ、標的はブラウザおよび Electron アプリのデータ、Slack、Microsoft Teams、Discord、GitHub、npm、Vault、Docker/Podman、SSH、VPN 関連データ、シェル履歴などである[^5]。 **この事例の構造的な意味（解釈）:** - AUR は設計上、コミュニティの相互監視に依存しており、自動的な事前検証やサンドボックスの仕組みを持たない[^4]。 - PKGBUILD は本質的に**任意のシェルスクリプト**であり、ビルド時点で任意コードが実行される。「インストール前にレビューできる」という建前は、実際にレビューする利用者がどれだけいるかという問題を抱えている。 - 400超という規模は、単発の悪ふざけではなく、**組織的かつ計画的な運用**を示唆する。なおこの数値は2026年6月の報道時点のものであり、その後さらに拡大したとする集計もあるが、本レポートでは確認できていない。標的が開発者ワークステーションに集中している点も、攻撃者の狙いが「その端末そのもの」ではなく、**そこから到達可能な組織の資産**にあることを示す。同種の構図は npm、PyPI、VS Code 拡張機能、ブラウザ拡張機能にも共通する。2024年の XZ Utils 事件（メンテナー権限そのものをソーシャルエンジニアリングで奪取した事例）と合わせて見れば、**「信頼できる配布元」の定義自体が揺らいでいる**と言える。 ### 3.3 ソーシャルエンジニアリング：ClickFix の Linux 展開 ClickFix は、偽の CAPTCHA 認証やブラウザのエラー表示を装い、利用者自身に攻撃者の用意したコマンドをコピー＆ペーストして実行させる手法である。Microsoft の Digital Defense Report 2025 は、同社の Defender Experts が観測した初期アクセス手法のうち、ClickFix が47%を占めて最多であり、従来型のフィッシング（35%）を上回ったと報告している[^7]。**この47%はマイクロソフトの特定サービスにおける観測値であり、全世界の攻撃全体に対する比率ではない点には注意を要する（解釈）。** それでも、単一の手法が初期アクセスの半数近くを占めるという事実の重みは変わらない。当初は Windows の「ファイル名を指定して実行」を対象としていたが、2025年5月には Windows と Linux の双方を狙うキャンペーンが観測された[^8]。現在の ClickFix 誘導ページは OS を自動判別し、Windows・macOS・Linux それぞれに適した命令を提示するとの報告がある[^43]。 **Linux デスクトップにとって、これは特に危険な手法である（解釈）。** 理由は文化的なものである。Linux コミュニティでは、トラブルシューティングの回答として端末コマンドを提示し、それを貼り付けて実行する慣習が定着している。`curl ... | bash` 形式のインストール手順も、公式サイトが堂々と掲載している場合がある。**「知らないコマンドを貼り付けて実行する」ことへの心理的抵抗が、構造的に低い。** 技術的な防御（署名検証、サンドボックス、MAC）は、利用者本人が自発的に実行したコマンドを止めない。ここが最大の空隙である。 ### 3.4 情報窃取型マルウェア：root 権限は不要である情報窃取型マルウェア（infostealer）の標的は、ブラウザに保存された資格情報、セッションクッキー、暗号資産ウォレット、SSH 秘密鍵、各種 API トークンである。 **ここで重要な認識（解釈）:** これらはすべて**ユーザー権限で読み取れる場所にある。** `~/.ssh/`、`~/.config/`、`~/.aws/credentials`、ブラウザプロファイル、`~/.bash_history` ——いずれも root 権限を必要としない。 Linux 利用者は「root を取られなければ大丈夫」という感覚を持ちやすいが、**攻撃者にとって root は必ずしも目的ではない。** 前節の AUR 事例で、eBPF ルートキット機能が「root 権限がある場合のオプション」と位置付けられていたことは示唆的である。認証情報の窃取という主目的は、一般ユーザー権限で十分に達成できる。セッションクッキーの窃取は、パスワード変更や多要素認証を迂回しうる。すなわち、**一度の感染が、その端末を超えて組織のクラウド資産に波及する。** ### 3.5 ローカル権限昇格：それでも root は取られる 2025年から2026年にかけて、主要ディストリビューションのデフォルト構成に影響する権限昇格の脆弱性が相次いだ。 | CVE | 対象 | 概要 | |---|---|---| | CVE-2025-6018 | PAM（openSUSE/SLES） | 一般ユーザーが `allow_active` 相当に昇格[^9] | | CVE-2025-6019 | libblockdev/udisks | `allow_active` から root へ昇格[^9] | | CVE-2025-32462 | sudo（`--host`） | 特定の sudoers 構成下で昇格[^9] | | CVE-2025-32463 | sudo（`--chroot`） | デフォルトビルドで、sudoers に登録のないユーザーでも root 取得が可能[^10] | | CVE-2026-31431 | Linux カーネル | ローカルログイン可能なユーザーによる管理者権限取得[^11] | CVE-2025-32463 は sudo 1.9.14〜1.9.17 に影響する。攻撃者が制御する chroot ツリー内の `/etc/nsswitch.conf` を通じて任意の共有ライブラリを読み込ませ、sudoers の制限を完全に迂回する[^10]。CISA の KEV カタログにも追加されている。なお本件の CVSS v3.1 評価は、CNA（MITRE）が9.3、NVD（NIST）が7.8と分かれており、NVD 自身がこの不一致をページ上で明示している[^10]。差の実体は、sudoers に登録されていないユーザーでも成立する点を「権限不要（PR:N）」と見るか「低権限が必要（PR:L）」と見るか、およびスコープ変更の有無の判断にある。**同一の脆弱性であっても、評価主体によって深刻度の数値は変わりうる（事実）。** Base Score を単独の指標として扱うことの限界が、ここに端的に現れている。 **これらに共通する構図（解釈）:** いずれも、デスクトップ環境の利便性を支える仕組み——ポリシー制御（polkit）、リムーバブルメディアの自動マウント（udisks）、権限委譲（sudo）——が攻撃面になっている。デスクトップは「使いやすさのためにサーバより多くのデーモンが動いている環境」であり、その分だけ攻撃面が広い。 ### 3.6 ネットワークサービスの意図しない露出：CUPS の事例 2024年9月に公表された CUPS の脆弱性連鎖（CVE-2024-47076、CVE-2024-47175、CVE-2024-47176、CVE-2024-47177）は、この構図の典型である[^12][^13]。 `cups-browsed` が UDP 631番ポートを `INADDR_ANY` にバインドし、認証なしで受け付ける設計であったため、細工されたパケットにより攻撃者制御下の IPP サーバへ接続させ、悪意ある PPD 指示を注入できた。印刷ジョブ実行時にコマンドが実行される[^13]。Qualys の調査では、7万5千以上の資産がインターネットに露出しており、うち4万2千以上が認証なし接続を受け付けていた[^13]。 **デスクトップ利用者にとっての教訓（解釈）:** 「印刷したいから」という理由だけで、ほとんどのデスクトップ環境には印刷サブシステムが標準で有効化されている。プリンタを持たない利用者ですら、そのデーモンを動かしている。**使っていない機能を止める**という基本が、デスクトップでは驚くほど実践されていない。 --- ## 4. デスクトップ固有のアーキテクチャ論点 ### 4.1 X11 と Wayland：これは思想の問題ではなく設計の問題 X11 の設計上、同一セッションに接続したクライアントは、他のアプリケーションのウィンドウ内容の読み取り、キー入力の傍受、入力イベントの注入が可能である[^14]。X11 はネットワーク透過性を前提に設計されており、**アプリケーション間のアクセス制御という概念がプロトコルに存在しない。** したがって、任意の X クライアントが特別な権限なしにキーロガーを実装できる。これは実装のバグではなく仕様であるため、Xorg のアップデートでは原理的に解決できない。加えて X.Org サーバ本体でも、深刻な脆弱性が繰り返し発見されている。2025年10月28日に公表されたアドバイザリでは、CVE-2025-62229（use-after-free）、CVE-2025-62230（Xkb クライアントリソース削除時の use-after-free）、CVE-2025-62231（XkbSetCompatMap における値のオーバーフロー）の3件が報告された[^15]。**このうち後者2件は X11R6 以来コードベースに存在していたものである**[^15][^44]。X11R6 の初出は1994年であり、30年以上にわたり発見されなかったことになる。 Wayland では各クライアントは自身のサーフェスとしか対話できず、他のアプリケーションのウィンドウを参照できない。スクリーンショットや画面共有は `xdg-desktop-portal` を経由し、利用者の明示的な承認を要する[^14]。 **評価（解釈）:** アプリケーション分離を前提とするならば、Wayland への移行は選択肢ではなく前提条件である。Flatpak の権限管理を扱うプロジェクトも、Flatpak が X11 向けのサンドボックス手段を提供しておらず、X11 には GUI の分離がないため、サンドボックスの試み自体が実効性を持たないとしている[^16]。Flatpak 本体の議論でも、X11 ソケットへのアクセスがサンドボックス脱出の経路になりうる点が指摘されている[^55]。ただし移行には実務上のトレードオフがある（一部のリモートデスクトップ、特殊な入力デバイス、スクリーンリーダー、自動化ツール等）。**互換性の問題が出た場合に X11 へ戻すことは、思想の敗北ではなく運用上の判断である。** ただしその場合、上記のリスクを受容したことになる点は自覚しておく必要がある。 ### 4.2 Flatpak / Snap：サンドボックスの限界 Flatpak は bubblewrap による名前空間分離とポータル経由の権限付与を提供するが、実効的な保護は**パッケージ側が宣言した静的権限**に依存する。 Flatpak 公式ドキュメントは、静的で恒久的なファイルシステムアクセスを可能な限り制限すること、`--socket=system-bus` / `--socket=session-bus` は D-Bus のフィルタリングを無効化するため開発ツール以外では避けるべきことを明記している[^17]。しかし現実には、Flathub 上のアプリケーションの多くが `filesystem=home`、`filesystem=host`、`device=all` といった広範な権限を宣言している[^16][^18]。 `filesystem=home` を持つアプリケーションは、`~/.ssh/` も `~/.aws/` もブラウザプロファイルも読める。**サンドボックス内で動作しているという事実は、情報窃取を防がない。** 対策としては Flatseal または `flatpak override` による権限の見直しが有効である[^19]。ただし、権限を絞るとアプリケーションが動作しなくなる場合があり、そこで元に戻してしまえば意味がない。**利便性と分離のトレードオフを、利用者が個別に引き受ける構造**になっている。加えて、Flatpak ランタイムはディストリビューションの更新サイクルから独立しているため、ランタイム内蔵ライブラリの脆弱性修正が遅れる場合があるとの指摘もある[^18]。 ### 4.3 強制アクセス制御（SELinux / AppArmor） Fedora/RHEL 系は SELinux、Ubuntu/Debian 系は AppArmor を標準で備える。デスクトップ用途では、これらを無効化する解説記事が今なお散見されるが、**無効化は最後の防御層を自ら外す行為である。** ANSSI の GNU/Linux 構成推奨（ANSSI-BP-028 v2.0）は、強化レベルに応じた段階的な適用を推奨している。同ガイドは Minimal / Intermediary / Enhanced / High の4段階を定義しており、原則としてすべてのシステムが Minimal を実装すべきであり、次いで Intermediary を目標とすべき旨を示している[^20]。Red Hat はこの v2.0 での変更を、Minimal の適用後に Intermediary が「強く推奨される」ようになったものと要約している[^21]。**「全部やるか、何もしないか」ではなく段階的に上げていく設計**は、実務上きわめて現実的である。 --- ## 5. 持ち出し端末の物理セキュリティノートPCに Linux を導入し、出先で使う——という利用形態を想定する。この場合、これまで論じてきたネットワーク越しの脅威に加えて、**攻撃者が端末そのものに手を触れられる**という条件が加わる。 ### 5.1 物理アクセスは、ソフトウェア的防御の前提を壊すこれまで述べてきた対策は、いずれも「OS が正しく動作していること」を暗黙の前提としている。物理アクセスは、その前提そのものを外すことができる。デバイスの物理的な確保が最も確実な防御であるという指摘は、この分野では一貫している[^24]。出先での物理的脅威は、次の4類型に整理できる。 | 類型 | 状況 | 攻撃者の目的 | |---|---|---| | 盗難・紛失 | 端末が手元に戻らない | 保存データの奪取 | | 一時的な無人放置（evil maid） | 端末は手元に戻る | 恒久的なバックドアの設置 | | 稼働中・休止中の端末への接触 | 目を離した隙 | メモリ上の鍵やセッションの奪取 | | 覗き見・撮影 | 公共空間 | 画面情報およびパスフレーズ入力の観察 | **多くの利用者が想定しているのは、このうち第1類型だけである（解釈）。** フルディスク暗号化は第1類型には有効だが、第2類型以降にはほとんど効かない。「暗号化しているから大丈夫」という認識は、脅威の4分の1しかカバーしていない。 ### 5.2 電源状態が防御力を決めるフルディスク暗号化が守るのは「電源が切れている状態」である[^22]。稼働中はマスター鍵が RAM 上に平文で存在する。したがって、**カバンに入れる瞬間の電源状態が、その端末の防御力をそのまま決める。** | 状態 | 鍵の所在 | 防御力の評価（解釈） | |---|---|---| | 電源オフ | ディスク上（暗号化済み） | 最も強い | | ハイバネート（S4） | スワップ領域に書き出される | スワップを暗号化していなければ、鍵が平文でディスクに残る | | サスペンド（S3） | RAM 上に平文 | 弱い。DMA 攻撃およびコールドブート攻撃の標的 | | 画面ロックのみ | RAM 上に平文 | ロック画面実装の不備や USB 経由の入力注入に晒される | **実務的な結論（解釈）:** 移動時は、画面を閉じる（サスペンド）のではなく**電源を落とす**。「起動が遅いから」という理由でサスペンド運用を常態化させることは、暗号化を実質的に無効化しているのに近い。ハイバネートを使う場合は、スワップ領域が暗号化されていることを必ず確認する。 ### 5.3 evil maid 攻撃：`/boot` は暗号化されていない LUKS の一般的な構成では、ブートローダおよび initramfs を含む `/boot` は暗号化されない。**パスフレーズを尋ねて復号する主体そのものが、暗号化されていない**という構造がある。このため、端末を無人で放置した攻撃者は、initramfs やブートローダを改ざんし、次回入力されたパスフレーズを記録・送出させることができる。フルディスク暗号化システムは利用者に対して自身の正当性を証明する手段を持たないため、この攻撃に対して構造的に脆弱である[^24]。攻撃の概念自体は2009年から知られているが[^25]、根本的な解決には至っていない。 **現実的な緩和策:** | 対策 | 効果と限界 | |---|---| | Secure Boot の有効化 | 署名されていないブート構成要素の起動を拒否する。可能であれば自己署名鍵を登録する | | TPM による measured boot | ブート構成の測定値（PCR）に鍵をシールし、改ざん時には鍵を解放しない[^23] | | UEFI 設定のパスワード保護 | 外部メディアからの起動やブート順序の変更を禁止する | | 物理的な封印 | 筐体ネジへの改ざん検知シール等。低コストだが、検知には有効 | | **端末を無人で放置しない** | 最も確実。ホテルの部屋も無人放置に含まれる[^24] | **注意すべき点（事実）:** TPM による自動アンロックは、ディスクを抜き取って別のマシンで読む攻撃には有効だが、**端末が通常どおり起動された場合には効かない**[^23]。したがって、持ち出し端末では TPM 単独ではなく、PIN またはパスフレーズとの併用を検討すべきである。 ### 5.4 補論：自己暗号化ドライブ（SED）という選択肢持ち出し端末が TCG Opal 2.0 等に対応した自己暗号化ドライブ（Self-Encrypting Drive, SED）を利用できるならば、SED 対応ストレージへの換装も選択肢の一つとなる。ただし、採用にあたっては利点と既知の弱点の双方を理解しておく必要がある。 **利点（事実および解釈）** | 項目 | 内容 | |---|---| | 暗号化範囲 | ドライブ全体が対象となる。ソフトウェア FDE で暗号化されずに残る `/boot` 相当の領域も、ドライブ側の暗号化対象に含めうる | | 認証の分離 | 起動前認証（PBA）はドライブ側のシャドウ MBR に置かれ、ロック解除まで OS 領域が露出しない。5.3 節で述べた「復号を担う主体が平文で置かれている」構造への一つの回答となる | | 性能 | 暗号化処理がドライブ内のコントローラで完結する。ただし AES-NI を持つ現代の CPU では、LUKS との実効差は限定的である | | 廃棄・再利用 | 鍵の破棄による即時消去（Instant Secure Erase）が可能。端末の廃棄や譲渡の場面では明確な利点である | **弱点（事実）** SED の暗号化実装はファームウェア内部にあり、利用者が検証できない。この「検証できない」という性質は、過去に現実の被害として顕在化している。 2018年、Radboud 大学の研究者らが複数ベンダーの SED を解析し、重大な実装上の欠陥を公表した。CERT/CC は VU#395981 として、SED における ATA Security および TCG Opal 実装の複数の脆弱性により、攻撃者が暗号化されたドライブの内容を復号しうると告知している[^29]。指摘された問題には、利用者のパスワードとデータ暗号化鍵（DEK）との間に暗号学的な結び付きが存在しないこと（CVE-2018-12037）、および鍵情報がウェアレベリング対象の記憶チップ上に保持されること（CVE-2018-12038）が含まれる[^30]。前者に該当する機種では、デバッグポート経由でパスワード検証処理を改変することにより、**任意のパスワードでロックを解除できた**とされる。この事案を受け、Microsoft は BitLocker がハードウェア暗号化へ処理を委譲する既定動作を見直し、ソフトウェア暗号化の使用を強制する設定を推奨するアドバイザリを発行した[^30]。 **判断の枠組み（解釈）** 以上を踏まえると、SED の採否は次のように整理できる。 - **SED は LUKS の上位互換ではない。** LUKS は実装が公開され、独立した監査が可能である。SED はそうではない。この差は、脅威モデルに国家機関級の攻撃者や高度なフォレンジック事業者が含まれる場合に効いてくる。 - **機種選定が対策の実質を決める。** FIPS 140-2/3 や Common Criteria 等の第三者認証を受けた製品か、ベンダーが上記研究への対応を明示している製品を選ぶ。認証のない安価な SED は、暗号化しているという安心感だけを提供しかねない。 - **両者は排他的ではない。** SED の上に LUKS を重ねる構成も可能である。性能上の負担と運用の複雑さは増すが、一方の実装が破られてももう一方が残る。第8章で述べる「適度な非効率」の考え方に沿った選択と言える。 - **可用性のリスクを見積もる。** ドライブ側にロックアウトや故障が生じた場合、LUKS のようにヘッダをバックアップして別環境で復旧する手立てが乏しい。**バックアップの重要性は、SED を採用した場合にむしろ高まる。** --- ### 5.5 ポートは開いた扉である：DMA と USB **DMA 攻撃**は、Thunderbolt や FireWire、一部の USB-C ポートが CPU を介さずに RAM へ直接アクセスできる仕組みを悪用する。2019年に公表された Thunderclap は、IOMMU による保護が有効な環境でも DMA 経由のアクセスが可能であることを示し、これを受けて各ベンダーが緩和策を導入した。しかし2020年の Thunderspy は修正不能とみられており、2019年以前に製造された機種（および一部の以降の機種）において、無人の端末に対し約5分で全情報へのアクセスを許すとされる[^26]。対策は、IOMMU の有効化（カーネルパラメータ `intel_iommu=on` / `amd_iommu=on`）、UEFI 設定における Thunderbolt セキュリティレベルの設定（デバイスごとの認可を要求する）、および使用しないポートの無効化である。 **BadUSB / HID 注入攻撃**は、USB デバイスがキーボードを詐称し、ログイン中の利用者の権限でコマンドを打ち込む手法である。Linux では USBGuard により、デバイス属性に基づく許可リスト方式での制御が可能である[^27][^28]。ただし USBGuard の限界は明示されている。これはデバイス単位のゲートであってキーストローク単位のフィルタではなく、**「これはキーボードである、許可する」と判断した時点で、OS はそれを人間の入力と同一に扱う**[^24]。したがって USBGuard は「決定的な攻撃者を止めるもの」ではなく「攻撃者にとっての手間を一段増やすもの」として位置付けるべきである。実務的には、画面ロック中に新規 USB デバイスを一切受け付けない設定が最も費用対効果が高い。 ### 5.6 公共空間での運用技術的対策以前の、運用上の論点を挙げる。これらはいずれも古典的だが、Linux 利用者だから免除されるものではない。 | 論点 | 具体的な対応 | |---|---| | 覗き見・撮影 | プライバシーフィルタの使用。座席は背後に人が立たない位置を選ぶ。**パスフレーズ入力時こそ最も危険である** | | 公共 Wi-Fi | 証明書警告を絶対に無視しない。DNS を信用しない。自宅への VPN や踏み台を経由する。ただし「VPN を使えば安全」ではなく、VPN は経路を移すだけである | | 充電ポート | 公共の USB 充電ポートを使わない。使う場合はデータ線を切ったケーブルまたはデータブロッカーを用いる。AC アダプタを優先する | | 短時間の離席 | トイレ・会計の間も端末を放置しない。数分あれば initramfs の書き換えも USB の接続も完了する | | 越境・出張 | 持ち出す情報を最小化する。渡航先によっては、業務データを載せない渡航専用端末を用意し、帰国後に初期化する運用が合理的な場合がある | **「出先で使う」という前提が加わった瞬間、脅威モデルは変わる（解釈）。** 自宅やオフィスで使う端末に対しては、物理アクセスは例外的な事象として扱ってよい。しかし出先の端末に対しては、**物理アクセスの機会は日常的に発生している**。カフェの席、ホテルの部屋、会議室、空港のラウンジ——いずれも、一時的に端末が自分の視界から外れる場所である。 ### 5.7 物理セキュリティ対策の整理 | 優先度 | 対策 | 主に効く脅威類型 | |---|---|---| | 必須 | LUKS2 によるフルディスク暗号化（スワップを含む） | 盗難・紛失 | | 必須 | 移動時は電源を落とす（サスペンドで運ばない） | 盗難・紛失、稼働中への接触 | | 必須 | 短時間でも端末を無人で放置しない | evil maid、稼働中への接触 | | 高 | Secure Boot の有効化、UEFI 設定のパスワード保護 | evil maid | | 高 | 画面ロックの自動化（短いタイムアウト） | 稼働中への接触 | | 中 | IOMMU 有効化、Thunderbolt のデバイス認可設定 | DMA 攻撃 | | 中 | USBGuard によるデバイス認可 | BadUSB、HID 注入 | | 中 | TPM による measured boot（PIN 併用） | evil maid | | 中 | プライバシーフィルタ、着席位置の選択 | 覗き見 | | 選択肢 | SED 対応ストレージへの換装（第三者認証のある機種を選ぶ） | 盗難・紛失、廃棄時のデータ残存 | | 状況次第 | 渡航専用端末の運用 | 越境時の検査、盗難 | --- ## 6. 開発環境としての Linux デスクトップ ### 6.1 仮説とその検証 Linux デスクトップ利用者には、ソフトウェア開発者が相当の比率で含まれているのではないか——本章はこの仮説から出発する。 **仮説を支持するデータ（事実）:** Stack Overflow の Developer Survey 2025 において、Ubuntu を業務で使用する回答者は27.7%、個人利用では27.8%であった[^45][^46]。ディストリビューション別の集計であるため、Linux 系全体の比率はさらに高い。**ただし、この調査が示すのは「開発者のうち Linux 系 OS を使う割合」であり、「Linux デスクトップ利用者のうち開発者が占める割合」を直接示すものではない（留保）。** 条件付き確率としては方向が逆であり、本仮説を厳密に裏付けるデータは確認できていない。第2章で参照した報道も、Linux デスクトップへの移行を主導しているのが労働者層であり、歴史的に PC の制御を重視する人、オープンシステムを好む人、プログラミングやシステム管理といった業務に従事する人であったと述べている[^1]。 **この事実が意味すること（解釈）:** Linux デスクトップの相当部分は、単なる「Web とメールの端末」ではなく、**コンパイラ、パッケージマネージャ、コンテナランタイム、クラウド認証情報、ソースコード、そして署名鍵を備えた開発環境**である。この差は、防御の設計を根本的に変える。 ### 6.2 開発端末は「価値の集積地」である 3.4 節で、情報窃取型マルウェアの標的がユーザー権限で読める場所にあることを述べた。開発端末では、そこに置かれているものの価値が桁違いに高い。 3.2 節で見た AUR の400超パッケージ侵害において、マルウェアが標的としていたものを改めて確認する。ブラウザおよび Electron アプリのデータ、Slack、Microsoft Teams、Discord、GitHub、npm、Vault、Docker/Podman、SSH、VPN 関連データ、シェル履歴、その他ローカルに保存された開発者の秘密情報である[^5]。**このマルウェアは開発者ワークステーションとビルド環境向けに設計されていたと報告されている**[^5]。つまり、攻撃者はすでに「Linux デスクトップ＝開発端末」という前提で設計している。 | 開発端末にあるもの | 侵害された場合の波及先 | |---|---| | SSH 秘密鍵、`~/.ssh/config` | 本番サーバ、踏み台、Git リモート | | クラウド認証情報（`~/.aws/`、`~/.config/gcloud/` 等） | クラウド基盤全体 | | CI/CD トークン、レジストリのアクセストークン | ビルドパイプライン、配布物そのもの | | コード署名鍵、GPG 鍵 | 利用者へ配布される成果物の真正性 | | `.env`、設定ファイル | データベース、外部 API | | ソースコード | 知的財産、および未公開の脆弱性情報 | **開発端末の侵害は、その端末で終わらない（解釈）。** 一般利用者の端末が侵害された場合の被害はその個人に留まりやすいが、開発端末の侵害は**成果物を通じて下流の利用者へ波及する**。3.2 節で扱ったサプライチェーン攻撃は、どこかの開発者の端末が起点になっている。**自分が被害者になるだけでなく、加害の経路になりうる**という点が、この層の本質である。 ### 6.3 IDE 拡張機能——第二のパッケージマネージャ 7.1 節で入手経路の統制を扱うが、開発者にはもう一つ、見落とされがちな入手経路がある。**IDE の拡張機能である。** 2025年から2026年にかけて、この経路を狙う攻撃が相次いだ。 | 時期 | 事案 | |---|---| | 2025年10月 | GlassWorm。OpenVSX レジストリ経由で拡散し、**不可視の Unicode 文字を用いて悪意あるロジックを拡張機能のソース内に隠蔽**。人間のレビュアーにも自動ツールにも空行に見えたと報告されている[^47] | | 2026年1月 | AI アシスタントを騙る VS Code 拡張2件が、合計約150万インストールを経て開発者のファイルを外部へ送信していたことが判明[^48] | | 2026年5月 | Nx Console 拡張が侵害され、盗まれた公開権限で悪意あるバージョンが公式マーケットプレイスへ公開された。**ワークスペースを開いただけで難読化ペイロードが実行される**構造であった[^49]。なお同拡張の総インストール数は220万超だが、悪性版が公開されていたのは短時間であり、影響を受けた数はこれより大幅に少ない | | 2025年10月〜2026年6月 | JetBrains Marketplace で、AI コーディング支援を騙る偽プラグイン15件が計約7万インストールを集め、AI プロバイダの API キーを窃取[^47] | **拡張機能は、パッケージマネージャと同等の危険度を持ちながら、その自覚が伴っていない（解釈）。** 構造を並べると明らかである。 - **レビューなしで即時公開できる。** AUR と同じ性質を持つ。 - **自動更新される。** 導入時に安全でも、更新で悪性化しうる。3.2 節のメンテナー交代と同じ構図である。 - **ワークスペースを開いただけで実行される。** 利用者の明示的な操作を必要としない。 - **IDE の権限で動く。** すなわち、開いているすべてのソースコードと、シェル実行の権限を持つ。 7.1 節の表に「拡張機能を棚卸しする」を挙げたが、開発者にとってこれは補助的な項目ではなく、**パッケージ入手経路と同格に扱うべき対象である。** ### 6.4 ビルドは任意コード実行である開発作業には、**外部から取得したコードを自分の権限で実行する工程が構造的に組み込まれている。** - `npm install` は、パッケージの lifecycle script（`preinstall`、`postinstall` 等）を自動的に実行する。 - Python のソース配布物は、インストール時に任意のコードを実行しうる。pip 公式が、ソース配布物を禁じる `--only-binary :all:` の併用を案内しているのはこのためである[^40]。 - `make`、Gradle、各種ビルドスクリプトも同様である。 - PKGBUILD については 3.2 節で述べたとおりである。 **3.3 節で述べた ClickFix と、構造的には同じである（解釈）。** どちらも「利用者が自分の意思で、外部由来のコードを自分の権限で実行する」。違いは、ClickFix が例外的な出来事であるのに対し、**ビルドは日常の作業手順に組み込まれている**点である。日常であるがゆえに、疑う契機がない。なお、サーバのハードニングでは「コンパイラやビルドツールを導入しない」ことが定石の一つとされる。**開発端末ではこの定石が使えない。** ただし、この点を過大評価すべきではない。本章で見た攻撃はいずれもコンパイラを必要としておらず、スクリプトと既製のバイナリで完結している。**問題はツールチェーンの存在そのものではなく、外部コードを日常的に実行する作業構造のほうにある。** ### 6.5 開発者自身が標的になる開発者は、無差別攻撃の巻き添えになるだけでなく、**属性を理由に狙い撃ちされる。** 代表例が Contagious Interview である。Palo Alto Networks の Unit 42 が2023年後半に公表したこのキャンペーンでは、脅威アクターが雇用者を装ってソフトウェア開発者に接触し、面接の過程でマルウェアを導入させる。Unit 42 は、北朝鮮の国家支援型脅威アクターによる運営であると中程度の確度で帰属している[^50]。手口は、LinkedIn 等で好条件の求人を提示し、コーディング課題や開発ツールの導入を求めるというものである。マルウェアとしては BeaverTail（情報窃取）と InvisibleFerret（バックドア）が観測されている[^51]。 **Linux 利用者にとって見過ごせない指摘がある（事実）。** 本キャンペーンがソフトウェア開発者を標的としているため、企業の従業員が通常使用する Windows 以外に、**macOS および Linux で実行可能な形態が用いられている**と報告されている[^51]。npm パッケージのほか、Qt や Electron で開発されたクロスプラットフォームのアプリケーションに埋め込まれた例も観測されている[^51]。 **この攻撃が厄介なのは、正常な経験の延長線上に配置されている点である（解釈）。** OSS への貢献がキャリアにつながることも、採用過程で技術課題が課されることも、渡されたリポジトリで `npm install` を実行することも、いずれも開発者にとって日常である。疑うべき理由が構造的に乏しい。 ### 6.6 開発環境に固有の対策第7章で述べる一般的な対策に加えて、開発環境では次を検討する価値がある。 | 対策 | 内容 | |---|---| | **拡張機能を入手経路として扱う** | 導入数を絞り、定期的に棚卸しする。自動更新される前提で、不要なものは残さない。公開元と評判だけでなく、**発行元アカウントの変更**にも注意する | | **未検証コードのビルドを隔離する** | 面接課題、他人のリポジトリ、初めて触る依存関係は、コンテナ・VM・devcontainer など**使い捨ての環境**で開く。ホストの認証情報が見えない状態にする | | **認証情報をファイルから外す** | SSH 鍵や署名鍵はハードウェアトークンへ格納する。クラウド認証情報は短期のものに切り替える。**ファイルにある限り、読み取られれば終わりである** | | **秘密情報の混入を検査する** | pre-commit フックや CI で、コミットに認証情報が含まれていないかを検査する | | **依存関係を固定・検証する** | ロックファイルを版管理下に置く。pip ではハッシュ検証モード、npm では `npm audit signatures` を用いる[^40][^42] | | **用途ごとに環境を分ける** | 業務・OSS・私用でアカウントや端末を分ける。7.4 節の分離を、開発では特に強く適用する | | **通信を俯瞰する** | ビルド時やエディタ起動時に予期しない外部通信が発生していないかを見る。7.0 および 7.6 節で述べた仕組みは、開発端末でこそ有効である | **優先順位について（解釈）:** 上記のうち、費用対効果が最も高いのは**未検証コードのビルドを隔離すること**だと考える。6.4 節で見たとおり、開発における侵害の多くは「ビルドまたはインストールの実行」という一点を通過する。ここに使い捨ての境界を一つ置くだけで、拡張機能・依存関係・面接課題という異なる経路の相当部分を、同時に遮ることができる。 --- ## 7. 対策の体系以下に、Linux デスクトップ利用者が講じるべき対策を整理する。まず**すべての対策に先立つ前提**を 7.0 として示し、続く 7.1 以降に個別の対策を優先順位とともに並べる。優先順位は、本レポートで確認した脅威の現実性（実際に観測されている攻撃かどうか）と、対策の実施コストの比から導いた**筆者の解釈**である。 ### 7.0 前提：己を知る孫子の「敵を知り己を知れば百戦危うからず」は、順序としては「敵を知る」が先に置かれている。しかし個人の端末防御において、実際に先立つのは**己を知る**ほうである。攻撃手法の知識をいくら仕入れても、自分の端末に何が入っていて何が動いているかを把握していなければ、その知識を適用する対象が定まらない。 **そして、これは 7.1 以降の対策と並ぶ選択肢ではなく、それらを成立させる前提である（解釈）。** - 何を入れているかを把握していなければ、7.1 の入手経路の統制はできない。統制すべき対象が分からない。 - 何が動いているかを知らなければ、7.3 の不要サービス停止はできない。何が不要かを判断できない。 - 平常時に何と通信しているかを知らなければ、7.6 の異変の検知は成立しない。**異常を異常と判定する基準線がない。** 把握すべきことは、次の3つの問いに整理できる。 | 問い | 確認手段の例 | |---|---| | **何を入れているか** | 導入済みパッケージの一覧、有効なリポジトリの一覧、Flatpak/Snap の一覧とその権限、ブラウザ・VS Code・シェルの拡張機能 | | **何が動いているか** | `systemctl list-units --type=service --state=running`、`systemctl --user list-unit-files`、`~/.config/autostart/`、シェルの rc ファイル、cron、`ss -tulpn` によるリッスンポート | | **何と通信しているか** | アプリケーション単位での通信の俯瞰（下記） | #### 通信のベースラインをどう取るか 3つ目が、Linux デスクトップにおいて最も欠けている（解釈）。`ufw` や `firewalld` は**ポートの制御**であって、「どのアプリケーションが、どこへ、いつ、どれだけ通信しているか」を俯瞰する手段ではない。この用途に使えるのが、アプリケーション単位で通信を扱うツールである。たとえば Safing の Portmaster は、Linux では nfqueue でネットワークスタックに統合してパケットを捕捉し、eBPF と `/proc` を用いて各接続の所有プロセスを特定する。設定の大半をアプリケーション単位で定義でき、接続とその詳細をローカルのデータベースに記録して後から検索できる[^31][^32]。 **まず遮断のために導入するのではなく、俯瞰のために導入する（解釈）。** 「このアプリケーションが、なぜこのドメインへ？」という問いは、可視化されて初めて成立する。ルールを書くのはその後でよい。 #### この前提が一度きりでない理由「己を知る」は、初回の棚卸しで終わるものではない。パッケージを入れれば構成は変わり、拡張機能を追加すれば通信先も変わる。**ただし、更新すべき対象が「前回把握した状態との差分」に限定されるため、二回目以降の負荷は初回より大幅に小さい。** 記録を残しておくことの価値はここにある。以降の 7.1〜7.6 は、この前提の上に立つ。 ### 7.1 第一優先：入手経路の統制 | 対策 | 内容 | |---|---| | 公式リポジトリを既定とする | 第一の入手先はディストリビューション公式リポジトリとする | | 公式以外は入手経路を検証する | ダウンロード元、アップデート元、およびそれらの GPG 鍵を検証する（下記参照） | | AUR / PPA / COPR は中身を読む | PKGBUILD 等のビルド定義を必ず読む。メンテナーの交代を確認する | | `curl \| bash` を原則禁止する | 一度ダウンロードして内容を読んでから実行する | | 拡張機能を棚卸しする | ブラウザ、VS Code、シェルプラグインを定期的に見直し、不要なものを削除する | **「入手経路を検証する」とは、具体的に何をすることか** 主要なディストリビューションおよびパッケージエコシステムは、それぞれ公式のガイダンスや要件を公開している。以下に調査結果を示す。 #### ディストリビューションのガイダンス | 配布元 | 公開されている要件・ガイダンス | |---|---| | **Debian** | サードパーティリポジトリ利用の要件を規範表現（MUST / SHOULD）で公開している[^35]。要点は、署名鍵を HTTPS 等で root のみが書き込める場所へ取得すること、`/etc/apt/trusted.gpg.d` への配置や `apt-key add` による読み込みを行わないこと、`sources.list` に `signed-by` を設定して鍵の適用範囲をそのリポジトリに限定すること | | **Ubuntu** | 公式ヘルプが PPA 追加時に警告を掲げている。すなわち、**信頼できる提供元のリポジトリのみを追加すること**、サードパーティのリポジトリは Ubuntu のメンバーによってセキュリティや信頼性を検査されておらず、有害なソフトウェアを含む可能性があること[^36] | | **Fedora** | サードパーティリポジトリの取り扱いを定めた方針を公開している。COPR を指す `.repo` ファイルを同梱する場合は `enabled=0` とし、利用者が明示的に有効化しない限り導入されない状態にすることを条件としている[^37]。また、署名検証を既定で強制する変更提案（Change）が進行しており、その中で `gpgcheck=0` を設定したリポジトリからは署名のないパッケージが導入されうることが明記されている[^38] | | **Arch Linux** | AUR は利用者が作成したコンテンツであり、**提供されるファイルの利用は自己責任である**と明示している[^39]。公式リポジトリと異なり、投稿前のレビューや署名の仕組みは存在しない。ArchWiki は、PKGBUILD・`.install` ファイル・リポジトリ内の他のファイルを慎重に確認すること、疑わしい場合はビルドしないこと、**過去に悪意あるコードが発見された実績があること**を併記している[^39] | #### 言語パッケージエコシステムのガイダンス | エコシステム | 公開されている要件・ガイダンス | |---|---| | **Python / pip** | 「Secure installs」として、`--require-hashes` によるハッシュ検証モードを文書化している[^40]。重要なのは、pip 自身が**ローカルに記述したハッシュとリモート由来のハッシュを区別している**点である。ダウンロード URL に付随するハッシュは配信破損の検出には役立つが、**リモート由来であるため改ざんへの有効な防護にはならない**と明記されている[^40]。加えて、ソース配布物の導入を禁じる `--only-binary :all:` との併用が案内されている | | **PyPI** | 署名（attestation）の意味を限定的に説明している。公式ドキュメントの要約は端的で、**「attestation は PyPI パッケージがどこから来たかを教えるが、それを信頼すべきかどうかは教えない」**とされる[^41]。attestation が保証するのはビルド後の改ざんがないことと、Trusted Publisher の変更を観測できることであり、ビルド前後に悪意あるコードが混入していないことは保証しない[^41] | | **npm** | provenance（来歴）の生成と検証を文書化しており、`npm audit signatures` によりレジストリ署名と attestation を検証できる[^42]。ここでも限界が明記されている。**provenance が確立されていても、そのパッケージに悪意あるコードが含まれていないことは保証されない**。provenance が提供するのは、ソースコードとビルド手順への検証可能なリンクであり、それを監査して信頼するか否かを判断するのは利用者側である[^42] | #### 調査から見える共通構造（解釈） 3つの点が浮かび上がる。 **第一に、どのエコシステムも「保証しているのは出所であって、中身の安全性ではない」と自ら明言している。** PyPI と npm の記述はほぼ同じ趣旨であり、署名や provenance を「安全の証明」と読み替えないよう繰り返し注意している。**署名の検証は、責任の所在を特定可能にする仕組みであって、内容を審査する仕組みではない。** **第二に、「署名の有無」と「レビューの有無」は別の軸である。** 両者を混同すると、入手経路の危険度を見誤る。 | 経路の類型 | 署名 | 事前レビュー | 例 | |---|:---:|:---:|---| | ディストリビューション公式リポジトリ | あり | あり | Debian / Ubuntu / Fedora の公式リポジトリ | | 署名付きサードパーティ | あり | なし | PPA、COPR、ベンダー提供の apt/dnf リポジトリ | | レジストリ経由 | 一部あり（provenance 等） | なし | PyPI、npm | | ビルド定義の共有 | なし | なし | AUR | | 直接実行 | なし | なし | `curl \| bash` | 3.2 節で見たインシデントは、いずれも下3段で発生している。**利用者が判断すべきは「安全かどうか」ではなく、「その経路にどの検証機構が備わっていないか」である。** **第三に、鍵の入手経路が配布元と同一であれば、信頼の起点は循環する。** 署名鍵をリポジトリと同じサーバから取得している場合、そのサーバが侵害されれば鍵も同時に差し替えられる。署名検証は形式的には成立するが、起点が攻撃者に握られている。重要な入手先については、鍵のフィンガープリントを**配布サーバとは独立した経路**で照合することが望ましい。Debian が、証明書が他の鍵によって署名されていること、可能であれば strong set に近い鍵を含めて OpenPGP の信頼の輪を活用することを推奨しているのは、この循環を断つためである[^35]。 **この層が最も重要である。** 3.2 で見たとおり、実際に観測されている大規模インシデントはここに集中している。そして、**各エコシステムが公式に「何を保証していないか」を明示している以上、その空白を埋めるのは利用者の側である。** ### 7.2 第二優先：自分自身を攻撃者の道具にしない | 対策 | 内容 | |---|---| | 意味の分からないコマンドを実行しない | 「CAPTCHA の確認のため」「エラー修正のため」の端末コマンドは、正当な手順として存在しない[^7] | | 貼り付け前に一度エディタへ通す | 端末に直接貼らない。改行が仕込まれていれば即実行される | | 認証プロンプトの出所を疑う | パスワードを求められた際、それが何の操作に対するものか説明できるか確認する | ClickFix 系の攻撃に対しては、技術的対策は限定的にしか効かない。**「知らないコマンドは実行しない」という一線を、文化的な慣習より優先させる**必要がある。 ### 7.3 第三優先：更新と攻撃面の削減 | 対策 | 内容 | |---|---| | セキュリティ更新の自動適用 | `unattended-upgrades`（Debian/Ubuntu）、`dnf-automatic`（Fedora）等 | | EOL を管理する | LTS のサポート期限を把握し、期限内に移行する。ESM 契約の要否を判断する | | Flatpak / Snap も更新対象に含める | パッケージマネージャの更新だけでは更新されない | | 不要なサービスを停止する | `systemctl list-units --type=service --state=running` で棚卸し。プリンタを使わないなら CUPS を止める[^12] | | リッスンポートを確認する | `ss -tulpn` で外部に開いているポートを把握する | | ローカルファイアウォールを有効化する | `ufw` / `firewalld` を既定拒否で運用する | ### 7.4 第四優先：分離と権限 | 対策 | 内容 | |---|---| | Wayland セッションを既定とする | 互換性上やむを得ない場合のみ X11 に戻す（4.1）[^14] | | Flatpak 権限を見直す | Flatseal または `flatpak override` で `filesystem=home` / `host`、`device=all` を絞る[^17][^19] | | SELinux / AppArmor を無効化しない | Permissive への切り替えは一時的な切り分けに限る | | 日常作業を非管理者アカウントで行う | sudo を使う瞬間を意識的な行為として残す | | 用途を分離する | 業務・開発・私用を、別ユーザー・別 VM・別端末に分ける | ### 7.5 第五優先：資産の保護と復旧 | 対策 | 内容 | |---|---| | フルディスク暗号化（LUKS2） | 盗難・紛失時の唯一の実効的対策。LUKS2 ではメモリハードな Argon2 系の鍵導出関数を選択できる[^22]。スワップ領域も対象に含める | | Secure Boot を有効化する | ブートチェーンの改ざん検知。TPM 連携時は PCR ポリシーを理解した上で使う[^23] | | SSH 秘密鍵をパスフレーズで保護する | さらに望ましいのはハードウェアトークンへの格納 | | 3-2-1 バックアップ | オフライン/イミュータブルなコピーを1つ持つ。ランサムウェアはバックアップも狙う | | 復旧手順を検証する | 復元テストをしていないバックアップは、バックアップではない | **暗号化の適用範囲について（事実）:** フルディスク暗号化は「電源が切れている状態での物理的持ち去り」に対して有効であり、稼働中の端末やマルウェア感染に対しては無力である[^22]。TPM による自動アンロックは、ディスクを抜き取られる攻撃は防ぐが、通常どおり起動された端末には効かない[^23]。**何を防ぎ、何を防がないかを分けて理解する必要がある。** 端末を持ち出す場合、この層の対策は第5章と併せて設計する必要がある。 ### 7.6 第六優先：異変を知る——検知と記録 7.0 で述べた「己を知る」が平常時の把握であるのに対し、この層は**平常時からの逸脱に気づくこと**を扱う。両者は連続しているが、性質は異なる。前者は一度やれば基準線が残るのに対し、**後者は継続的な運用を要し、運用が止まれば効果もゼロになる（解釈）。** この非対称ゆえに、本レポートではこの層を最上位ではなく第六に置いている。基本的な対策を後回しにして検知基盤だけを組んでも、防御力は上がらない。 #### 7.6.1 逸脱に気づく、そして止める本レポートで扱ってきた脅威——情報窃取型マルウェア、ClickFix で投入されたペイロード、侵害されたパッケージのプリインストールスクリプト——は、**いずれも例外なく外向き通信を必要とする。** 7.0 でベースラインを取ってあれば、この層の役割は「そこから外れたものに気づき、必要なら止める」ことに絞られる。通信を軸に据えることには、次の性質がある（解釈）。 - **攻撃手法の違いを吸収する。** 侵入経路が AUR であれ ClickFix であれブラウザ拡張であれ、C2 接続や認証情報の送出という段階では同じ形で現れる。**入口ごとに対策を用意しなくても、出口で捉えられる。** - **実行を止められなくても、被害の完成を止めうる。** 3.3 節で述べたとおり、利用者自身が実行したコマンドを技術的に阻止することは難しい。しかし、その後の通信は別である。アプリケーション単位の通信制御ツールは、フィルタリストによる既知の悪性ドメイン・トラッカーの遮断や、ドメイン・IP・国といった単位でのルール記述にも対応する[^32]。 **ufw が守るのは受信側であり、Linux デスクトップにおける現実の脅威は圧倒的に送信側にある。** この非対称は、多くの利用者に意識されていない。 #### 7.6.2 名前解決の観測と防御：Protective DNS DNS は、通信の観測において最も費用対効果の高い地点である。 NSA と CISA は共同のサイバーセキュリティ情報シート「Selecting a Protective DNS Service」において、Protective DNS（PDNS）が既知の悪性ドメインを遮断することでランサムウェア、フィッシング、ボットネット、マルウェアのキャンペーンの有効性を大きく低下させうること、および **DNS クエリログがインシデント対応と脅威ハンティングに活用できる**ことを示している[^33][^34]。PDNS の中核機能は、オープンソース・商用・政府系の脅威フィードを用いてドメイン情報を分類し、悪性と判定されたドメインへの問い合わせを遮断することである[^33]。個人の Linux デスクトップにおいても、DoH/DoT に対応したフィルタリングリゾルバの利用によって、同種の効果は得られる。Portmaster もこの機能を内包しており、システム内で「はぐれた」DNS クエリを捕捉して自身に迂回させ、設定された DoT/DoH リゾルバで解決する構成を取る[^32]。 **留意点（事実）:** NSA/CISA の同文書は、PDNS の採用にあたって評判の確かな事業者を選び、**その事業者が顧客データをどう扱うかを理解すべきである**と明記している[^33]。暗号化 DNS は経路上の第三者からクエリを隠すが、リゾルバ事業者に対しては隠さない。可視性を得る代わりに、閲覧履歴に相当する情報を一者へ集約している——このトレードオフは自覚しておく必要がある。 #### 7.6.3 記録を残す | 対策 | 内容 | |---|---| | 認証ログの監視 | `journalctl -u sshd`、`/var/log/auth.log` の定期確認 | | ファイル完全性監視 | AIDE / debsums による改ざん検知 | | auditd による監査 | 特権コマンド実行、`/etc/passwd`・`/etc/shadow`・`/etc/sudoers` への変更の記録 | | 自動起動の再確認 | 7.0 で把握した状態との差分を定期的に確認する。**永続化はここに現れる** | | ログの外部保全 | 侵害された端末上のログは信用できない。別ホストへの転送を検討する | #### 7.6.4 この層の限界検知の仕組みを導入する際は、次の3点を併せて理解しておく必要がある（解釈）。 1. **監視ツール自体が攻撃面になる。** パケット捕捉やプロセス特定は特権を要し、カーネル層に深く統合される。導入するツールの出所と更新経路は、7.1 節の基準で評価すべきである。 2. **承認疲れが起きる。** アプリケーション単位の許可を求められ続けると、人は内容を読まずに許可するようになる。既定を「拒否」に寄せ、確認を求める場面を絞る設計にしなければ、仕組みは形骸化する。 3. **root を取られた後の自己観測は信用できない。** ホスト内で完結する監視は、ホストが陥落した時点で無効になる。ログの外部転送や、ルータ側での通信観測といった**端末の外からの視点**が、最後の担保になる。 **デスクトップ Linux における構造的な弱点（解釈）:** Windows や macOS と異なり、Linux デスクトップには EDR や統合的な監視の実装が乏しい。個人利用では、事実上ほぼ何も見ていないのが実情である。**「侵害されたことに気づけない」ことが、Linux デスクトップの最大のリスクかもしれない。** ただし、いきなり完全な検知基盤を組む必要はない。**7.0 で平常時の姿を把握しておけば、この層の負荷は「差分を見る」ことに縮む。** 逆に、その前提を欠いたまま検知の仕組みだけを導入しても、出力されるものが正常なのか異常なのか判断できず、やがて見なくなる。 --- ## 8. 考察 ### 8.1 攻撃面は「使いやすさ」とともに拡大した本調査で確認した脆弱性の多くは、デスクトップの利便性を支える仕組みに存在した。udisks（自動マウント）、polkit（権限委譲）、cups-browsed（プリンタ自動検出）、D-Bus（プロセス間通信）——いずれも「利用者が設定しなくても動く」ためのものである。サーバとして最小構成で運用される Linux と、デスクトップとして使われる Linux は、**同じカーネルの上に載った別のシステム**と考えたほうがよい。サーバ運用の経験があるからデスクトップも安全に扱える、とは限らない。 ### 8.2 「適度な非効率」の観点から完全に統合された環境は攻撃者にとって効率的な標的になる。すべての資格情報が一つのブラウザプロファイルに集約され、すべての SSH 鍵が一つの `~/.ssh/` に置かれ、すべての作業が一つのユーザーアカウントで行われている端末は、一度の侵害で全損する。用途によるアカウント・VM・端末の分離、ハードウェアトークンへの鍵の外出し、バックアップの物理的隔離——これらは日常的には非効率である。しかし、その非効率こそが、突破された後に全損を防ぐ構造を作る。**各層が自工程完結の覚悟で守り、全体としては折れずに粘る**という考え方は、デスクトップ環境にもそのまま適用できる。 ### 8.3 増加が意味するもの Linux デスクトップの利用増加は、コミュニティにとって歓迎すべき出来事である。同時に、それは**攻撃者にとっての市場拡大**でもある。シェアの低さによって守られていた時代は終わりつつある。そして皮肉なことに、増加の担い手として推定される「Windows 10 からの移行者」は、Linux 固有の運用慣習——リポジトリの信頼モデル、sudo の重み、PKGBUILD が任意コードであること——を知らない層である可能性が高い（推定）。 **この状況で最も価値が高いのは、技術的なハードニングの手順書ではなく、「なぜそうするのか」を説明できる言葉であると考える。** 「AUR は使うな」ではなく「AUR の PKGBUILD は任意のシェルスクリプトであり、実行するのはあなた自身である」と説明すること。「curl | bash をするな」ではなく「その一行は、相手のサーバが返す任意のコードをあなたの権限で実行する契約である」と説明すること。技術層と経営層の間だけでなく、熟練利用者と新規利用者の間にも、翻訳者が必要である。 --- ## 9. まとめ Linux デスクトップにおける2026年時点の脅威は、以下のように整理できる。 1. **最大の現実的脅威はサプライチェーンである。** AUR の400超パッケージ侵害に代表されるとおり、攻撃はすでに配布経路に到達している。そして各エコシステムの公式ガイダンスは、**署名や provenance が保証するのは出所であって中身の安全性ではない**ことを自ら明示している。 2. **次に現実的なのは、利用者自身を実行者にする手法である。** ClickFix は Linux を含む全 OS を対象とし、Linux の端末文化はこの攻撃と相性が悪い。 3. **root 権限は攻撃者の必須要件ではない。** 認証情報の窃取はユーザー権限で完結し、被害は端末を超えて波及する。 4. **デスクトップ固有のデーモンが攻撃面である。** sudo、udisks、polkit、CUPS など、利便性を支える仕組みに重大な脆弱性が継続的に発見されている。 5. **X11 のままではアプリケーション分離は成立しない。** Wayland 移行は前提条件であり、Flatpak の権限も既定値のままでは不十分である。 6. **Linux デスクトップの相当部分は開発環境である。** 開発端末には SSH 鍵・クラウド認証情報・署名鍵が集積し、その侵害は成果物を通じて下流へ波及する。IDE 拡張機能は第二のパッケージマネージャであり、ビルドは日常に組み込まれた任意コード実行である。 7. **持ち出し端末では、脅威モデルが変わる。** 暗号化が守るのは「電源が切れている状態」に限られる。evil maid、DMA、BadUSB、覗き見は、いずれも暗号化では防げない。 8. **すべての前提は「己を知る」ことである。** 何を入れ、何が動き、平常時に何と通信しているかを把握していなければ、他のいずれの対策も対象を定められない。とりわけ送信側——どのアプリが何と通信しているか——の把握が決定的に欠けており、これを欠いたままでは侵害に気づく手段も持てない。対策の骨格は単純である。**まず自分の端末を知り、その上で、入手経路を統制し、自分で悪意あるコマンドを実行せず、更新を絶やさず、使わない機能を止め、分離を保ち、暗号化とバックアップで最悪に備え、端末から目を離さず、そして異変に気づく手段を持つ。** 目新しいものは一つもない。しかし、Linux デスクトップの世界では、これらの基本が「Linux だから安全」という前提のもとで省略されてきた。前提が変われば、省略の正当性も失われる。 --- ## 脚注 [^1]: GIGAZINE「Linuxのデスクトップ利用が1日のうちに22％まで急増したことがCloudflareのデータで明らかに」 https://gigazine.net/news/20260814-linux-desktop-cloudflare/ (2026-08-15 閲覧)。同記事が参照する原典は ZDNET "Linux desktop use surged to 22% on one workday, Cloudflare data shows" https://www.zdnet.com/article/linux-desktop-use-surged-on-one-workday-cloudflare-data-shows/ 、および Cloudflare Radar https://radar.cloudflare.com/ 、StatCounter https://statcounter.com/ である。 [^2]: ITmedia エンタープライズ「『もう手動での対応は無理……』 Linux関連の脆弱性は前年比で967％増加」 https://www.itmedia.co.jp/enterprise/spv/2505/19/news081.html (2026-08-15 閲覧) [^3]: Huntress "The Evolving Linux Threat Landscape" https://www.huntress.com/blog/evolving-linux-threat-landscape (2026-08-15 閲覧) [^4]: LinuxSecurity "CHAOS RAT Found in Arch Linux AUR Packages" https://linuxsecurity.com/features/chaos-rat-in-aur (2026-08-15 閲覧) [^5]: Codebook（マキナレコード）「400超のArch Linuxパッケージがルートキットと情報窃取マルウェアを拡散」 https://codebook.machinarecord.com/threatreport/silobreaker-cyber-alert/46162/ (2026-08-15 閲覧) [^6]: BleepingComputer "Over 400 Arch Linux packages compromised to push rootkit, infostealer" https://www.bleepingcomputer.com/news/security/over-400-arch-linux-packages-compromised-to-push-rootkit-infostealer/ (2026-08-15 閲覧。[^5] に記載の原典URL) [^7]: Microsoft "2025 Microsoft Digital Defense Report" https://www.microsoft.com/en-us/security/security-insider/threat-landscape/microsoft-digital-defense-report-2025 、レポート本体 https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/msc/documents/presentations/CSR/Microsoft-Digital-Defense-Report-2025.pdf (2026-08-15 閲覧) [^8]: BleepingComputer "Hackers now testing ClickFix attacks against Linux targets" https://www.bleepingcomputer.com/news/security/hackers-now-testing-clickfix-attacks-against-linux-targets/ (2026-08-15 閲覧) [^9]: SOC Prime "CVE-2025-32463 and CVE-2025-32462 Detection: Sudo Local Privilege Escalation Vulnerabilities" https://socprime.com/blog/cve-2025-32463-and-cve-2025-32462-vulnerabilities/ (2026-08-15 閲覧) [^10]: Sudo Project "Local Privilege Escalation via chroot option"（公式セキュリティアドバイザリ） https://www.sudo.ws/security/advisories/chroot_bug/ (2026-08-15 閲覧)。なお sudo 公式アドバイザリは CVSS 値を示していない。本文で挙げた CVSS v3.1 の両評価は、NVD の当該ページに併記されているものである。CNA（MITRE）による評価は 9.3 CRITICAL（`CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`）、NVD（NIST）による評価は 7.8 HIGH（`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`）。 https://nvd.nist.gov/vuln/detail/cve-2025-32463 (2026-08-15 閲覧) [^11]: ScanNetSecurity「Linux に権限昇格の脆弱性」 https://scan.netsecurity.ne.jp/article/2026/05/07/55193.html (2026-08-15 閲覧) [^12]: Ubuntu (Canonical) "CUPS Remote Code Execution Vulnerability Fix Available" https://ubuntu.com/blog/cups-remote-code-execution-vulnerability-fix-available (2026-08-15 閲覧) [^13]: Qualys ThreatPROTECT "CUPS Printing Systems Remote Code Execution Vulnerability" https://threatprotect.qualys.com/2024/09/27/cups-printing-systems-remote-code-execution-vulnerability-cve-2024-47176-cve-2024-47076-cve-2024-47175-cve-2024-47177/ (2026-08-15 閲覧) [^14]: ISSOH「WaylandとX11の違い｜構造・セキュリティ・確認方法【2026年版】」 https://www.issoh.co.jp/tech/details/11677/ (2026-08-15 閲覧) [^15]: X.Org Security Advisory "multiple security issues X.Org X server and Xwayland" (2025-10-28) https://lists.x.org/archives/xorg-announce/2025-October/003635.html および X.Org Development/Security https://www.x.org/wiki/Development/Security/ (2026-08-15 閲覧) [^16]: GitHub "Flatpak Overrides" https://github.com/QWxleA/Flatpak-Overrides (2026-08-15 閲覧) [^17]: Flatpak 公式ドキュメント "Sandbox Permissions" https://docs.flatpak.org/en/latest/sandbox-permissions.html (2026-08-15 閲覧) [^18]: Linux Journal "When Flatpak's Sandbox Cracks: Real-Life Security Issues Beyond the Ideal" https://www.linuxjournal.com/content/when-flatpaks-sandbox-cracks-real-life-security-issues-beyond-ideal (2026-08-15 閲覧) [^19]: Flatseal ドキュメント https://github.com/tchx84/Flatseal/blob/master/DOCUMENTATION.md (2026-08-15 閲覧) [^20]: ANSSI "Configuration recommendations of a GNU/Linux system" (ANSSI-BP-028 v2.0 英語版) https://messervices.cyber.gouv.fr/documents-guides/linux_configuration-en-v2.pdf (2026-08-15 閲覧) [^21]: Red Hat "ANSSI-BP-028 security recommendations updated to version 2.0" https://www.redhat.com/en/blog/anssi-bp-028-security-recommendations-updated-version-2.0 (2026-08-15 閲覧) [^22]: cryptsetup 公式 FAQ https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md 、cryptsetup(8) man page https://man7.org/linux/man-pages/man8/cryptsetup.8.html 、および ArchWiki "dm-crypt/Device encryption" https://wiki.archlinux.org/title/Dm-crypt/Device_encryption (2026-08-15 閲覧) [^23]: systemshardening.com "LUKS Disk Encryption with TPM2 Sealing: Measured Boot and Network-Bound Unlock" https://www.systemshardening.com/articles/linux/luks-tpm2-sealing/ (2026-08-15 閲覧) [^24]: Kicksecure Wiki "Evil Maid Attack" https://www.kicksecure.com/wiki/AEM および "USBGuard" https://www.kicksecure.com/wiki/USBGuard (2026-08-15 閲覧) [^25]: Bruce Schneier "'Evil Maid' Attacks on Encrypted Hard Drives" https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html (2026-08-15 閲覧) [^26]: Wikipedia "Thunderspy" https://en.wikipedia.org/wiki/Thunderspy および "Evil maid attack" https://en.wikipedia.org/wiki/Evil_maid_attack (2026-08-15 閲覧) [^27]: USBGuard 公式サイト https://usbguard.github.io/ (2026-08-15 閲覧) [^28]: ArchWiki "USBGuard" https://wiki.archlinux.org/title/USBGuard (2026-08-15 閲覧) [^29]: CERT/CC Vulnerability Note VU#395981 "Self-encrypting hard drives do not adequately protect data" https://www.kb.cert.org/vuls/id/395981/ (2026-08-15 閲覧) [^30]: Dell "Self-Encrypting Drives Vulnerabilities (CVE-2018-12037 and CVE-2018-12038): Mitigation steps for Dell Encryption products" https://www.dell.com/support/kbdoc/en-us/000130689/ (2026-08-15 閲覧)。Microsoft のアドバイザリ ADV180028 に基づく BitLocker 側の対応については Petri "Self-Encrypting SSDs Vulnerable to Attack, Microsoft Warns" https://petri.com/self-encrypting-ssds-vulnerable-to-attack-microsoft-warns/ (2026-08-15 閲覧) を参照した。 [^31]: Safing "Portmaster - Application Firewall" https://safing.io/ (2026-08-15 閲覧) [^32]: GitHub - safing/portmaster README https://github.com/safing/portmaster (2026-08-15 閲覧) [^33]: NSA / CISA "Selecting a Protective DNS Service" (Cybersecurity Information Sheet, v1.3) https://media.defense.gov/2025/Mar/24/2003675043/-1/-1/0/CSI-Selecting-a-Protective-DNS-Service-v1.3.PDF (2026-08-15 閲覧) [^34]: CISA "Joint NSA and CISA Guidance on Strengthening Cyber Defense Through Protective DNS" https://www.cisa.gov/news-events/alerts/2021/03/04/joint-nsa-and-cisa-guidance-strengthening-cyber-defense-through-protective-dns (2026-08-15 閲覧) [^35]: Debian Wiki "DebianRepository/UseThirdParty" https://wiki.debian.org/DebianRepository/UseThirdParty (2026-08-15 閲覧) [^36]: Ubuntu 公式ヘルプ "Add a Personal Package Archive (PPA)" https://help.ubuntu.com/stable/ubuntu-help/addremove-ppa.html.en (2026-08-15 閲覧) [^37]: Fedora Project Wiki "Third Party Repository Policy" https://fedoraproject.org/wiki/Third_Party_Repository_Policy (2026-08-15 閲覧) [^38]: Fedora Project Wiki "Changes/Enforcing signature checking by default" https://fedoraproject.org/wiki/Changes/Enforcing_signature_checking_by_default (2026-08-15 閲覧) [^39]: AUR 公式サイトの DISCLAIMER https://aur.archlinux.org/ および ArchWiki "Arch User Repository" https://wiki.archlinux.org/title/Arch_User_Repository (2026-08-15 閲覧) [^40]: pip documentation "Secure installs" https://pip.pypa.io/en/stable/topics/secure-installs/ (2026-08-15 閲覧) [^41]: PyPI Docs "Attestations — Security Model and Considerations" https://docs.pypi.org/attestations/security-model/ (2026-08-15 閲覧) [^42]: npm Docs "Generating provenance statements" https://docs.npmjs.com/generating-provenance-statements/ (2026-08-15 閲覧) [^43]: Todyl "ClickFix: The Evolution of Copy-Paste Social Engineering" https://www.todyl.com/blog/clickfix-evolution-copy-paste-social-engineering (2026-08-15 閲覧) [^44]: Phoronix "Three More X.Org Server & XWayland Security Vulnerabilities Made Public" https://www.phoronix.com/news/X.Org-Server-3-Vuln-Oct-2025 (2026-08-15 閲覧) [^45]: Stack Overflow "2025 Developer Survey — Technology" https://survey.stackoverflow.co/2025/technology (2026-08-15 閲覧) [^46]: FOSS Post "Most Popular Linux Distros 2026" https://fosspost.org/most-popular-linux-distros/ (2026-08-15 閲覧)。Stack Overflow Developer Survey 2025 の集計値（Ubuntu：業務27.7%、個人27.8%、回答者49,000人超）を整理したもの。 [^47]: Cyber Security News "Malicious JetBrains and VS Code Extensions Steal OpenAI, Anthropic, and DeepSeek API Keys" https://cybersecuritynews.com/malicious-jetbrains-and-vs-code-extensions-steal-api-keys/ (2026-08-15 閲覧)。Aikido Security および Koi Security の調査に基づく。 [^48]: BleepingComputer "Malicious AI extensions on VSCode Marketplace steal developer data" https://www.bleepingcomputer.com/news/security/malicious-ai-extensions-on-vscode-marketplace-steal-developer-data/ (2026-08-15 閲覧) [^49]: Cyber Security News "Nx Console VS Code Extension Compromised to Steal Developer and Cloud Secrets" https://cybersecuritynews.com/nx-console-vs-code-extension-compromised/ (2026-08-15 閲覧) [^50]: Unit 42（Palo Alto Networks）「求職戦線異状あり: 北朝鮮の国家支援型 APT 脅威アクターの特徴をもつ 2 つの求人・求職ハックキャンペーン」 https://unit42.paloaltonetworks.com/ja/two-campaigns-by-north-korea-bad-actors-target-job-hunters/ (2026-08-15 閲覧) [^51]: マクニカセキュリティ研究センターブログ「北からのジョブオファー: ソフトウェア開発者を狙う Contagious Interview」 https://security.macnica.co.jp/blog/2024/10/-contagious-interview.html (2026-08-15 閲覧) [^52]: Linuxiac "Linux Desktop Market Share Surpasses 10% in North America" https://linuxiac.com/linux-desktop-market-share-surpasses-10-in-north-america/ (2026-08-15 閲覧)。ZDNET 原文の逐語引用については Slashdot 掲載分 https://linux.slashdot.org/story/26/08/11/2047228/linux-desktop-use-surged-to-22-on-one-workday-cloudflare-data-shows を参照した。 [^53]: XenoSpectrum "North American Linux Tops 10%, But It's Not a \"PC Market Share\" Milestone Yet" https://xenospectrum.com/en/linux-statcounter-north-america/ (2026-08-15 閲覧) [^54]: LWN.net "The kernel becomes its own CNA" https://lwn.net/Articles/961961/ (2026-08-15 閲覧)。なお、この文言はしばしば誤解を招くとして、Linux CNA チームの側からは、実際には CVE 採番を最小限に留め、セキュリティ上のリスクを生じうる欠陥にのみ番号を割り当てているとの説明がなされている（https://lwn.net/Articles/978711/ 、2026-08-15 閲覧）。 [^55]: Flatpak GitHub Issue #5744（X11 ソケットへのアクセスがサンドボックス脱出の経路となりうる点に関する議論）https://github.com/flatpak/flatpak/issues/5744 (2026-08-15 閲覧)