Omarchy：あらゆるユーザープロセスがrootに権限昇格可能

Omarchy：あらゆるユーザープロセスがrootに権限昇格可能 Omarchy のデフォルト Docker 設定におけるセキュリティ問題により、ユーザーのデスクトップセッションで実行されているほぼ全てのプログラムが、パスワード、sudo、または権限昇格プロンプトなしに root に権限昇格できるようになりました。 Omarchy を使用している場合、最も重要な点はシンプルです：4.0.1 にアップデートしてください。 私はこの問題をプロジェクトの責任ある開示プロセスを通じてプライベートに報告しました。根本的な設定はその後パッチ適用されたため、問題の内容を説明し、ユーザーにシステムのアップデートを知らせるために、ここで詳細を公開します。 問題 Omarchy はデフォルトのユーザーを Linux の docker グループのメンバーとして設定していました。 これにより、ユーザーは以下のようなコマンドを実行できます。 docker run ... sudo を入力せずに。 Arch Linux では、Docker デーモンは root として実行され、/var/run/docker.sock でリッスンしています。docker グループのメンバーは、そのソケットと通信できます。Docker 自体は、docker グループがユーザーに root レベルの権限を付与することを明示的に警告しています。 Docker ソケットにアクセスできるプロセスは、root 権限でコンテナを起動し、ホストファイルシステムの任意の領域をマウントし、それらのファイルに対して root として操作を行い、root としてコードを実行するように、root 所有の Docker デーモンに要求できます。 Affected Omarchy システムでは、これはデフォルトのユーザーと、そのユーザーセッションで起動されたすべてのプロセスが root にアクセスできることを意味します。 Proof of Concept 影響を受ける Omarchy の新規インストールで /etc/shadow を読み取ってみます： $ cat /etc/shadow cat: /etc/shadow: Permission denied 次に、ユーザーのグループメンバーシップを確認します： $ 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 として実行されているデーモンを介して行われます。 範囲 Linux の補助グループは子プロセスに継承されるため、これはユーザーセッション全体に影響します。 ユーザーの systemd --user インスタンスの下のプロセスツリーをたどると、セッション内のほぼすべての通常のプロセスに Docker グループが存在することが示されました。 これは、信頼されていないコードが実行される可能性のあるほぼすべてのプロセスが root を取得できることを意味します。これには以下が含まれます： AI コーディングエージェントおよびエージェントハーネス Web ブラウザ エディタおよび IDE npm スクリプト ランダムな開発ツール バックグラウンドプロセス つまり、通常のユーザーアプリケーションの侵害は、直ちに完全なマシン侵害につながる可能性があります。 セキュリティデフォルト この設定には、もう1つ重要な側面があります。それはオプトインではなくオプトアウトでした。ユーザーは実際に Docker を使用する必要はありませんでした。セキュリティ上のトレードオフはユーザーのために行われ、デフォルトのアカウントに適用され、トレードオフはユーザーに説明されませんでした。 セキュリティ上重要なデフォルトは、多くのユーザーが合理的にオペレーティングシステムがデフォルトで安全であり、より安全でない設定についてはオプトインを通知またはプロンプトすると想定しているため、重要です。 誤解を招くドキュメント Omarchy は、開発者ツールに関するドキュメントで Docker グループについて言及していました。 Omarchy は [docker] をうまく実行するために必要なすべてをインストールします。これには…通常のユーザーとして Docker を root 以外で実行するために必要なユーザーグループの変更が含まれます。 セキュリティへの影響は、典型的な読者が推測するであろうこととほぼ反対です。「root 以外で」という説明を読んだユーザーは、Omarchy が Docker を何らかの rootless モードで設定したと合理的に結論付ける可能性があります。しかし、そうではありませんでした。 影響を受けるバージョン これは 4.0.1 より前のバージョンに影響します。最新の 3.x ISO (3.8.4) でも影響を受けました。 タイムライン この問題の導入から解決までのコミットのタイムライン： 2025年6月1日 — Docker グループメンバーシップが導入されました 25799ee 2025年6月2日 — Docker グループの追加が一時的に無効化されました c5ee230 2025年6月17日 — Docker グループメンバーシップが再度有効化されました fdd2aaf 2026年8月24日 — Docker グループメンバーシップがデフォルト設定から削除されました b5ded31 より広い文脈 AI がコアインフラストラクチャに対して高深刻度の CVE をますます生成するにつれて、セキュリティはすべての開発者にとって最優先事項である必要がありますが、特に開発者をターゲットにしたディストリビューションの作成者にとってはそうです。最近、開発者のマシンが侵害され、そのアクセスがソフトウェアサプライチェーンを汚染したり、本番システムを悪用するために使用されたという報告が数え切れないほどあります。開発者は、しばしば付与されるアクセスのレベルのために、高価値のターゲットです。開発者のマシンは通常、利便性のためにセキュリティガードレールを無効にし、認証情報をプレーンテキストのドットファイルに保存し、システムへのアクセスを蓄積します。これは変わらなければなりません。 DHH が docker グループを追加することの影響を知らなかったため、単なる見落としだったと確信しています。セキュリティに関して完璧な決定を下すディストリビューションはありません。この問題が報告された際の対応の速さには驚かされました。これは健全な兆候です。 とはいえ、Omarchy でセキュリティ問題に遭遇したのはこれが初めてではなく、率直に言って、私のディストロに期待するセキュリティレベルを確保するための意思決定プロセスは信頼できません。Omarchy には多くの良い点があるので、いつかそれが変わることを願っています。 Podman Linux で Docker を使用しており、コンテナを実行するために root 権限（sudo を使用しても）を強制されることを避けたい場合は、Podman を試すことを強くお勧めします。Podman はデーモンレスです。コンテナは独自のユーザー名前空間で通常の子プロセスとして実行され、いかなる種類の root アクセスも必要としません。私は数ヶ月間 Podman を実行しており、すべての Docker ワークフローを完全に置き換えました。ぜひ試してみてください。 参考文献 Docker：非 root ユーザーとして Docker を管理する Omarchy Docker ドキュメント