Omarchy:任意のユーザープロセスがルートに昇格可能

2026/08/31 0:59

Omarchy:任意のユーザープロセスがルートに昇格可能

RSS: https://news.ycombinator.com/rss

要約

Japanese Translation:

Omarchy のデフォルトシステム構成には、Docker 経由で任意のデスクトップアプリケーションが root に特権を昇級させることを可能にする深刻なセキュリティ上の欠陥が含まれており、これによりオペレーティングシステム全体が侵害されるリスクが生じていました。核心的な問題は、ユーザーが自動的に Docker グループに追加されていたことと、root アクセスなしで Docker が動作すると誤って記載された誤導的な文書によるものでした。その結果、Web ブラウザ、コードエディタ、AI コーディングエージェント、IDE、npm スクリプト、バックグラウンド開発ツールといった一般的なアプリケーションが侵害される場合、完全なシステム権限を持って任意のコードを実行することができました。この脆弱性はバージョン 4.0.1 の前まで存在し、発見当时には最新の ISO リリース(バージョン 3.8.4)も含まれていました。バージョン 4.0.1 で公開された重大なパッチにより、デフォルト設定から Docker グループのメンバーシップが恒久的に削除されましたが、このインシデントは、ユーザーの同意なく適用されたセキュリティ感度の高いデフォルト設定に伴う重大なリスクを示しています。Docker グループのメンバーシップは 2025 年 6 月 1 日に導入され、2025 年 6 月 2 日に一時的に無効化され、2025 年 6 月 17 日に再度有効化され、最終的に 2026 年 8 月 24 日に削除されました。専門家は現在、安全なコンテナ化のために Podman などの代替手段を採用するよう推奨しています。脆弱性のある Docker セットアップとは異なり、Podman はユーザーネームスペース内でコンテナを実行し、root 権限や特別なシステムグループの必要なく動作するため、特権昇級を防ぎ、標準的なセキュリティ期待に より適合するより安全なアーキテクチャを提供します。著者はこの問題を Omarchy に対して秘密裏のリスク対応プロセスを通じて報告し、通知された後、下層の設定をパッチ適用しました。対応速度は称賛されましたが、過去の事案により著者は Omarchy のセキュリティに関する意思決定プロセス全体への信頼を失っています。

本文

Omarchy のセキュリティ脆弱性と対処方法について

Omarchy の既定の Docker 構成に重大なセキュリティ上の問題が発見されました。この問題は、ユーザーのデスクトップセッション上で動作するほぼすべてのプログラムが、パスワードや sudo コマンド、特権昇格のプロンプトを必要とせずに root 権限を行使可能にするものでした。

本記事では問題の概要、影響範囲、および解決策について解説します。

解決策:アップデートを必須とする

Omarchy をご使用の方は、以下のバージョンへのアップグレードを最優先で実行してください。

  • 至急対応: 現在のバージョンから 4.0.1 版 へアップデートしてください。
  • 状況: この脆弱性は既にパッチ済みであり、詳細は責任ある情報開示プロセスを通じて報告済みのものです。

問題の詳細とメカニズム

1. 根本原因:docker グループへのメンバーシップ

Omarchy の設定では、ユーザーを Linux の

docker
グループのメンバーとして自動付与していました。これにより、sudo コマンドなしで Docker ソケットにアクセス可能になります。

  • Docker デモン: root ユーザーとして動作し、
    /var/run/docker.sock
    を監視しています。
  • 権限付与:
    docker
    グループのメンバーは、このソケットを通じて root レベルの特権を行使できます。
  • リスク: Docker ソケットにアクセスできるプロセスは、host ファイルシステムをコンテナ内にマウントしたり、root としてファイルを読み書きしたり、コードを実行したりできます。

2. 影響の範囲:セッション全体への波及

影響を受けたシステムでは、既定ユーザーとそのセッション内で起動されたすべてのプロセスに root アクセスが付与されます。

【概念実証(Proof of Concept)】 通常、普通ユーザーは

/etc/shadow
にアクセスできません。しかし、Docker を介すると閲覧可能です。

# 通常のユーザーからのアクセス:禁止
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

# ユーザーのグループ情報(docker グループが含まれている)
$ id
uid=1000(tester) gid=1000(tester) groups=1000(tester),967(docker),992(input),998(wheel)

# Docker を介したアクセス:root 権限で閲覧可能
$ docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow
root:$6$...
bin:!*:...
daemon:!*:...

このコマンドはユーザープロセスから起動しますが、実際のファイルシステム操作は root として動作する Docker デモンを通じて行われます。Linux のサブグループ(補助グループ)メンバーシップは子プロセスに継承されるため、セッション内の全てのアプリケーションに影響します。

脆弱化される潜在的なプロセス

信頼性の低いコードが実行可能な以下のほぼすべてのツールが侵害対象となります:

  • AI コーディングエージェントおよびエージェントフレームワーク
  • ウェブブラウザ
  • エディタおよび IDE(統合開発環境)
  • npm スクリプト
  • 開発用ツールの一部
  • バックグラウンドで動作するプロセス

つまり、通常のユーザーアプリケーションの一つが侵害されただけでも、直ちに完全なマシーンの侵害(コンプラメーション)につながる可能性があります。

セキュリティデフォルトに関する懸念点

この構成の問題は、単なるバグではなく、「オプトアウト」方式(悪意のある設定をデフォルトとし、ユーザーが手動で回避する必要がある)であり、「オプトイン」方式ではありません

  • 無関係なユーザーも影響: ユーザーが Docker を使用していなくてもセキュリティ上のリスクが存在します。
  • 説明不足: トレードオフ(利便性 vs セキュリティ)についてユーザーは事前に説明されておらず、安全であると誤認させる可能性があります。
  • 利用者の心理: 多くのユーザーは OS のデフォルト設定は安全だと合理的に想定しており、より不安全な設定に変更する際のアラートやプロンプトを期待しています。

誤解を招くドキュメントの記述

Omarchy の開発者向けドキュメントには以下のような記述がありました:

「Omarchy では [Docker] を適切に動作させるために必要なすべてのものをインストールします。これには、通常ユーザーとして(root としてではなく)Docker を実行するために必要なユーザーグループの変更も含まれます。」

この「root としてではなく」という表現は、一般的な読者を欺く可能性を孕んでいます。

  • 誤った解釈: 「Omarchy は rootless モード(安全なモード)で Docker を設定した」と推測される。
  • 実態: 実際には
    docker
    グループへの追加により、root アクセスが可能になっていた。

この表現はセキュリティ上の含意が逆になることを招き、深刻な誤解を生じさせていました。

影響対象のバージョンとタイムライン

影響を受けるバージョン

  • Omarchy 4.0.1 以前
  • Omarchy 3.x イーソス: 最新の 3.8.4 版でも同様の脆弱性が確認されています。

修正までのタイムライン(コミット履歴)

  1. 2025 年 6 月 1 日:
    docker
    グループのメンバーシップが導入された (
    commit: 25799ee
    )
  2. 2025 年 6 月 2 日: グループ追加が一時的に無効化された (
    commit: c5ee230
    )
  3. 2025 年 6 月 17 日: グループメンバーシップが再度有効化された(脆弱性の再発)
    (
    commit: fdd2aaf)`
  4. 2026 年 8 月 24 日: デフォルト構成から
    docker
    グループのメンバーシップが正式に削除された (
    commit: b5ded31
    )

より広い文脈:開発者向けディストリビューションのセキュリティ

現在、AI アジェンツなどがコアインフラストラクチャに対して重篤な CVE(クリティカルな脆弱性)を発見するケースが増えています。

  • ハイリスク: 開発者は高権限を有するため、最も標的にされやすいターゲットです。
  • 現状の課題: セキュリティガードレールの緩和や認証情報を平文で保存し、多様なシステムへのアクセス権を蓄積する傾向があります。
  • 期待: 今回の問題について迅速に対応してくれた姿勢は評価しましたが、過去のセキュリティ事例を考慮すると、現在の意思決定プロセスでは期待するレベルのセキュリティが確保できるか疑問が残ります。

推奨ソリューション:Podman の活用

root アクセス(sudo)を強制的に受けたくないと考える場合、Podmanの利用を検討することを強く推奨します。

  • Daemonless アーキテクチャ: サーバーデーモン不要で動作します。
  • ユーザーネームスペース: コンテナは独自の名前空間内で通常の子プロセスとして動作し、root アクセスは一切必要ありません。
  • 実績: 何ヶ月も運用した結果、従来の Docker ワークフローを完全に置き換えることができました。

参考リンク

同じ日のほかのニュース

一覧に戻る →

2026/08/30 2:49

おどろおどろしい虫たち

## Japanese Translation: Linux カーネルの公式サイトは、AI モデルの学習に使用する自動スクレーパーから多大な負荷をかけています。これらのボットはプロキシ SDK を利用し、数百万件の住宅 IP やモバイル IP を悪用しています。これらのボットは日間のトラフィックのおよそ 33% を消費し、利用可能な CPU コアを約半数(5 つの地理的に分散されたノードを通じて 90 のコアのうち 14〜16 コア)に占有しており、主にレポジトリをクローンするのではなく git コミットを HTML としてレンダリングすることによってこれを行っています。この手法はプロジェクトの著者が「スクレーパーがデータを使用する最も愚かな方法」と呼んでいます。Anubis がアクセス前に SHA256 パズルを要求しているにもかかわらず、ボットが低い難易度を解いた後に難易度がレベル 4 から 5 に引き上げられましたが、これはモバイルユーザーにとってデバイスを温めるという点で依然として不満を生み出しており、人間の行動を模倣する高度な戦術を完全に阻止していません。推定される正当な人間によるトラフィックはわずか約 2% です。スクレーパーは Linux カーネルの履歴が LLM の学習データの豊富な源泉であるためこれを標的としています。また、浅いクローンを使用している脆弱な CI システムは、さらなる即時的過負荷リスクをもたらします。緩和策としては特定の機能を無効化し、匿名ユーザーのアクションをゲートリングするなどの措置が講じられていますが、すべてのデータは引き続きダウンロード可能です。簡単な解決策はありません:新しい AI モデル企業は引き続き無料の学習データを求めており、アプリ開発者は家庭用デバイスを攻撃ベクトルに変え続けており、その結果、サイトはスクレーパーによる負荷から「背景放射線」のような状態に常時置かれています。

2026/08/31 5:00

宇宙のコア:1980年のスペースシャトル搭載のSpacelabコンピュータから復元されたコアメモリモジュール

## Japanese Translation: Spacelab は、スペースシャトルの貨物コンパートメントに搭載された再利用可能な欧州製実験室であり、標準的な IBM AP-101 システムではなく、フランス製 Mitra 125 MS ミニコンピュータを 3 台採用していた。これら 3 台のうち 1 台は実験室を、もう 1 台は実験を担当し、残りの 1 台が予備として機能した。各コンピュータのメモリシステムは 1980 年頃製作され、シリコンではなくフェライトリングを使用した磁性コアメモリを採用しており、「2½D」アーキテクチャにより抑制線を廃止するため、各ビットに独立した X ドライバ回路を設け、位相反転技術を用いることで垂直ドライバの数を半減させていた(U 字形の配線ループを使用)。メモリスタックは 7 ボードで構成され、ドライバボード、4 つのコアプレーンボード、第 2 のドライバボード、およびインターフェースボードからなっていた。各コアプレーンは 1024 本の垂直 Y ワイヤーと 288 本の水平 X ワイヤーで支えられ、16K の 18 ビット語(32 KB)を保持し、総計で 294,912 個のリチウムフェライトコアを有していた。ノイズキャンセレーションにはねじれペアセンスワイヤと「蝶結び」状のクロス構成が用いられ、ダイオードマトリクスはプリント基板間にコードウッド構造を採用しており、各ダイオードチップには 8 コアラインに対応する 16 個のダイオードが含まれていた。1991 年、IBM AP-101S のアップグレードにより、AP-101SL モディフィケーションを通じて磁性コアを半導体メモリに置き換えられながら、フェライトコアメモリが廃棄される直前まで Spacelab システムとの互換性を維持した。 ## Text to translate: Spacelab was a reusable European laboratory carried in the Space Shuttle's cargo bay that employed three French-built Mitra 125 MS minicomputers—rather than standard IBM AP-101 systems—with one managing the laboratory, one managing experiments, and one as a backup. Each computer's memory system, built around 1980, used magnetic core memory with ferrite rings (not silicon) in a "2½D" architecture that eliminated inhibit lines by using separate X driver circuitry for each bit; phase reversal techniques halved the number of vertical drivers via U-shaped wiring loops. The memory stack comprised seven boards: a driver board, four core plane boards, a second driver board, and an interface board. Each core plane held 16K of 18-bit words (32 KB) supported by 1024 vertical Y wires and 288 horizontal X wires, totaling 294,912 lithium ferrite cores. Noise cancellation was achieved through twisted pair sense wires and a "bow tie" crossing configuration, while diode matrices used cordwood construction between printed circuit boards (each diode chip containing 16 diodes for 8 core lines). In 1991, IBM AP-101S upgrades replaced the original magnetic cores with semiconductor memory via the AP-101SL modification, maintaining compatibility with the Spacelab system before ferrite core memory became obsolete.

2026/08/31 1:01

Haiku R1/beta6 がリリースされました

## Japanese Translation: 2026 年 8 月 26 日(水曜日)に、R1/beta6 のリリースをもって Haiku は創業 25 周年を迎えます。これは記念日から約 1 ヶ月後、そして前回から約 2 年後の発表です。この大きなアップデートは開発の一時停止を経て実現され、ユーザーに待ち望まれていた機能向上を提供します。ファンは提供されたダウンロードポータルを通じてすぐにアップグレードを行うか、詳細なリリースノートを確認するか、またはお問い合わせにはプレスコンタクトまでご連絡ください。この発売は Haiku の遺産を称えつつ、オープンソース OS が専用コミュニティと共に進化し続ける中、個々のユーザーならびにテクノロジー企業双方がアクセス可能な導入と継続的なフィードバックへと導く重要な瞬間を象徴します。

Omarchy:任意のユーザープロセスがルートに昇格可能 | そっか~ニュース