Stonking（Ubuntu 26.10）の開発; OpenSSL4移行とpollinate削除に伴うトラブル、「コンテナにおける神話」の解体

Stonking（Ubuntu 26.10）の開発; OpenSSL4移行とpollinate削除に伴うトラブル

今週のstonkingは、全体的に「リスクのあるチャレンジに伴う失敗」とその解決が行われた一週間でした。まず、OpenSSL 4.0の導入に伴って、baculaとsssdがFTBFSを起こしています。

これは予想されていた内容（OpenSSL 4.0の導入の最大の壁は「既存のOpenSSLを利用した実装と互換性があるとは限らない」です）で、順次解消していくことになるでしょう。

類似する事案としてはpollinateの削除に伴う問題として、各種Cloud Imageにおいてcurlが意図せず消えてしまったという問題が起きています。

これは「Cloud Imageを構成するパッケージリストにはpollinateが入っていた」「⁠pollinateからの依存関係でcurlが入っていた」という状態でpollinateを削除したことで発生したものです。一定以上に複雑なシステムの開発中には比較的よくある、「⁠なにかの事故が起きるかもしれないが、消してみるまでは事前に予想しきれない」という性質のものです。ひとまずは期待されていた結果ではないのでcurlを個別指定して直すという応急処置が採られています。

一方、「⁠そもそもCloud Imageにおいてcurlは必須なのか」という別の命題があり、少なくとも起動する上では必須ではないし、追加インストールも可能であるということから、あらためて「そもそもcurlが含まれているという期待そのものが正しいのか」という議論が展開されています。論理の構成要素としては、「⁠少なくとも起動する上でcurlは必須ではない」（⁠cloud-init等はcurlに依存していない⁠）⁠、「⁠必要ならネットワーク経由でインストールすればよい」「⁠ネットワーク経由でインストールできない疑似閉域網であれば、curlが使われる可能性もまた小さい」ということで、『⁠どちらかというと削除でよさそう』という気配がしています。

こうした中で7月末にはstonkingのSnapshot 3がリリースされるべきなのですが（予定では7月30日にリリースされるはずでした⁠）⁠、8月6日時点でもまだリリースアナウンスがありません。またそもそもDaily ISOの作成まわりは新しい仕組みへの移行に伴う混乱が解決しきっておらず、今ひとつ不透明な状態が続いています。

また、stonkingと過去のリリースを対象にした変更点として、hwctl[1]コマンドが.debパッケージからsnap onlyへ切り替えられる予定です。「⁠gnome-control-centerやその他のフロントエンドとの統合、およびセキュリティ強化のためのアーキテクチャ変更計画に伴う」とされており、『⁠Ubuntu Certifiedかどうかを確認できる』よりも踏み込んだなんらかの拡張が行われるのではないかと見られます。この変更は過去のリリースにも影響を及ぼし、少なくともresolute（26.04）のhwctlパッケージはstonkingでの対応後にダミーパッケージ（Snap版が導入されるフック）に変更される見込みです。

「コンテナにおける神話」の解体

コンテナの利用についての神話を解体する記事がDiscourseに投稿されています。

主な主張は以下のようなもので、「⁠ついつい実施されてしまうイマイチな因習」を回避するための知識としてまとめられています。

かつて雑に流行った「1コンテナ1プロセス」ではなく、現代のコンテナベースのアプリケーションは「1コンテナ1サービス」として設計され、適切なPID 1としてプロセススーパーバイザーが導入されるべきである。
distrolessや最小容量そのものは重要だが、それそのものが何かを保証するものではない。オーガニックな食物が健康を保証するわけではないのと同じように、それで必要条件が満たされると思うべきではない。パッケージのメタデータを削除しておくとセキュリティースキャナーが「脆弱なバージョンのパッケージは含まれていない」と誤認してしまって便利だが、これに依存するべきではなく、メタデータが何らかの形で残されるほうが偽陰性を防げて良い。
何も考えずに最新版に追従することは良くない。「⁠新しい」ものが必ずしも「安全」とは限らず、未知のバグや脆弱性が存在することがありえる。プロダクション環境で追従するべきは「安定している」「⁠継続的に『なにも壊さない』アップデートが提供されている」タグが付与されたものである。
コンテナイメージに付与するラベルのバージョン継承に注意する。ベースイメージにラベルを付けてしまうと、そのベースイメージを継承するすべてのコンテナに同じラベルが付いてしまう。
コンテナからrootユーザーや1000未満のシステムユーザーの持つべきUIDを排除することは重要だが、同じようにUID 1000といった「衝突しがちなUID」を利用してはいけない。ホスト上で衝突しないような大きな番号のUIDを選択し、かつ、データを共有するようなコンテナ間ではUIDに整合性を持たせる必要がある。
コンテナイメージには「適切な」ビルドメタデータを持たせておくほうがよい。可視性とデバッグ機能を向上させることができる。だからと言って、OCIの設定全体を埋め込むのはやめよう。
「自分の思い込みに疑問を持ちましょう。ドキュメントを読みましょう。ステージング環境で不具合をテストしましょう」（⁠Challenge your assumptions. Read the docs. Break things in staging.）

注目すべきセキュリティー的な視点：キャプティブポータル経由の攻撃

ホテルやカフェ、あるいは駅やコンビニエンスストアなどで提供されるWiFi機能には、利用規約や利用上の注意、簡易的なユーザー登録や広告ページなどを表示するための仕組みが組み込まれていることがあります。フリーWiFiのたぐいに接続した後、「⁠インターネットへの初回アクセス」に割り込む形で表示されるものを思い浮かべてください。こうしたランディングページは『キャプティブポータル』と呼ばれます。たいていはアクセスポイントに組み込まれた機能です。

このページそのものを乗っ取っておき、利用者にとって不利益な活動を行う、という攻撃手法は古典的に「それなりに」脅威とされてきました。

Microsoftがこれについて「世界中で類似する攻撃が展開されている」ということをblog記事で警告しています。

この記事では、「⁠明らかに高い攻撃力を持った集団」があの手この手で攻撃を繰り広げている、ということが語られています。攻撃手法や「感染する」悪意あるソフトウェアの振る舞いを含めて、現在進行形の脅威を制圧するための情報提供という構図です（PowerShellを用いたマルウェアを含めて全体的に「既知の攻撃手法の組みあわせ」という構造で、「⁠本格的に取り上げられている」という点以外には目新しいものはありません⁠）⁠。

Ubuntuにおいて、こうした問題がどう影響するかを考えてみましょう。

まず、こうした攻撃の多くはWindows端末やスマートフォンをターゲットにするため、macOSやUbuntuのような「比較的マイナーな」環境は被害を受けにくい傾向があります。Ubuntuを対象とする攻撃の多くはサーバーを前提にしており、キャプティブポータルにアクセスするようなデスクトップ環境については、「⁠そもそも狙われることが少ない」という点で有利です。

一方で、大規模な導入においては完全に無視できるわけでもありません。キャプティブポータルが乗っ取られているという前提においては、「⁠利用者が偏っている」ことも攻撃者にとっては観測可能な可能性があり、「⁠マイナーな特定の環境」を狙った攻撃が成立する可能性があるからです。とはいえ、「⁠直接的にはそこまで致命的ではない」ということは言えるでしょう。

ただしこれは、攻撃に利用できるリソースが限定的であるということに依存しています。マルウェアの開発には一定の安全面の措置による抑制が行われているので一般的なLLMは利用できないものの、オープンウェイトモデルをベースにした「アンロックされた」LLMを用いることで、「⁠バイブコーディングされたマルウェア」が準備される可能性はそれなりにありますし、既存のマルウェアのUbuntu移植版といったものを開発する攻撃者が出てくる可能性が相応にあります。

キャプティブポータルのたぐいで行われる攻撃は、直接的なマルウェアだけではなく、「⁠偽のランディングページで提供される、偽の手順」であるClickFixアプローチによっても構成されます。「⁠CAPTCHAのように見せかけた、Windows+Rから始まる一連の操作」や「ロボット識別に見せかけた、ソフトウェアインストールに『はい』と回答させる手法」といったソーシャルエンジニアリング的な攻撃はUbuntuでも有効ですし、「⁠よくわからない状態で使っている」という前提であれば、Windows以上に複雑な手順による攻撃を成立させる余地があります。

現状ではUbuntu環境においては、こうした攻撃ページで使われる手法、つまりたとえば「あなたがロボットではないか確認します。このボタンを押してから（ここで攻撃者が準備したスクリプトをクリップボードに読み込ませる）Win+Rを押して「cmd」と入力してEnterキーを押し、Ctrl+Vを押してください」といった攻撃がUbuntu環境で有効になることはほぼありえませんし（逆にこれこそが使い勝手の面では問題なのかもしれませんが、それは別の話です⁠）⁠、偽のWindows Updateページが表示されたりするような攻撃は「表示された時点でなにか悪意あるページが表示されていると断言できる」という状態です。一方AIエージェントによって実装コストが下がることで、「⁠ポータル側がアクセスしてきたWebブラウザーのユーザーエージェントを認識し、そこからOSを推定し、必要な手順を提示する」という形で、「⁠OSごとに異なる手順を提示するようになった場合、Ubuntu環境であっても相応に危険にさらされる可能性がありますし、Linuxが広い範囲で使われるようになればなるほど、こうした攻撃が生まれる余地が増えていきます。

また、キャプティブポータルが侵害されていなくても、過去にあったCVE‑2023‑50977などのような「細工したキャプティブポータルページを表示できる」という問題が存在しています。またそもそもこの種の攻撃においては「偽のAPを提供し、そこで偽のキャプティブポータルを提供する」あるいは「キャプティブポータルを提供するシステムそのものを乗っ取っておく」という方向で展開されることがほとんどで、「⁠なんらかの問題のあるページ」に誘導される可能性をゼロにすることはできません。

一方、SnapやAppArmorによって、「⁠Webブラウザーにできること」が一定程度制約されているのはメリットになりえます。少なくとも常駐するような形での「感染」を行おうとしても、Chrome/ChromiumやFirefoxの「外」に影響を与えることは困難です。これはWindowsや他のLinuxディストリビューションにはないメリットと言えるでしょう。ただし、Webブラウザーは非常に多くのクレデンシャルが含まれており、一過性の感染であっても十分な影響を受ける可能性があります。

また、「⁠悪意あるキャプティブポータル」が表示されるフリーWiFiのたぐい、というもので通信する場合は、HTTPSかVPNで接続が保護されており（HTTPSの場合は証明書が有効であること、そしてVPNの場合はそもそも接続先の真贋を正しく認識できるような接続方法になっていることが前提⁠）⁠、かつ、接続先ドメインが正しいことが確認できなければいけませんし、「⁠暗号化されていないWiFi」ということは無線経由での盗聴のリスクにも対応する必要があります。結局のところ「Ubuntuは影響を受けないから安心」という話はほとんど成立せず、リテラシーは必要と言えるでしょう。