RHEL互換LinuxのAlmaLinuxがセミナーを開催。サイバートラストのセッションを主に紹介

Red Hat Enterprise Linux（RHEL）のバイナリー互換を提供するオープンソースのLinuxディストリビューションAlmaLinuxを公開する非営利団体The AlmaLinux OS Foundationが、パートナーであるサイバートラスト株式会社、株式会社インターネットイニシアティブの協力で2023年12月9日に都内で半日のセミナーを開催した。The AlmaLinux OS Foundationのチェアであるbenny Vasquez氏によるセッション、TuxCareのCEOであるIgor Seletskiy氏によるコミュニティに関する解説、サイバートラストや日本ヒューレット・パッカード合同会社のセッションなどが行われた。

イベントの公式ページにはセッションのようすを録画したYouTubeのリンクも公開されているので参照して欲しい。

●参考：イベントの公式ページ

今回はその中からVasquez氏のセッションとサイバートラストの鈴木庸陛氏による日本語のセッションを主に紹介する。

ちなみにサイバートラストがAlmaLinux OS Foundationと共同で2023年5月に開催した記者発表に関する記事は以下から参照して欲しい。

●参考：サイバートラスト、RHEL互換OSサポートビジネスへの参入とAlmaLinuxコミュニティへの参加を発表

プレゼンテーションを行うbenny Vasquez氏

ちなみにVasquez氏の「ファーストネームがBennyではなくbennyなのはどうしてか？」と質問したところ、「Bennyよりもbennyのほうの見た目が好きだから」という回答が返ってきている。本人の意向を受けて以降は大文字のBではなく小文字のbを使うことにしたい。

AlmaLinuxのソースコードチェックインのタイムラインを紹介

このスライドではAlmaLinuxのソースコードのチェックイン、つまり脆弱性などの修正がどのように推移しているのかを解説している。RHELの互換でありながらオリジナルのRHELよりも早いタイミングで修正をマージしていることを強調しているが、GitLabがCentOSからAlmaLinuxに移行したこと、IBMのメインフレームのサポート、CERNがCentOSからリプレースしたことなどが挙げられている部分にも注目したい。

なおCERNがCentOSからAlmaLinuxに移行したことは2023年4月にプレスリリースが出ている。

●参考：AlmaLinux to be Used by CERN and Fermilab in Groundbreaking Physics Experiments

サイバートラストの鈴木氏は、サイバートラストとCentOSやAlmaLinuxの関わりについて解説を行った。日本オラクルに端を発したMiracle Linuxとの関わり、CentOSの変遷、インダストリー向けのLinuxのディストリビューションとして成長したMiracle Linuxなどのビジネスサイドのエピソードだけではなく、開発リーダーが失踪したなども加えつつ、事情を良く知る業界人としての知識を披露した形になった。

CentOS、Miracle Linuxなどの変遷を解説

より重要なポイントについては次のスライドにまとめられている。

CentOSとAlmaLinuxに関する重要なマイルストーンを解説

ここでのポイントはRed Hatが発表した無償のRHEL互換であるCentOSをCentOS Streamに移行することで、無償で公開されていたエンタープライズ向けのLinuxがRHELユーザーに向けた限定的な公開となったという部分だろう。それに呼応するように、AlmaLinuxがCentOSユーザーを引き継ぐ形で公開のディストリビューションとなった。また鈴木氏によれば、現在CentOS 7を使っている多くのユーザーにとってこの先のサポートなどが不透明になっているということも大きな訴求ポイントだろう。

Miracle LinuxとAlmaLinux統合への段取りを紹介

このスライドは2023年5月の記者発表会でも同様の内容が解説されたが、今回はより詳細に解説したものとなった。産業用の組込OSとして使われているMiracle Linuxについては、AlmaLinuxにリアルタイム機能を追加したものでリプレースしていくことが説明された。

またOracle Linuxなどの他の互換ディストリビューションについてもスライドで解説。ここでは主な競合となるRocky LinuxやOpenELAについても言及しており、RHEL互換Linuxにまつわる状況が混沌としていることを示している。

RHEL互換Linuxの状況を整理

また前述のVasquez氏も説明した、コミュニティがより早く脆弱性などについて対応している点についても、具体的な内容について解説を行った。ここではCVE-2023-46847についてはRed Hatよりも数日早く修正を行っていることが見て取れる。

脆弱性に関してRocky Linuxよりも確実に早く対応できていることを紹介

また多くのユーザーが望む「どのディストリビューションを選べばいいのか？」についてもわかりやすく解説。ここではRed Hatの意向を尊重しているのがAlmaLinux、Red Hatに対抗するのがRocky Linux、Oracle Linux、SUSE Liberty Linux、OpenELAとまとめられていることがポイントだろう。あくまでもAlmaLinuxはRed Hatのルールに従っていることを強調している。

CentOS Stream以降のLinuxの選び方を解説

またAlmaLinuxが提供する価値についても1枚のスライドにまとめられている。

当たり前品質というタイトルにサイバートラストの思いが込められている

ここではSBOMについてもSPDXおよびCycloneDXのフォーマットで提供することが解説されている。なおSBOMについては、別のセッションでサイバートラストのMatthias Kruk氏が解説を行っている。それについても簡単に紹介したい。

「SBOMはユーザーが作成すること」を解説するKruk氏

ここでKruk氏は、SBOMはユーザーが作成することを強調。しかし実際にはシステムインテグレーターなどによって納入されたシステムについて、脆弱性の対応などがインテグレーター側のサービスとして提供されているような場合には現実的ではないのでは？ と質問を行ったが、回答はユーザーが行うべきというものだった。

これについて後日、サイバートラストが提供するライブパッチのサービスとの関係も含めて改めて質問を行った。以下の回答を参照して欲しい。

質問 1：SBOMを作成するのはユーザーだというのはサイバートラストのスタンスとして理解したが、サイバートラストが提供するライブパッチを利用してパッチを適用した際にサーバーのSBOMに反映するためにはどのようにするのか？

回答 1：ライブパッチサービスで適用したパッチの内容をSBOMに反映する方法はない。ライブパッチサービスでは脆弱性管理の観点から各脆弱性スキャナーがサーバーに適用したライブパッチを識別するためのOVALデータを提供している。またライブパッチが対処した脆弱性リスト（CVELIST）も提供している。

質問 2：利用するAlmaLinuxのイメージに対しても、ライブパッチを適用した後に同じパッチを含む最新のOSイメージを更新して再起動した際にデグレーションしないようにする必要があるという理解で良いか？

回答 2：大前提としてシステム全体のSBOMはユーザー側で作成、管理する必要がある。AlmaLinuxでシステムを構築する場合、インストールされたパッケージごとにSBOM作成ツールでSBOMを作成してシステム全体のSBOMを作成する。システム運用時にパッケージアップデートした場合は、該当する更新されたパッケージのSBOMを再作成し、更新する必要がある。そのうえでライブパッチサービスは、提供するライブパッチセット自体のSBOM、ライブパッチを適用したパッケージのSBOMをいずれも提供しない。

ライブパッチサービスは既存のSBOM内の修正対象のパッケージに対して自動的に情報を追記、削除するような機能は提供していない。ライブパッチサービスはライブパッチセットが修正した脆弱性について、OVALデータと脆弱性リストを提供する。

「SBOMの管理の観点」から上記ライブパッチサービスを考えると、ライブパッチサービスが提供するOVALや脆弱性リストの情報をSBOM内のパッケージコンポーネントに拡張情報として、あるいはVEXなどに追記することで、SBOMを利用した脆弱性管理に役立つかもしれない。ただし、ライブパッチセットは通常のパッケージ更新タイミングより頻繁に更新されるため、追記した情報も新しいライブパッチセットがシステムに適応されたタイミングで都度情報を更新する必要がある。

ライブパッチは揮発性のパッチなので、OSを再起動するとパッチを適用する前に戻ってしまう。従ってSBOMに記載している内容とシステムの状態に一時的にギャップが発生することを許容するSBOMの設計が必要となる。結論として、SBOMにライブパッチサービスの情報を追記する場合はライブパッチの特性をふまえてSBOMを設計、管理することがユーザーサイドに要求される。

サイバートラストが提供する付加価値としてのライブパッチは無停止で脆弱性を修正することができる機能だが、SBOMの観点から見るとユーザーサイドでの運用は難しくなると思われる。無停止で脆弱性を解消できることを利点として採用するならば、再起動時のデグレーションを回避する仕組みを考えることは必須だろう。