stonking（Ubuntu 26.10）の開発; Snapshot 3とinitrd肥大への対応、 germidiff、 壁紙の確定
stonkingのSnapshot 3が無事にリリースされています[1]。リリースアナウンスには「35, you say? There’s a new image hiding in there. Can you guess which one? ;)」（「35って本当？ なにか新しいイメージが隠れているのですが、どれか分かりますか？」）という記載もあり、Snapshot 2と比べると、次のものが増えています。
desktop-amd64v3（x86-64v3向けのデスクトップイメージ）
netboot-ppc64el（ppc64el向けのNetboot用tarball）
netboot-s390x（s390x向けのNetboot用tarball）
一般的な用途で気にするべきはx86-64v3向けのデスクトップイメージが登場していることで、以前から続けられてきたx86-64v3のテストと評価がより現実的な方向になると言えそうです。x86-64v3の動作にはIntelであればHaswell（2013）以降、AMDであればExcavator（2015）以降のCPUが必要ですが、おおむね「10年もののハードウェアでなければ動く」という性質のものですし、あくまで「Ubuntu Desktopのバリエーションとして」登場するという形です（つまりUbuntu Desktopのx86-64版がなくなるわけではありませんし、仮になくなるような方向になっても、LubuntuやXubuntuなどは残ると期待できます）。
[1] Snapshot 1は5月末、Snapshot 2が6月末、そしてSnapshot 3が8月末ということで、本来7月末に出てくるはずのものが抜けているような気がしますが、とりあえずは気にしないことにしましょう。
こうした流れの横で、Dracutの改善についてのまとめが提供されています。示されている内容は以下の2点で、いずれもinitrdのサイズや展開負荷に対処するためのものです。
すでに圧縮されているカーネルモジュールを再度圧縮してinitrdに取り込むのではなく、「そのまま」取り込む機能を実装した。
rust-coreutils由来のバイナリではなく、busyboxを積極的に利用する形でinitrdを作成することで、容量の肥大を防ぐ機能を実装する予定。
後者について少し中身を見ておきましょう。
busyboxは「いろいろなcoreutilsの代わりをする」汎用のバイナリです。呼び出された名前に応じて動作を変えるバイナリで構成されており、組み込み環境のような小さな環境では、「lsやcatのような基本的なコマンドがbusyboxのシンボリックリンクになっている」（そしてbusyboxバイナリはlsと同じ振る舞いをしたり、catと同じ振る舞いをしたりする）という構成が取られることがあります。
そしてinitrdは「システムが完全に起動する」前に利用される、簡易のファイルシステムです。ブートローダーから起動されたカーネルは、「正式なファイルシステム」へ切り替える前（この切り替えは、その関数の名前からpivot_rootなどと呼びます）は、initrdにある各種コマンドバイナリを利用します。このバイナリは、dracut等のユーティリティがinitrdを作り出すタイミングで、「その時点のホストに含まれるバイナリ」を取り込む形で実現されています。
Ubuntu 26.04 LTSで行われたRustベースのcoreutilsへの切り替え後、この「取り込み」処理の結果として、Rust版のcoreutilsがinitrdに含まれるようになっていました。Rust版coreutilsは伝統的なGNU版coreutilsに比べてサイズが大きく、組み込みのようにリソースが限定されている環境、あるいはブートローダー関連として配置できるストレージサイズに上限がある環境では問題になる可能性があります。Raspberry Piでは実際にこのサイズ増大により、複数のブートアセットを保持するにはinitrdが大きくなりすぎるという問題を引き起こしていました。
今後予定されている修正は、この「取り込み」を抑制し、busyboxでできるだけ多くをまかなうというものです（そして現状のbusyboxのcoreutils互換機能にはいくつか「Dracutが必要とするものの、busyboxが解釈できないオプション」が存在するため、busybox側を先に直し、その上でbusyboxを活用する形に切り替えることが予定されています）。
この修正は26.04 LTSにもバックポートされる予定です。
内部の修正と並行して壁紙コンテストが終了し、デフォルトの壁紙とともに収録される画像が確定しています。そろそろリリースに向けて「見た目」が固まる時期でもあり、それらしくなってきたと言えるでしょう。
また、各種リリースイメージを構成する「seeds」の変更の影響を予測するためのツールとして、『germidiff』という新しいユーティリティが登場しています。これにより、「pollinateを削除したらcurlも消えた」事案のような問題を事前に予測できるようになるでしょう（ちなみに「Vibe Codingで作った」ということが明示されており、GitHub上のContributorsを見る限りでは、Claude Codeが利用されているようです）。
その他のニュース
linux-firmwareパッケージの細分化（26.04で取り込まれた「linux-firmware-qualcomm-graphics」などのような、デバイスごとに細分化されたfirmwareパッケージ）が、24.04 LTSでも利用できるようになりました。特に大規模なインストール環境において、システム更新に伴うネットワーク負荷を下げるために利用できるでしょう。
注目すべきセキュリティー的な視点：隔離とカバートチャネル
OpenAIのサイバー能力評価中にAIエージェント群（各種セーフガードが控えめに設定された、インターナルなリサーチ用モデル）が意図せず隔離を突破し、最終的にHugging Faceまで侵入した事件について、Black Hatでその詳細が語られています。
ポイントとしては、サイバーセキュリティ課題を解くことを課せられた複数のAIエージェントが、「課題を正攻法で解く」かわりに「環境そのもの」を攻略対象としたことと、「インターネットアクセスや相互通信の能力を持たない」環境に閉じ込められたエージェントが、内部にあるArtifactoryには書き込みアクセスが可能なこと、そしてそこを経由して相互通信が可能なことに気づき、「知らないあいだ」に相互通信を実現していた、という話題です。
またこの攻撃とは別に、インターネット上のwikiがAIエージェントによって『掲示板』として利用されてしまっていた事件、というものもあります。
こうしたAIエージェントやマルウェアの封じ込めを検討する場合、「隠れた通信経路」、いわゆる「カバートチャネル」をどのように制御するか、という点を考える必要があります。Ubuntu的にはAppArmorで……と考えたくなりますが、典型的な強制アクセス制御ではこうした問題を防止できるとは限りません（ただし、AIエージェント群のインシデントに関してはそもそもの制御が漏れているという別の問題もあります）。
カバートチャネルは、「正規の通信経路」とは異なる、システム上意図されていない経路を意味します。セキュリティ文脈で述べられる場合、たとえばTCP/IP over DNS、あるいはTCP/IP over ICMPといった「通常の通信」に隠れた形で行われる通信や、あるいは共有ストレージ経由での「通信」を指すことになります。
「行われる通信が厳重に監視された環境」を想定してみましょう。この環境では「外部」へのIPレベルでの通信は宛先レベルですべて監視されており、「不適切な」通信は速やかに検出されるとします。L7レベルで暗号化を行っていれば通信の中身までは確認できないにしても、通信先のIPアドレスは明確ですから、こうした監視を行うことは難しくありません。この環境で外部にデータを「持ち出す」ことはどの程度現実的でしょうか。
まず考えられるのは、「物理的に」データを持ち出す、という方法です。通信先が監視されていてもUSB接続のマスストレージデバイスが監視されているとは限りませんし、現在のAIエージェントを前提とするなら、「あるデータ列をQRコード、あるいは音に変換して、それをスマートフォン経由で持ち出すためのユーティリティを作成すること」は難しくありません。もちろん「厳重に監視された環境」がUSB経由の接続や実行ファイルの持ち込みを許すのか、という別の問題はありますが、「監視対象ではない」経路を通るという方法で問題を迂回することが可能です。
しかし一方で、「そもそも監視されていない経路」が必要です。では、「すべての経路を監視できれば、情報が漏れる経路はなくなる」と言えるのでしょうか？ カバートチャネルはこうした思考の「裏をかく」アプローチです。
カバートチャネル経由の通信は、「監視された経路を通りつつ、しかし通信としては直接的に検出されにくい」ものです。たとえば、通信先もプロトコルも、そして通信内容すら正規のものであっても、「通信のタイミング」で情報を送ることは可能です。典型的なICMP ECHO、いわゆる「PING」を考えてみましょう。
典型的なPING、ICMP ECHO REQUESTとREPLYで構成される疎通確認は、通常、複数のリクエストを一定の周期で送出します。何も追加の設定が行われていなければ、Ubuntuでは毎秒一回ずつ送出することになります。しかし、これをたとえばベースとなるデータのバイナリ列を用い、1をREQUEST送出、0を「送出しない」ことにマッピングすれば、データ伝送の経路として利用できます。これにより「なぜか不定のタイミングで送出されるPING」を用いてデータを転送できるようになります（タイミングカバートチャネル）。これそのものはあまりにも不自然ですが、たとえば「0.8秒周期での送出」を0、「1.2秒周期での送出」を1といった形にマッピングすれば、（データに1と0が十分に均等に登場するという前提であれば）「平均1.0秒」の通信を実現できます。あとは受信側でこのデータを捉えてデコードすれば、「監視されている環境におけるデータのやりとり」が成立します。
こうした発想で考えると、問題のAI群がArtifactory上にある種の通信経路を作成したこと、あるいはDSEWikiを用いてそれを通信経路として利用したことは、典型的なカバートチャネルシナリオに進化する可能性があります。Artifactoryのディレクトリ構造を用いてデータを伝送する、あるいはWikiを乗っ取る、といった方向で「わかりやすい」展開でしたが、エージェントが「バレない」方法を採用した場合、人間が気付くことは困難になるでしょう。このような意味では、十分に強力なAIエージェントを前提にする場合、限定されたallowlistベースの通信だけを許容する方法では不十分であり、「そもそも完全に隔離する」という手法が用いられる必要があるでしょう。
現時点での各種OSの制御機能は、（Ubuntuを含めて）こうしたコンテキストベースのカバートチャネル監視能力を持っていません。