resolute(Ubuntu 26.04)の開発; Betaと「次」へ向けた作業
resolute(Ubuntu 26.04)の開発はベータリリースに進み 、あわせて「変更することだけが決まっている」項目が徐々に確定しつつあります。
まず、カーネルについて6.20(7.0になる見込み)の準備が進められ、変更点のまとめ が準備されました。またなんとなく釈然としない部分はありつつ、年齢確認関連 の機能が投入されました。これにより、「 OS側がアプリケーションに年齢情報を伝えなくてはならない」というタイプの法律が存在する地域でも利用を継続できるようになるはずです。ちなみにこの裏ではUIコンポーネント(アイコンや起動時スプラッシュ)のいろいろ な改修 と凝視しないとわからないUIアニメーションの投入 が行われています。
次に、ISOイメージのQAが旧来のISO Trackerから、新規に準備されたtests.ubuntu.com ベースで実施できる状態になりました。これにより、26.04 LTSが無事にテストされてからリリースできる状態になりそうです(「 以前の環境でテストするの? 新しいのでテストするの?」というような混乱が生まれる余地はまだ残っていますが、まあ、これはいつものことです) 。
スタイル変更という意味では、これまでDiscourse上で展開されていたリリースノートが、documentation.ubuntu.comベース で公開される方向になりました。ベースはRead the Docs で、実体はGitHub上のSphinxドキュメント です。Discourseでのリリースノート作成作業は現実的にかなり厳しいものがある という状態だったので、これは正常な変化と言えるでしょう。
ちなみにリリースノート本体はかなり充実しつつあり、Dracutの移行 がどうも今回もデフォルトの切り替えだけ 、といったことが読み取れます。
“CrackArmor”への対応
Ubuntuに搭載された強制アクセス制御 機構であるAppArmor において、「 CrackArmor」と呼ばれる脆弱性が公表 されました。さらに、ローカルユーザーの権限昇格の攻撃点として利用できる 脆弱性が発見されました。実際にはAppArmorだけでなく、他のいくつかのプログラム(suやsudo)を併用して特権を奪取するもので単独のエラーとは言いにくいのですが、rootを取ることが可能です。
すでに修正が提供 されているので、ユーザーとして実施するべき作業はシステムをアップデートすることです。攻撃はあくまでローカルユーザーからの特権奪取なので、ネットワーク越しに攻撃するには「まず一般ユーザーの権限を奪取する」というフェーズが含まれます。
なお、「 sudo-rs, the Rust-rewrite of sudo available by default in Ubuntu Questing Quokka (25.10) and later, is not affected because of the design decision to not send email notifications.」( Ubuntu Questing Quokka (25.10)以降でデフォルトで利用可能なsudoのRustリライト版であるsudo-rsは、メール通知を送信しないという設計上の決定により、この影響を受けません)というのがそれなりにポイントで、( Rustにしていることはあまり関係なく)「 そもそも攻撃界面になりうるが、利用者がそこまで多くないであろう場所は未実装にしておく」というアプローチによって回避できているという結果になっています。リファクタリングのメリットと言えるでしょう。
その他のニュース
注目すべきセキュリティー的な視点: 塩漬けに挑む
コンテナを「適切な温度にしてから」デプロイするべき、という話に関連して、「 適切な温度にする」発想の行き着いてしまった形として、「 塩漬け」と呼ばれる文化があります。一度デプロイが完了したシステムについて、二度とアップデートせずそのまま運用を続けるのが基本的なモデルです。
これは色々な事例で発生する、やむにやまれぬ最後の手段なのですが、場合によっては定石として最初に採用されてしまうようなこともありえます。多くの場合は、QAにかかるコストを圧縮したいという動機になるでしょう。
そもそも実際の塩漬けにおいては、あくまで十分な量の塩を投入し、それによって微生物やいろいろな不快害虫が発生しない状態を作り出す、あるいは一定のコントロールされた発酵を作り出すといった目的があります。この原理からして、塩が足りない塩漬けは、ただの腐敗物や不快害虫の生成装置にしかならない、忌避されるべきものです。
IT業界でよく見かけられる「塩漬け」は、多くが塩分濃度の足りない塩漬けになっていることがあります。つまり、塩漬けと称される腐敗物に蓋をしているだけ、ということも多々あり得ます。これを何とかする方法は、塩漬けにおいて高度な技術力を投入する、という方法しかありません。しかし一方、塩漬けが真剣に必要になるケースというのもあり得るものの、恥ずべきもの、というニュアンスが強いため、「 具体的にどういうことが起きえるか」あるいは「どうするべきか」を考える起点がそこまで多くありません。
もちろん、閉鎖環境であれば一切アップデートをしないという戦術もありえるのですが、一方、真の閉鎖環境がそうそう存在するかという命題もあり、どうあるべきなのかという点も検討されるべきです。
今回は、Ubuntuを塩漬けする「最低条件」を考えてみましょう。
証明書のトラストストア
まず絶対に必要なのが、証明書を利用できる環境を適切に管理できることです。証明書を適切に管理するということは、すなわち、OSなりミドルウェアなりのトラストストアにあるルート証明書を適切にアップデートし続けるということを意味します。もちろん接続先となる相手がごく限定的な場合は、TrustStoreの更新をしなくてもよいかもしれません。すでにこの時点で、「 できれば放置したい」という塩漬けの裏にある望みが破壊されているような気がしますが、あまり気にせず次へ行きましょう。
tzdata
次に問題になるのは、タイムゾーン関連の情報を格納するtzdataです。もちろん、これも単一のタイムゾーンしか使わないという話であれば問題はないかもしれませんが、国際化されたアプリケーションであれば、こちらも定期的にアップデートする必要があります。
暗号系ライブラリ
これもまた、時間の経過によって徐々に風化していく属性を持っています。こちらも適切にアップデートしていく必要があります。場合によっては、アプリケーションが利用する暗号系を更新する必要があるでしょう。このあたりでもう現実性が失われてきている気がしますが、やはり気にせず進みます。
「外から」の通信からの隔離
塩漬けを行う以上、多くのソフトウェアが脆弱性を抱えたまま動作することになります。外部の通信から十分に隔離されている、あるいは外部の通信がすべて管理されている必要があります。
封印を解除するときの手順が決められている
どうしても「塩漬け」を行わないといけない場合であっても、やむにやまれず、いろいろなものをアップデートする(つまり塩漬けを解除する)必要が出てくることがあります。
この場合、以下の内容が整理されている必要があるでしょう。
どのような塩漬けが行われていたのか、その狙いと意義
塩漬けを解除するときに、どのようなリスクがあるのか、どうする予定だったのか
これらが整理されていない場合、アップデートを担当する人間はある種の「黒ひげ危機一発」的な爆弾解体をする羽目になり、かつて塩漬けを担当した人間を心から呪いまくるという、悲しい光景が展開することになります。
……というような問題を考えることと、実際にアップデートを適切な周期で適用すること、どちらがより効率的なのか、というのはそれなり以上に考える価値がありそうです。