こんにちは。SIOS OSSエバンジェリスト/セキュリティ担当の面 和毅です。
諸般の事情により、遅くなってしまいましたが、Linux Security Summit 2019のレポートを３回に分けてお送りします。
2019年8月21日～8月23日まで、『Open Source Summit North America 2019』が、アメリカのサンディエゴで開かれました。それに先立ち、同会場で8月19日～8月21日で、「Linux Security Summit 2019」が開かれました。
この「Linux Security Summit 2019」は、主にLinuxのカーネル周りのセキュリティについて、新しい機構の提案や既存の機構のアップデート情報を発表し、会場に集まっている専門家達と情報交換や意見をもらう場となっています。今までは2日間の開催でしたが、今年(2019)は3日間の開催となり、内容が濃いものが沢山集まっています。
今回、筆者もこのLinux Security Summit 2019に参加してきましたので、最新のLinuxのセキュリティ機構を紹介する一環として、それぞれのセッションの簡単なダイジェストを紹介したいと思います。
尚、実際に発表に使用された資料の殆どはこちらからダウンロードできます。
- Linux-Security-Summitのサイト
- セッションの動画(Youtube)
一日目(8月19日)
- Welcome
- AMD Secure Encrypted Virtualizatino Overview (AMD) / Enarx (Red Hat)
- メモリコントローラに組み込まれたAES-128エンジン
- AMD Secure Memory Encryption(SME)
- AMD Secure Encrypted Virtualization(SEV)
- AMD Secure Encrypted Virtualization –Encrypted State (SEV-ES)
- Processベース
- Intel SGX
- RISC-V Sanctum
- VMベース
- AMD SEV
- IBM PEF
- Intel MKTME
が挙げられる事の説明がありました。Ernaxは、それらのモデルに対応した「デプロイメントのフレームワーク」であり「サーバレスアプリケーションを作成するもの」になります。こちらはまだまだ開発段階ですが、少しだけデモが行われました。
- TrenchBoot: How to nicely boot system with Intel TXT and AMD SVM
- UEFI Secure Boot
- TCG Dynamic Launch
- Linux IMA
- Kernel Integrity Monitoring
- Process Integrity Monitoring
- Making Containers Safer – Stéphane Graber & Christian Brauner, Canonical Ltd.
- Kernel Runtime Security Instrumentation – KP Singh, Google
- Signals(何らかのシグナルを上げるもの)
- Audit
- Perf
- Mitigations(緩和策)
- SELinux, AppArmor(LSM)
- seccomp
- Breaking and Protecting Linux Kernel Stack – Elena Reshetova, Intel
- Securing TPM Secrets with TXT and Kernel Signatures – Paul Moore, Cisco
- Tutorial: The Why and How of libseccomp – Tom Hromatka, Oracle & Paul Moore, Cisco
- システムコールはアーキテクチャ毎に異なっている
- BPFの言語は32bitで開発されている（64bitをサポートすることも出来るがBPFコードがもっと複雑になる）
- コードが難しく、メンテナンスが困難である。
- 開発者に対して、BPFを学習しなければならない敷居が高い
まず、今回のLinux Security Summit 2019のオーガナイザーであるMicrosoft社「James Morris」氏から、簡単な挨拶がありました。
AMD社のSecurity ArchitectのDavid Kaplan氏から、AMDの提供するAMD Secure ProcessorとAES-128エンジンがメモリコントローラに載っている事などの紹介があり、Red Hat社のNathaniel McCallum氏よりTrusted Execution Environment(TEE)を提供するフレームワークである「Enarx」の説明がありました。
まず最初にAMD社のDavid氏から、AMDが提供しているハードウェアメモリ暗号化として
の振り返りがありました。AMD SME/SEV/SEV-ESに関しては2017年のThinkITで公開した記事（https://thinkit.co.jp/article/12805）でも紹介しましたが、既に実装から時間も経っており枯れた技術となっている感があります。2019年のセッションでも簡単に纏められていましたが、ハイパーバイザー側からゲストOSの情報を盗んだり制御を奪ったりする「ハイパーバイザーに対する攻撃」を防ぐためにHWレベルでメモリの暗号化を行うものになります（同ThinkITの2017年の記事参照）。また、SEVの発展形であるSEV-ESは、暗号化に加えてIntegrity(整合性)を強化したもので、ゲストのレジスタの”state”をゲストの暗号化鍵で暗号化しておき、ゲストのみがレジスタの”state”情報を変更できるようにしておくことで、ハイバーバイザーからのVM “state”に関する脆弱性を突いたような攻撃を整合性の観点から防ぐものになります（https://events.linuxfoundation.org/wp-content/uploads/2017/12/Extending-Secure-Encrypted-Virtualization-with-SEV-ES-Thomas-Lendacky-AMD.pdf）。
これらの機構がVMに関する攻撃をどの様に防ぐのかという説明がなされました。
次に、Red Hat社のNathaniel McCallum氏より、Ernaxの説明がされました。最初にハードウェアベースの信頼できる実行環境である「Trusted Execution Environment」(https://github.com/enarx/enarx.github.io/wiki/TEEs-(Trusted-Execution-Environments)
の簡単な纏めと、TPMとの違い、またTrusted Execution ModelとしてOracle社のDaniel Kiper氏とApertus Soutions社のDaniel Smith氏から、Intel TXT/AMD SMVからのセキュアブートの話とLoad Time整合性／Runtime整合性の話がありました。
まずはOracle社 Software Developerであり、Grubの アップストリームメンテなであるDaniel P. Smith氏から、Trusted Computing GroupによるSystem TrustやRoots of Trustの定義の説明と、Load Time Integrity / Runtime Integrityの違いについての説明がありました。
“System Trust”とは何か 
“Load Time Integrity”とは、ロードされた後でかつ実行される前に正当性が確立するものです。例えば
のような物が挙げられます。
Load TimeとRuntimeのIntegrityに関しての話 
一方、”Run Time Integrity”は、コンポーネントのライフサイクルでいつでも正当性が確立されるものです。例えば
等が挙げられます。
次にDaniel Kiper氏による「 Dynamic Launch」の紹介がありました。「Dynamic Launch」とは、ソフトウェア環境をスタートさせるプロセスがシステムのランタイムで任意のタイミングで起動するものになり、Intel TXTでは「Late Launch」、AMD-Vでは「Secure Startup」と呼ばれるものになります。
UEFI Secure BootからのそれぞれのTrustが何に依存して遷移しているかのTrust Chainを説明し、Dynamic LaunchがTPMやストレージ等から波及したTrustを用いていること、最終的なDynamically Launched Measured Environment(DLME)がUEFI Secure Bootから経て複数回のIntegrityチェックを経ており非常に高い「integrityの認証」を受けている状態になっていることが、それぞれの状態の遷移図を用いて説明されました。
最後にまた、Daniel P. Smith氏に説明が戻り、TrenchBootの説明がなされました。TrenchBootのアイデアは、OpenXTプロジェクトでXenをtboot(IntelのTXTとTPMを用いたブート)を用いて起動する開発を行っていた際との事です。現在はIntelのTXTとAMDのSecureBootのみのサポートですが、開発が続けられているそうです。
コーヒーブレイクを挟んで次のセッションは、CanonicalのStephane Graber氏、Christian Brauner氏による「コンテナを安全にする方法」でした。
所謂「特権コンテナ」の問題を列挙し、現実として脆弱性が発覚したためにホストOSにまで影響が及んだものを説明しました。
現状ではseccompやLSM等を使って保護するのが効果的であることを説明し、更に先の実装としてLinux Kernel Summit 2019 in Lisbonで議論された、seccompのextended-filteringが効果的に使用できることが説明されました。
また、LSMスタッキングが出来ることや、コンテナのuid/gidを縛ることが出来るsafeSetIDに加え、mount APIやKeyringの拡張、pidfd APIのようなKernelの新たな実装でコンテナのセキュリティを担保することが出来るという説明がありました。
次のセッションはGoogle社のKP Singh氏による「Kernel Runtime Security Instrumentation」でした。現在のLinux Kernelのセキュリティ機構では
に分類されます。これらのSignalとMitigationを「組み合わせて」使うことでもっと効率的にマルウェアなどを防ぐことは出来ないか、というアイデアが原点となり、「LD_PRELOAD」に着目してこれらの怪しい動きを補足して封じ込めるものとして「Kernel Runtime Security Instrumentation(KRSI)」を開発したそうです。KRSIはeBPF+LSMで実装されています。
このKRSIの動きですが、基本的にはLSMフックをbprm_check_securityに掛けて、何らかのプロセスが実行された際にユーザランドで動くeBPFのプログラムでフィルタリングを行う、というものになります。
通常であればseccomp+eBPFで実装するのが普通ですが、TOCTTOU (Time of Check to Time of Use：何かを確認してから実際に行うまでの時間差の問題）を考えた時にはLSMの方がベターと判断したそうです。
実際、パフォーマンス劣化もそれ程激しくない実装になっているようです（比較は素のKernelと、Kernel Auditを有効にした場合）
ランチタイムを挟んで午後のセッションは、まずIntelのElena Resphetova氏によるLinux Kernel Stackに関しての過去の事例と新たな提案です。
まず、過去のバッファーオーバーフローやスタックオーバーフローなどの事例が、簡単な図解とともに解説されました。
これらの詳細な動きを説明したあとで、一般的なx86_64のKernelでの防御策を例を挙げて説明しました。
しかし、今までの防御策では、スタック領域に関してアドレス情報を引き出すなどが出来てしまいます。そこで、最終的に現時点で実装されていない（PAXでは2003年に実装されていた）「スタックのランダム化」を実装することで、今までのスタックに対して行われていたスタックオーバーフロー等の攻撃を難しくできる、というものです。
CONFIG_RANDOMIZE_KSTACK_OFFSETというカーネルオプションを新たに加えることで、これを実現させています。これを行うと、やはりパフォーマンス劣化が気になる所ですが、こちらに関しては現在取り組んでいるとのことでした。目標としては2-3％の劣化程度に収めるようにしていますが、現時点では5-10%程度の劣化になっているようです。
続いて、CiscoのPaul Moore氏による「Securing TPM Secrets with TXT and Kernel Signatures 」が始まりました。これはUEFIブートに関係なく、TPM（今回のセッションではIntel TXTのみが対象)のNVRAMに格納されている鍵をどの様に保護するか、という話になります。
解決方法としては、tbootを改良してPECOFFフォーマットを用いたシグネチャの確認を実装することになります。現時点ではtbootの修正を行っているそうです。
コーヒーブレイクを挟んで最後のセッションではPaul Moore氏とOracleのTom Hromatka氏による「libseccomp」のチュートリアルでした。
まず最初にseccompの歴史(syscallのフィルタリングが何故必要なのかという話と、linux 2.6.23に実装された「seccomp mode 1」、どの辺がだめだったのかを含めて）の話がされました。
そして、Linux 3.5から導入されたseccomp mode 2(seccomp-bpf)の説明がなされました。
しかし、現時点でのseccomp mode 2(seccomp-bpf)には下記の問題があるそうです。
それらを解決するものとして、libseccomp(seccomp mode 3)を開発しているそうです。
たしかに、libseccompを用いたほうが、コードの見た目がスッキリとしています。このlibseccompは、書き方によってホワイトリスト的にもブラックリスト的にも使えるため、色々なシーンで活躍できそうです。
ここまででlibseccompの概要説明は終わり、OracleのTom Hromatka氏による、実際にコーディングを行いながらのチュートリアルが始まりました。こちらは写真で雰囲気を味わっていただくしか無いですが、色々コードを書き換えてうまく動かなかったりした際には会場から「こうしたら動く」みたいな突っ込みがたくさん入り、ワイワイガヤガヤと非常に楽しめる雰囲気でチュートリアルが終了しました。
一日目のまとめ
一日目はここまでとなります。次回は二日目の様子になります。
