IMAポリシーはどこまで信頼できるか

Acompanyは、データを暗号化したまま処理できるConfidential Computingをコア技術の一つに据え、研究開発からプロダクト開発までを進めている。弊社では、その実用化に欠かせないRemote Attestation（リモートアテステーション）や完全性検証に関する研究開発に取り組んでいる。

Confidential Computingを実用化するうえで重要になるのは、「環境が隔離されている」ことに加えて、その隔離された環境の中で、期待したソフトウェアが、期待した通りに動いているかを、ユーザーがリモートから検証できることだ。

本記事では、この「中で何が動いているか」を保証する仕組みのうち、LinuxカーネルのIMA（Integrity Measurement Architecture）によるランタイムの完全性と、さらにその一歩奥にあるIMAポリシー自体をどう測定するかという課題を扱う。

リモートで動くソフトウェアの正しさを、どう証明するか

コンピューターを起動するとき、多くの仕組みで「正しいものが立ち上がること」を確かめることができる。OSイメージには署名があり、Secure Bootはブートローダーからカーネルまでの一連の起動コンポーネントが改竄されていないことを検証する。またMeasured Bootは、起動の各段階で読み込まれるコンポーネントを測定し、その記録をTPMに残していく。こちらは起動を止めるのではなく、「何が起動したか」を後から検証できる証跡を残す仕組みである。

ところが、これらが保証してくれるのは「起動が完了する瞬間まで」である。システムが動き出した後、そこで実行されるバイナリや読み込まれる設定ファイルが本当に意図通りのものか、誰かに差し替えられていないか。こうしたランタイム（実行時）の完全性は、起動時の検証とは別の問題として残り続ける。

さらに近年は、クラウド事業者ですら中を覗けないハードウェア隔離環境、Confidential VM（CVM）も使えるようになった。ただしCVMが保証するのは、あくまで「箱そのものの隔離」であり、箱の中で起動後に何が動いたかまでは、それだけでは分からない。

このランタイムの完全性を担うのが、LinuxカーネルのIMA（Integrity Measurement Architecture）という機能である。IMAは、システム上で実行・読み込みされるファイルを測定し、その記録を改竄できない形で残す。そしてその記録は、リモートのユーザーが「このシステムでは確かにこれらが動いた」と確認するための材料になる。

IMAの機能を一通り押さえたうえで、測定の仕組みそのものに残る問題と、それを塞ごうとする最新のカーネル開発の動向まで踏み込んでいく。

IMAとは？

何ができるか

IMA（Integrity Measurement Architecture）は、システム上でファイルが実行・読み込みされる際に、そのファイルを 測定（measure）するLinuxカーネルのサブシステムである。

測定の流れはこうだ。対象ファイルが読み込まれると、IMAはその内容のハッシュを計算する。そのハッシュを measurement log（測定ログ、　/sys/kernel/security/ima/ascii_runtime_measurementsなどから参照できる）に追記し、同時に同じ値をTPMの PCR（Platform Configuration Register）をextendすることで記録する[1]。

PCRはextend操作（既存値と新しい値をハッシュで連結していく一方向の積み上げ）でしか更新できず、途中の値を後から書き換えることはできない。つまり「何が、どの順番で測定されたか」が改竄不能な形でTPMに刻まれる。measurement logが「人間が読める明細」だとすれば、PCRは「その明細が改竄されていないことを保証する封印」にあたる。

IMAにはもう一つ、検証（appraise）という機能もある。これは測定したハッシュを期待する値と照合し、一致しなければファイルのアクセスや実行を拒否する機能だ[1]。measureが「記録する」のに対し、appraiseは「止める」。本記事で主に扱うのは前者のmeasureだが、両者はIMAの両輪として押さえておきたい。

何に使えるか

最も基本的な用途は改竄検知である。測定された値を期待値と突き合わせれば、想定外のバイナリや書き換えられた設定ファイルが動いた事実を検知できる。

クラウドコンピューティングの文脈で、これが真価を発揮するのは、リモートアテステーション（Remote Attestation, RA）と組み合わせたときである。PCRに刻まれた測定値とmeasurement logをリモートのユーザーに提示すれば、ユーザーは「そのシステムで確かにこれらのファイルが、この順序で動いた」を手元で検証できる。ローカルでの検知に留まらず、第三者が遠隔から完全性を確認できるようになる。なおPCR値の完全性はTPMあるいはvTPMによる署名を検証することで保証できる。

CVMが箱の隔離を保証し、IMA＋RAが箱の中で何が起動され、起動後に何が動いたかを保証する。両者が揃ってはじめて、「信頼できる隔離環境で、信頼できるソフトウェアが動いている」と遠隔から確認することができる。

IMAポリシーとは？

前章で「IMAはファイルを測定する」と述べたが、IMAはシステム上のあらゆるファイルを片端から測定するわけではない。何を、どの操作のときに測定（あるいは検証）するか、あるいはしないかを決めるルール集がIMAポリシーである。ポリシーがなければIMAは何も測定しない。

デフォルトポリシー

これはカーネルにあらかじめ用意されたビルトインのポリシーである。カーネルコマンドラインでima_policy=tcbのように指定すると有効化される[1]。tcbポリシーは、実行されるファイルやカーネルモジュール、メモリにマップされる実行可能ファイルなど、システムのTCB（Trusted Computing Base）に関わる読み込みを測定対象とする。

カスタムポリシー

実運用では、測定・検証の要件はカスタムポリシーで定義するのが基本だ。ビルトインのポリシーは起動初期の暫定的なルールにすぎず、独自に記述したルール集を投入して本来の要件を反映させる。

投入のタイミングには大きく二通りある。

起動時 — ポリシーファイルを/etc/ima/ima-policyに置いておくと、systemdなどのユーザーランドの初期化プログラムが、起動シーケンスの早い段階でその内容を/sys/kernel/security/ima/policyに投入する。

実行時 — システムが稼働した後にecho "measure func=BPRM_CHECK" > /sys/kernel/security/ima/policyのように、ルールを直接書き込むことができる。

ここで押さえておきたい挙動がある。カーネルにとって初回のポリシーロードは、ビルトインポリシーを「置き換える」。追加ではなく置き換えなので、ブートコマンドラインで有効化していたビルトインのmeasure/appraiseルールは、この初回ロードの時点ですべて失われる。そして2回目以降のロードは（許可されていれば）既存ポリシーへの「追記」になる。

ポリシーは後から更新できるのか —CONFIG_IMA_WRITE_POLICY

ポリシーを更新できる回数は、カーネルのコンパイルオプションCONFIG_IMA_WRITE_POLICYに依存する[1]。

• CONFIG_IMA_WRITE_POLICY=n：更新は1回だけ許可される。この1回（起動時カスタムポリシーか、実行時カスタムポリシーのいずれか）で確定し、以降の書き込みは拒否される（Permission denied）。
• CONFIG_IMA_WRITE_POLICY=y：稼働中に複数回の更新が可能になる。

注意したいのは、=nであってもポリシーは一度は書き換えられることである。そしてその1回は前述の通りビルトインポリシーの「置き換え」であり、デフォルトのmeasure/appraiseルールはそこで失われる。「=nだから初期状態のまま固定されて安全」ではない。

IMAポリシーの測定問題

ここまでで、IMAがファイルを測定し、その記録をPCRに積み上げること、そして「何を測定するか」を決めるのがIMAポリシーであることを見てきた。ここで一つ、根本的な問いが立ち上がる。

ポリシーは「何を、どの操作のときに測定するか」を決める基準そのものである。だとすれば、測定値がいくら正しく積まれていても、その基準であるポリシー自体が正しいと検証できなければ、測定全体の信頼が揺らぐ。たとえばリモートのユーザーが「測定ログにマルウェアのハッシュは無かった」と確認できたとしても、そのとき効いていたポリシーが「実行ファイルを測定しない」ものに差し替えられていたなら、その確認には何の意味もない。

測定の番人であるポリシー自身は、測定されているのか。これが本章で扱う問題である。

実行時カスタムポリシーは測定チェーンに乗らない

前章で見た通り、カスタムポリシーは実行時に　/sys/kernel/security/ima/policyへ直接投入できる。運用上は柔軟で便利な反面、アテステーションの観点では穴になる。

実行時に投入したポリシーは、どこから来たのかを測定チェーンが捉えていない。仮にポリシーファイルをrootfs上に置いてそれを読み込ませたとしても、そのrootfs自体が測定チェーンに乗っていなければ、リモートのユーザーには「実際にどんな基準で測定が行われていたか」を検証する術がない。

これは前段で述べた問題そのものである。測定の基準が検証できなければ、その基準のもとで積まれた測定値の信頼も担保できない。

initramfsに埋めてアテステーションチェーンに繋ぐ

この問題への実践的なアプローチが、カスタムポリシーファイルをinitramfsに埋め込むことである。

UKI（Unified Kernel Image）として、カーネル・initramfs・カーネルコマンドラインなどを一つの署名付きイメージにまとめる構成では、initramfsもまた起動時の測定対象となり、その値はPCRに記録される。ポリシーファイルをこの initramfsの中に置いておけば、ポリシーはUKIごと測定チェーンに乗り、PCRにバインドされる。リモートのユーザーは、PCRの値を検証することで「このポリシーが使われる構成で起動した」ことを確認できる。

さらにCONFIG_IMA_WRITE_POLICY=nと組み合わせれば、起動後にポリシーが書き換えられる余地も封じられる。測定チェーンに乗った既知のポリシーが、起動後も変更されないことが担保される。

なお、ポリシーをinitramfsに埋め込むこのアプローチは、Embedded Linuxの世界では確立された手法のようである。Yocto/OpenEmbeddedのmeta-securityレイヤーは、カスタムIMAポリシーをinitramfs内に配置し、専用の initramfsモジュールでロードする仕組みを提供している[2]。rootfsのinit自体の完全性がカーネルによって検証される点が、rootfs上のinitでロードする方式に対する利点とされている。

ただし、この方法で保証できるのはあくまで「そのポリシーファイルがinitramfsの中に置いてあること」までである。実際にそのポリシーが起動シーケンスの中で正しくロードされたかどうかは、initramfs内の起動スクリプトが期待通りに動作することへの信頼に依存する。スクリプトの不備や起動時の予期せぬエラーでロードに失敗していても、PCR値からはその失敗を読み取れない。「置いてあること」と「実際に効いていること」の間には、埋めきれない隙間が残る。

measure func=POLICY_CHECKの落とし穴

では、「ポリシーが実際に投入された事実」そのものを測定する仕組みはないのか。実はIMAにはmeasure func=POLICY_CHECKという、まさにそれを狙った測定ルールがある[1]。tcbなどのビルトインポリシーにも含まれており、ポリシーが投入される場面を測定対象にする。

ところが、このルールには二つの落とし穴がある。

一つ目は、投入方法によって測定されたりされなかったりすることである。ポリシーの投入には二通りの書き方がある[1]。

• パス渡し：echo /path/to/policy > /sys/kernel/security/ima/policyのように、ポリシーファイルのパスを書き込む。先頭の/によって、カーネルはこれをファイル名と解釈し、ファイル全体を読み込む。
• 本文渡し：echo "measure func=BPRM_CHECK" > /sys/kernel/security/ima/policyのように、ルール文字列そのものを書き込む。カーネルは行単位でルールをパースする。

パス渡し・本文渡しという言葉は、解説のためにこの記事でのみ使用する用語である。

POLICY_CHECKによる測定は、カーネルがファイルを読み込む経路にフックされている。このため、パス渡しはこの経路を通って測定されるが、本文渡しには「読み込むべきファイル」が存在せず、経路に乗らないため測定されない。

筆者が調査した範囲では、IMA のドキュメント[1]がfunc=POLICY_CHECKについて説明しているのは、appraise（署名検証）の挙動についてだけでありmeasure func=POLICY_CHECKが具体的に何を測定するのかは、ドキュメントには明文化されていない。この挙動は、カーネルソースの該当経路を追い、実機で動作を観測することで確認した。

二つ目は、そもそも測定している対象がずれていることである。POLICY_CHECKが測定するのは/sys/kernel/security/ima/policyへ書き込まれようとしたコンテンツである。これは、実際にロードされて効力を持ったポリシーとは限らない。投入されたコンテンツがパースの段階で弾かれて適用されなかった場合でも、測定の対象になるのはあくまで「投入を試みた入力」である。本当に検証したいのは「いま実際に効いているポリシー」であるはずなのに、POLICY_CHECKはその一歩手前の入力を捉えているにすぎない。この測定対象のずれもまた、カーネルソースの該当処理を追うことで確認したものである。

IMA の最新動向

この二つの穴を塞ごうとする動きが、Enrico Bravi氏によってlinux-integrityメーリングリストに投稿されたパッチシリーズだ[3]。アプローチは二段構えになっており、先に挙げた二つの問題にそれぞれ対応する。

Patch #1は、有効化された後のポリシーを、そのテキスト表現として測定する。これにより「実際にロードされて効いているポリシー」そのものが測定対象になる。POLICY_CHECKが捉えられなかった「対象のずれ」を埋めるものである。これはPOLICY_CHECKとは別のルールであるCRITICAL_DATAという経路で測定する。

Patch #2は、securityfsに書き込まれた入力バッファを、受理されたか拒否されたかにかかわらず測定しPOLICY_CHECKで捕捉できるようにする。本文渡しが測定経路に乗らなかった「一つ目の穴」を塞ぐものだ。

ただし、これらはあくまでRFC段階であり、このままマージされると確定したものではない。また、仮にマージされたとしても、有効化の経路がアーキテクチャ固有ポリシー（arch policy）に依存するなど、特定の条件下でしか機能しない制約も存在しており、現時点で全面的に頼れる解決策とは言えない。

結局どうすればいいのか？

ここまでで、ポリシーの真正性を担保する二つのアプローチを見た。「ロードされたポリシーを直接測定する方法」と、「ポリシーをinitramfsに埋め込んで間接的にバインドする方法」である。前者にあたるのは、Braviパッチが追加しようとしているCRITICAL_DATAによる有効化後ポリシーの測定である。POLICY_CHECKは、測定対象が「投入されようとしたコンテンツ」であり「ロードされたポリシーの直接測定」ではない。

原理的には、ポリシーを直接測定する方法のほうが明確に優れている。実際にロードされたポリシーそのものを測定対象にできるため直接的であり、initramfsの起動スクリプトが正しく動作することへの信頼を必要としない。先ほど述べた「置いてあること」と「効いていること」の隙間が、原理上は埋まる。

しかし実用の観点では、ロードされたポリシーを直接測定する仕組みは、現時点ではまだ使えない。前述の通り、それを実現するBraviパッチはRFC段階であり、マージされたとしても特定の条件下でしか機能しない。

したがって現状では、ポリシーの真正性をアテステーションチェーンに繋ぐ方法としては、initramfsにバインドするのが現実的な手段だと言えるだろう。直接測定が原理的に優れていることを理解した上で、現時点ではinitramfsバインドを採るというのが、現実的な落とし所になる。

まとめ

本記事では、IMAがファイルを測定してPCRに記録する基本的な仕組みと、その測定対象を規定するのがIMAポリシーであることを解説したうえで、「測定の番人であるIMAポリシー自身は、測定されているのか」という問いを掘り下げてきた。

現時点での答えは、「完全には測定されていない」だ。IMAはファイルの完全性を強力に保証する一方で、その測定の基準であるポリシー自体をアテステーションチェーンに繋ぐ部分には、まだ埋めきれない隙間が残っている。

実務的な結論としては、ロードされたポリシーを直接測定するのが原理的には筋だが、それを実現する手段はまだ実用に至っていない。したがって現時点で取れる現実解は、ポリシーをinitramfsに埋め込んでPCRにバインドする方法になる。

IMAは完全性測定の強力な基盤だが、その測定の基準であるポリシー自体をどう測定チェーンに繋ぐかは、まだ発展途上の領域だ。本記事で見たPOLICY_CHECKの挙動やBraviパッチの議論は、その最前線で何が問われているかを示している。CVM上で実用的な完全性保証を組み上げようとすると「ポリシーをどう検証可能にするか」という問いは避けて通れないものになる。

参考文献

[1] "IMA Policy", Linux IMA Documentation. https://ima-doc.readthedocs.io/en/latest/ima-policy.html

[2] meta-security (meta-integrity layer), The Yocto Project. https://git.yoctoproject.org/meta-security

[3] Enrico Bravi, "[RFC][PATCH v3 0/2] ima: measure write on securityfs policy file",
linux-integrity mailing list, 2026年5月26日. https://www.mail-archive.com/linux-integrity@vger.kernel.org/msg05918.html