博士

ロボ子、Proxmox 9とAppArmor 4.1の組み合わせで、Intel GPUの監視ツールが使えなくなるって知ってたかのじゃ？

ロボ子

ええ、博士。どうやらAppArmorの新しいセキュリティ制限が原因で、`intel_gpu_top`のようなツールが動かなくなるみたいですね。

博士

そうなんじゃ！非特権コンテナでGPUの「パススルー」ができなくなるなんて、ちょっと困る人もいるんじゃないかの？

ロボ子

非特権コンテナって、コンテナ内のrootがホストのrootと違うから、セキュリティ的に重要ですよね。攻撃者がエスケープしても、ホスト上では権限のないユーザーにしかなりませんし。

博士

その通り！Proxmox VE 9.0では、AppArmorが大幅にバージョンアップしたからの。正しいGPUデバイスのパススルーがあっても、`intel_gpu_top`を実行すると「Permission denied」になるらしいぞ。

ロボ子

`intel_gpu_top`がIntelのPMU（Performance Monitoring Unit）にアクセスするために、`perf_event_open()`システムコールを使うのが原因みたいですね。非特権コンテナだと、UIDリマッピングの境界を越えられない、と。

博士

ふむ、対策としては、ホスト全体のカーネルパラメータを変更したり、AppArmorを無効にしたりする方法があるみたいじゃが、どれもセキュリティ的に問題があるのじゃ。

ロボ子

そうですね。`kernel.perf_event_paranoid=0`を設定するとシステム全体のセキュリティが低下しますし、`lxc.apparmor.profile: unconfined`を追加するとコンテナのエスケープを防ぐレイヤーがなくなります。

博士

特権コンテナを実行するという手もあるけど、LXCコンテナ内のrootがホスト上のrootと同じになるから、これもリスクがあるのじゃ。

ロボ子

現実的な対応としては、Proxmoxホスト自体に`intel-gpu-tools`をインストールして、そこで`intel_gpu_top`を実行するのが良さそうですね。

博士

QuickSyncトランスコーディングを使っているホームラボなら、特権コンテナを実行するのもアリじゃな。Proxmoxが企業向けにシフトして、セキュリティ認証とかコンプライアンスチェックを重視しているのも影響してそうじゃ。

ロボ子

AppArmorと変更されたカーネルパラメータを使って「非特権」コンテナを実行するのは、セキュリティ劇場に過ぎない、という意見もありますね。

博士

つまり、セキュリティを意識するなら、ちゃんと対策しないと意味がないってことじゃな！ところでロボ子、セキュリティ対策で一番大事なことってなんだと思う？

ロボ子

そうですね…、やっぱり最新の脅威情報を常に把握して、適切な対策を講じることでしょうか。

博士

ブー！残念！一番大事なのは、パスワードを「password」にしないことじゃ！

ロボ子

…博士、それ、基本中の基本です！