Renesas RZシリーズとArduino VENTUNO Qのサポート、Ubuntu 26.04（resolute）の開発; glibc 2.43のFTBFSの解決

Renesas RZシリーズでのcertified Ubuntu 24.04 LTS と Ubuntu Core 24 のイメージ提供

Canonicalとルネサスの協働によって、ルネサスRZ/G2L、RZ/G2LCプラットフォームにおいてcertified Ubuntu 24.04 LTS と Ubuntu Core 24のイメージの提供が行われるようになりました。GA版イメージを用いることで、Ubuntuの全機能が利用できます。

また、ルネサス製のAIアクセラレータ、DRP-AIを搭載しているRZ/V2Lプラットフォームで利用できる早期アクセス版の別イメージも提供されています。DRP-AIを利用できる、ルネサス製のAIアプリケーション（Snapベース）のチュートリアルが提供されています。

Arduino VENTUNO Qのサポート

CanonicalとArduinoの協働により、Arduino VENTUNO QでのUbuntuが利用できることがプレスリリースされています。VENTUNO QはQualcomm Dragonwing IQ-8275とSTM32H5を組み合わせたボードです。

Ubuntuは Dragonwing IQ-8275の側で動作し、Ubuntu上でネイティブに動作するArduino App Labが利用できる構造になります。この環境で「複雑な処理」を主に行い、モーターやセンサー類のような「常時動いているべきもの」はSTM32H5で動作させることによって、いわゆるIoT的な組み込み文脈で必要とされる、複雑性とリアルタイム性を両立させることができます。

resolute（Ubuntu 26.04）の開発; glibc 2.43のFTBFSの解決

UIフリーズ直前のresoluteの開発は、Powerにインストールできなかったり、あるいはglibc 2.43への移行（とC23準拠関連の問題）によってGRUB2がコンパイルできなくなったりしていますが、「⁠比較的静か」に進められています。GNOME 50もRCリリースに到達しており、このまま最終形が見えてくる見込みと言えます。

resoluteの「次」のコードネーム予想コンテストも展開され、開発終盤の「いつもの風景」が展開されています。

その他のニュース

UbuCon Asia 2026/COSCUPのCall for proposals（発表募集）が行われています。セッションで許容される言語は英語と中国語（北京語）です（資料は英語が必須だが解説は中国語（北京語）でも可⁠）⁠。

注目すべきセキュリティー的な視点：AppArmorの存在意義

Ubuntuの開発では、その終盤において、AppArmor関連の調整が行われることがあります。これは原理的な問題から開発の終盤にしかできない[1]という制約があるためでもあり、ある種の風物詩と言えるでしょう。

AppArmorのような制約の仕組みは、「⁠強制アクセス制御」と呼ばれます。今回はこの強制アクセス制御の存在意義を確認していきましょう。

Unix/Linuxシステムにおいて、root権限は「古典的には」あらゆる操作を許容する形で実装されてきています。現在のLinuxでは「Capabilities」という概念を用いて特権を細分化していますが、古代においては「rootでなければできない操作」と「一般ユーザーでもできる操作」にはそれなりの壁が存在していました（ここでの「操作」はシステムの設定を変更することだけでなく、ファイルの中身を見たりするようなものも含みます⁠）⁠。

「一般ユーザーはシステムに関することは何もできない」というデザインで、TCPやUDPの世界において、ポート番号1-1023までが「システムポート」（⁠旧称ウェルノウンポート）と呼ばれているのはこの実装によるもので、1-1023番を用いるにはroot権限が必要とされていたことに由来します。また、sudoを実行するときに表示される「We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:」で始まるメッセージは、「⁠root権限を行使できる以上は適切な訓練を受けているはずだ」という発想に基づきます。

一定のポート番号でソケットを作ったり、ファイルシステムをマウントしたり、再起動したり、あるいはシステムを構成するファイルシステムを操作したり時刻を設定したりと、「⁠システム」に関わることについて、root権限が常に必要となり、rootは適切に操作を行うだろう、という制御的なアイデアが、「⁠Discretionary Access Control（DAC; 任意アクセス制御⁠）⁠」です。

DACは、rootユーザーが適切な意図に基づいて、アクセスする範囲を制限し、悪用はしないだろう、ということが前提になっています。しかし、これはセキュリティ設計としては論外に近く、より厳格な制御が求められることになります。「⁠システム管理者がこっそり他人のメールを見ている」といった問題が起きうる環境を本格的に利用することは難しいからです。

「rootであってもできない操作があるべきだ」あるいは「より細かな制御ができるべきだ」という発想を実現するものが「Mandatory Access Control（MAC; 強制アクセス制御⁠）⁠」[2]です。LinuxにおいてはSELinuxとAppArmor、YAMA、TOMOYO Linuxあたりが知られている実装[3]で、「⁠rootであろうがなかろうが、一定の条件を満たしていなければ操作を許容しない」という動作が実現されるようになりました。

この動作が求められた理由は「rootが悪意を持ったらどうするのか」以外に、「⁠特定のプロセスが乗っ取られ、悪意あるユーザーに操作されてしまっている」という状態を制御するためでもあります。たとえばDNSデーモンがローカルユーザーのクレデンシャル、たとえばクラウド環境にアクセスするためのAPIキーを読み取る必要はおそらくないはずで、こうした動作を防ぐのが基本的な考え方です。UbuntuのAppArmorは、主にこの目的で実装されています。

一方、「⁠一般ユーザーであってもシステム特権的な操作ができても良いはずだ」という方向の実装がLinux Capabilitiesで、「⁠rootの特権そのものを分割して、一般ユーザーに部分的に付与できるようにする」というものです。

Linux CapabilitiesはそのままではAIはともかく人類には扱いにくいので、Bubblewrap（bwrap）のようなラッパーツールが存在しており、これらを用いて権限を制御するというアプローチが標準です。

このあたりの挙動は最近はコンテナやAIエージェントの文脈でも必要とされつつあり（特にAIエージェントに「できること」の制御は安全性の文脈で非常に重要です⁠）⁠、たとえばOpenAI Codexにもbwrapによる隔離が実装されたりしています。

[1] AppArmorは強制アクセス制御の実装の中で、「⁠パスベース」（⁠ファイルシステムにおけるパス）で実現されています。「⁠/usr/bin/daemonが動作に必要なファイルは/etc/daemon.confだけのはずなので、/etc以下にある他のファイルへのアクセスは許容しない」といった方式です。開発の終盤にならないと調整がしにくい理由のひとつがこれで、パス構成が決まらないと制御もできない、ということが原因です。ほかの理由は、カーネルとAppArmorはそれなりに密に結合されており、カーネルが最終版にならないと調整できないことがある、そして各種ソフトウェアの動作が確認されていく中で「過剰な制御」や「制御の不足」が明らかになっていくので、QAフェーズにしか分からないものもある、というものです。