Omarchyで、ふつうのユーザーが動かすあらゆるプロセスからroot権限に近い操作ができてしまう設定不備が見つかりました。見つかったのはDockerの既定設定に関する問題で、影響を受ける環境ではパスワード入力もsudoも権限昇格の確認も必要ありませんでした。公開した筆者は、すでに責任ある開示の手順で報告し、修正されたので詳細を明かしたと説明しています。Omarchyを使っているなら、まず確認すべきはシンプルで、4.0.1への更新です。
元記事が指摘しているのは、Omarchyの既定ユーザーがLinuxのdockerグループに入っていたことです。Dockerを使ったことがある人なら、docker run ... をsudoなしで実行できる設定だと考えると分かりやすいでしょう。ただしこの便利さには重い代償があります。ArchではDockerデーモンがrootで動き、/var/run/docker.sock を待ち受けています。dockerグループのメンバーはそのソケットにアクセスできるため、rootで動くデーモンに命令を送れる。Docker自身も、dockerグループはユーザーにroot級の権限を与えると明確に警告しています。
筆者は、そこからさらに踏み込みます。ソケットに触れるプロセスは、root所有のDockerデーモンに対して「rootでコンテナを起動してほしい」と頼めるだけでなく、ホストのファイルシステムの任意の部分をコンテナへマウントし、そのファイルをrootとして扱えます。つまり、dockerグループに入っているだけで、実質的にroot相当の操作が可能になるという話です。影響を受けるOmarchyでは、デフォルトユーザーと、そのセッションで立ち上がるプロセスの多くがこの権限を持っていました。
実際の確認例も示されています。新規の影響環境では、/etc/shadow を普通に読むと Permission denied になります。ところが id を見ると、ユーザーは docker、input、wheel など複数グループに所属していました。そのうえで docker run --rm -v /:/hostroot alpine cat /hostroot/etc/shadow を実行すると、root:$6$... で始まるファイル内容が読めてしまう。見た目は普通のユーザーが打ったコマンドでも、実際のファイルアクセスはrootで動くデーモン経由で行われるためです。
影響範囲はかなり広く、Linuxの補助グループは子プロセスにも引き継がれるので、ユーザーのsystemd --user配下で動くほぼすべての通常プロセスに波及します。筆者は、AI coding agents、ブラウザ、エディタやIDE、npm scripts、開発用ツール、バックグラウンドプロセスまで列挙しています。要するに、ふだんのユーザーアプリが一つ侵害されただけで、その場でマシン全体の侵害に発展しうる、というのが主張です。
この設定はオプトインではなくオプトアウトだった点も問題視されています。Dockerを使わない人でも、既定でこのリスクを背負わされていた。Omarchyの開発ツール文書には「normal userとして、rootではなくDockerを動かせるためのグループ変更」があると書かれていたそうですが、読んだ人はrootless modeのような安全な構成だと誤解しかねない、と筆者は述べています。影響を受けるのは4.0.1より前の版で、筆者は最新の3.x ISOである3.8.4でも再現したとしています。コミットの流れとしては、2025年6月1日に導入、6月2日に一度無効化、6月17日に再有効化され、2026年8月24日にようやく既定設定から外されました。
この件でいちばん引っかかるのは、攻撃者が何か巧妙なゼロデイを必要としないことです。設定そのものが危ない。しかも危険なのは「Dockerを使う人」ではなく、「そのセッションで何かを走らせる人」全体です。ブラウザでたまたま悪意あるコードを踏む、エディタに仕込まれた拡張が動く、開発用スクリプトに混入した処理が実行される。どれも開発者の机の上では珍しくありません。そこで即rootまで行けるのは、権限境界としてかなりまずいと思います。
筆者が強調しているのは、rootless modeではないのに「normal userでDockerが使える」という説明が、見た人に安全そうな印象を与えてしまう点です。ここは単なる説明不足ではなく、セキュリティ設計のミスに近い。便利さを優先した結果として、どの程度の権限が開くのかを利用者が理解しないまま配られていたわけで、これはディストリビューションが最も避けるべき失敗の一つではないでしょうか。
元記事の後半は、少し大きな文脈に広げています。AIを使った攻撃や、高権限の開発者マシンがソフトウェア供給網の汚染に使われる事例が増えていて、開発者向け環境は標的として格好の場所になっている、と筆者は見ています。ここは誇張ではないと思います。開発者の端末には、クラウドの鍵、社内のVPN、Gitの認証情報、複数の本番環境へのアクセスが集まりがちです。しかも利便性のために、普段なら嫌うはずのガードレールを外していることが多い。
Omarchyの件は、その弱点が丸ごと表面化した例だと読めます。開発者向けのディストリは「すぐ使えること」に価値がある一方で、初期設定の一つひとつがそのまま攻撃面になります。特にDockerやコンテナ周りは、慣れている人ほど危険を軽く見がちです。dockerグループがroot級という基本を知っていても、「既定で全員に入れる」のは別問題ですから。
筆者はOmarchy自体を全面否定しているわけではありません。報告への反応が速かったことは「健全な兆候」と評価していますし、今回の件も責任ある開示の流れで修正されたとしています。ただし、それでも「自分は今の判断プロセスを、期待する安全性を保証するものとしては信頼していない」とかなりはっきり書いている。ここは重い言葉です。
私も、この感覚は分かります。セキュリティ事故は、修正が早ければそれで終わりではありません。何が既定で入るのか、どこまでの危険を見積もって配るのか、その判断の積み重ねで信頼は決まるからです。今回はDockerグループという分かりやすい話でしたが、次も同じように見落とされない保証はない。開発者向けOSほど、便利さの裏で「何を無効化し、何を既定にしないか」を厳しく見る必要があります。
記事の最後で筆者は、Linuxでコンテナを使いたいがroot権限を背負いたくないならPodmanを勧めています。Podmanはdaemonlessで、コンテナは通常の子プロセスとして各ユーザー名前空間の中で動くため、rootアクセスを前提にしません。筆者は数か月使ってDockerのワークフローを完全に置き換えたとも書いています。
これは単なるツールの好みではなく、権限モデルの話です。Dockerの「便利さ」は、どうしてもrootに近い境界を引き寄せます。一方でPodmanは、その設計を最初から違う方向に振っている。もちろん互換性や運用のクセはありますが、少なくとも「普通に使っていたらrootを引っ張ってきていた」という事故は起こしにくい。今回のOmarchyの件を見たあとだと、コンテナ基盤を選ぶときにこの差はかなり大きいと感じます。
