Linux Security Summit 2019 レポート (II)

こんにちは。SIOS OSSエバンジェリスト/セキュリティ担当の面 和毅です。

前回に引き続き、Linux Security Summit 2019の二日目の様子を、簡単なダイジェストで紹介したいと思います。今回はSELinuxの話やfapolicyd等を紹介します。

尚、実際に発表に使用された資料の殆どはこちらからダウンロードできます。

  • Linux-Security-Summitのサイト
  • セッションの動画(Youtube)



    ニ日目(8月20日)

    1. Keynote: Retrospective: 26 Years of Flexible MAC - Stephen Smalley, National Security Agency
    2. 二日目の最初のセッションは、NSAに所属しておりSELinuxの開発者でもあるStephen Smalley氏から、Mandatory Access Control(MAC)の歴史とSELinuxの歴史を振り返るセションでした。

      筆者もSELinuxやMACに対する取り組みを2004年ごろから行っていますので、非常に「懐かしいなぁ」という印象が多かったセッションになりました。BLPやBibaのモデルの話、Trusted SolarisやTrusted AIX等のTrusted OSからFlukeやFlaskの話、そしてType Enforcement(TE)の実装としてLinuxを選んだ背景と、実装としてのSELinuxへの変遷などの非常に懐かしい話題と、現在Android上での「SE-Android」が動作していること、ChromeOSへの展開、組み込みや仮想化での実装などの話もされていました。

    3. NFS Support for the Linux Integrity Measurement Architecture - Chuck Lever, Oracle Corporation * Sapphire D
    4. NFSメンテなのChuck Lever氏による、NFSとIMAの組み合わせの話がされました。IMAのユースケースとして、実行可能なファイルのチェックサムを置いておき、そのファイルを実行する際にチェックサムが変更されていないかを検知してアクセス制限を掛ける、というものが挙げられます。この仕組みをネットワークを介したストレージ上でNFSを使用して実現しようとするものになります。

      具体的には、security.imaの拡張属性をfattr4_imaとして実装し、取り扱うことになります。現時点ではNFSを介したSecureBootやEVAはサポートされておらず、開発中とのことでした。

      また、現在は仕様をIETFのドラフトとして出している段階です。

    5. Application Whitelisting - Steven Grubb, Red Hat
    6. コーヒーブレイクの後は、Red Hat社のSteven Grubb氏から、Application Whitelistingの実装の話がありました。こちらは、マルウェアなどの実行防止のために、ホワイトリスト方式をfanotifyを用いて実装(fapolicydと呼んでいました)してみるというものになります。

      前提として、通常のAntiVirusではシグネチャによるブラックリスト方式を取っていますが、やはり漏れは出てしまいます。しかしMACのような完全なアクセス制御方式のものは、プログラム/リソース全てにアクセス制限がかかってしまうため、込み入った物になってしまいます。そこで、「アプリケーションのホワイトリスト化」として実行できるアプリケーションを予め定義しておき、それ以外を実行不可能にしておけばマルウェアなど怪しいものが来た時にも実行を防ぐことができ、かつ取扱も簡単になります。

      マルウェア等怪しいプログラムが実行される場合は、左のように「On disk(システム上にファイルが存在する)」のものと、右のように「Mobile code(リモートから実行される)」のに種類があります。

      攻撃者がコードを実行する際には、下記のようなオブジェクトを用いて一般ユーザとして様々な行為を行います。

      今回紹介されたfapolicydは、これらの行為を、ファイルアクセスをベースにしてモニタリングし、実行の可否を掛けるものになります。これを動作させるためにはroot特権がいらない、という所も面白い所になります。

      ファイルアクセスのモニタリングには、linux 2.6.37から実装されている「fanotify」を使用します。

      アクセスコントロールのポリシーは非常に簡潔なかたちで記載されます。

      サブジェクトには、このようなものが設定できます。

      Objectは、こちらになります。

      サンプルのポリシーは下記のようになります。

    7. Rich Authorization in a Resource Constrained Device - Kenneth Goldman, IBM
    8. 続いて、IBMのKenneth Gokdman氏により、リソースがかなり制限されている組み込みなどのデバイス上でのTPMポリシに対する認証”Policy Authorize”についての話がありました。

    9. Writing Linux Kernel Modules in Safe Rust - Geoffrey Thomas, Two Sigma Investments & Alex Gaynor, Alloy
    10. ランチを挟んで午後のセッションは、Geoffrey Thomas氏とAlex Gaynor氏による、Rustを用いたLinux Kernel Moduleの書き方からでした。

      49%のChrome、72%のFirefox、さらに81%の0day脆弱性等を引き起こしている原因は、「メモリの安全でない使用方法」から来ているそうです。また、カーネル空間でも、88%のmacOS、70%のMicrosoft製品、65%のubuntu、65%のAndroidが同様に脆弱性の原因が「メモリの安全でない使用方法」から来ているそうです。

      これらの脆弱性は、根本的にはC/C++から来ています。

      そのため、ASLRやSTACKLEAK等でシステムをハードニング化する方法がよく使われています。また、eBPFやMicrokernelなど「Isolation」の技術もよく使われています。

      しかし、これらを動作させるためにはパフォーマンス劣化という「コスト」が発生します。また、根本的な解決方法ではありません。

      そのため、Cコンパーチブルで、かつメモリ・スレッドが安全になる「Rust」を用いてLinux Kernel Moduleを作成しよう、という話になります。

      このセッションでは、Rustを用いてどのようにプログラムを書いていくか、Linux Kernel Moduleを作成していくか、の説明が行われました。

    11. Integrity Measurements and the Cruel World - Janne Karhunen, Dark Matter LLC
    12. 次に、Dark Matt LLCのJanner Karhunen氏から、IMAとコンシューマエレクトロニクスに適用した際に直面した問題についての話がありました。

      まずIMAの基本的な動作の説明がありました。IMAは可変および不変のデータを保護し、iノードレベルでの整合性を追跡して、信頼できないコードの実行を防止します。

      しかし、例えばファイルシステムはシステムクラッシュやバッテリー切れなどで破損してしまうことがあるため、書き込みが発生します。そのため、書き込み時の整合性チェックがパフォーマンスに及ぼす影響を気にする必要があります。

      また、工場出荷状態へのリセットする際に、EVMキーを破壊する事も必要になるため、サポートするように拡張したとのことでした。

    13. Tutorial: Complete Platform Attestation: Remotely Verifying the Authenticity and Integrity of your Platform’s Hardware, Firmware, and Software - Monty Wiseman & Avani Dave, General Electric
    14. (資料非公開)

      最後に、GEのMonty Wiseman氏とAvani Dave氏から、OSSツールを用いたIMAのリモート認証のチュートリアルが行われました。


    ニ日目のまとめ

    ニ日目はここまでとなります。次回は三日目の様子になります。

前へ

Linux Security Summit 2019 レポート (I)

次へ

Linux Security Summit 2019 レポート (III)