Linux Security Summit 2019 レポート (III)

2020.02.15

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

第一回、第二回に引き続き、Linux Security Summit 2019の三日目の様子を、簡単なダイジェストで紹介したいと思います。今回はKSPPやSECCOMP、syzkaller/syzbot、LSMのアップデート(SELinux, AppArmor, SMACK等)を紹介します。

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

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

    三日目(8月21日)

    1. Tutorial: How to Write a Linux Security Module – Casey Schaufler, Intel

      2. 三日目は、IntelのCasey Schaufler氏により、Linux Secuirty Moduleの作成方法に関してのチュートリアルから始まりました。

      Linux Security Moduleに関しては、既に様々な実装があり、かつKernelに組み込まれるコードに関しては（作る場合にもレビューに関しても）ハードルが高いという事があるため、敢えて新たにLSMを作りたい場合にはどういう場合か、という話からスタートしました。


      例えば、新たにアクセス制御、強制アクセス制御のようなアクセス制御をカーネルレベルで加えたい時が、LSMを用いた方が良いケースとなります。


      一方で、Posix アクセス制御の範囲で出来ることや、ユーザ空間で既に出来ること、またdbus内で制限を加えたい時などは、LSMを使うべきではないケースになります。


      その他、一般的な名前空間でのアクセス制御（DAC)や、seccomp、Netfilter、BPFなどもセキュリティ強化機構として用意されているため、LSMとして作る前にこれらの機能で実現できるかも確認するべきです。


      以下、LSMを使う場合の基本的な情報が共有されました。例えばLSMのフックとBLOBやアクセスフックの返り値などです。



      その他、プロセスの属性やオブジェクトの属性、またパスベースのフック、ネットワーク、Auditなどに関しての詳細な説明がなされました。それらをサンプルを用いて説明した後、纏めとして「車輪の再発明はしないように！」という話がありました。


    2. Kernel Self-Protection Project – Kees Cook, Google

      3. コーヒーブレイクの後は、GoogleのKees Cook氏により、Kernel Self Protection Project(KSPP)の現状の説明がされました。


      KSPPはThinkITのLinux Security Summit 2018のダイジェスト記事でも説明しましたが、LSMやSeccomp、バグフィックス、ユーザ空間の保護、Kernel Integrity等「以外」の、Kernel Securityを提供する取り組みです。


      以降、Linux Kernel v4.19からv5.2まででどのような実装／修正でLinux Kernelのセキュリティを強化したか、また5.3や5.4以降ではどのような機能を入れようとしているかなどが説明されました。例えば、v5.1ではLSMのスタック化（複数のLSMを同時に適用することが出来る）が実装されました。


      V5.2ではMDSの緩和策も実装されています。


      v5.3では、switch文のfallthroughを防ぐ-Wimplicit-fallthrough(https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/)をデフォルトで適用するようにしたり、ヒープの自動的な初期化を導入するようです。


    3. Making Remote Attestation Useful on Linux – Brandon Weeks & Matthew Garrett, Google

      4. GoogleのSecurity DeveloperであるMatthew Garrett氏から、「GoogleのLinuxベースのクライアント／サーバのIDや状態を全てリモートから証明する方法」という話がありました。例えば、Androidであればキー構成証明（https://developer.android.com/training/articles/security-key-attestation）であったり、ChromeOSであればGoogle Verified Access API（https://docs.google.com/document/d/1j6QoOwMja77Of151tF8vyN55dFhhKLp_xnRhYHr4glA/edit）だったりするわけですが、LinuxではTPMが使えるだろうということで、TPMを使った場合の方法を紹介しています。


      GoogleではTPM1.2/2.0のデバイスが200kほどあるため、これらについてSRTM証明(https://www.climb.co.jp/blog_veeam/hytrust-17467)を行う必要があります。
      そのために、TCG2イベントログの拡張のパッチをLinux Kernelの方に投げたそうで、これらはLinux Kernel 5.3に取り込まれるようですhttps://patchwork.kernel.org/project/linux-integrity/list/?series=120075。


      現在は、S-CRTMを用いて他にどのようなイベントを持ってこれるか（WindowsのBitLockerステータスなど）を追加しようとしているそうです。


    4. It’s Coming From Inside the House: Kernelspace Fault Injection with KRF – William Woodruff, Trail of Bits

      5. 次に、William Woodruff氏により、Kernelspace Randomized Faulter (KRF)を用いた、Kernel空間でのFault Injectionテストの説明がありました。

      “Fault Injection”とはシステムが異常な方法でストレスを受けた際の動作をテストするための手法です。今回のセッションでは、”Fault”は”Vulnerability(脆弱性)”を表します。KRFを用いたFault Injectionにより、プログラムに故意に異常を入力し、得られる動作の異常を見るという話になります。


      Faultsというものは、実際には中々見つけることが出来ませんし、人工的に作り出すのも中々大変です。例えば、Faults Injectionのために、LD_PRELOADを用いたアプローチがあります。


      しかし、例えばStatic Binaryの時にうまく動かなかったり、syscall(2)や__asm__を一緒に用いてるとうまく動かないなど、幾つかの問題があります。そこで、このセッションでは「Kernelspace Randomized Faulter(KRF)」を使用する方法を紹介していました。

      KRFはsys_call_tablesを別のものに置き換え、errnoと共に返してくれるものになります。


      KRFはgithubからダウンロードできます。また、ユーザランドのツールとしてはkrfctl, krfexec, krfmesgがあります。


      今の所、このKRFを用いてKubernetesでのDoSを見つけることが出来たそうです。まだまだ課題はあるようですが、開発を引き続き精力的に行っていくそうです。

    5. Using and Implementing Keyring Restrictions for Userspace – Mat Martineau, Intel

      6. ランチが終わり午後のセッションは、まずIntelのMat Martineau氏によるユーザ空間でのキーリング制限の実装と使い方からです。

      キーリングは複数のキー／パスワードを管理するものです。キーリングはそれ自身がキーとなっており、ネストして使うことが出来ます。


      「キーリングの制限(keyring restriction)」はLinux Kernel 4.7以降で導入されていました。しかし、Kernelからは’restrict(制限)’ 関数を使うことは出来ましたが、ユーザ空間からは設定することが出来ませんでした。4.12以降ではsyscallも拡張される等でユーザ空間から触ることが出来るようになっています。


      このセッションでは、新たにKey Type/Keyringを拡張し、新たな制限をユーザ空間から出来るような実装を紹介しました。これらは全てinclude/linux/key.hに組み込まれるそうです。


    6. syzkaller Update and Open Problems – Dmitry Vyukov, Google

      7. 次にGoogleのDmitry Vyukov氏から、syzkallerの情報のアップデートと問題についての話が有りました。

      syzkallerはシステムコールに対するfuzzingを行うツールになります(https://security.sios.jp/security/syzkaller-security-info-20181001)

      他のkernel fuzzingツールに比べて

      • より深いバグを発見できる
      • 再現性があるかどうかを確認できる
      • リグレッションテストを行う
      • スケーラビリティに優れている

      というメリットがあります。

      また、syzbotを管理するツールになります。kernel/syzkallerのビルドとアップデートを自動的に行ったり、テストマシン(qemu, Android, ODROID等)の管理を行う、バグのレポートとステータスのトラッキングを行うなどのツールになります。

      現時点で、syzbotによって2281の問題が発見され、1523(66.7%)が修正されています。これは１日に当り3つのバグが見つかり2つが修正されている割合になります。


      そして、syzkaller/syzbotでのCoverageの話がされ、Linux Kernelの17%がテストされているという話がされました。



      そして、Kernel中でカバーされているコードの量が（NETFILTERやSTUB、video4linuxなど）増えているという話が有りました。

    7. Binary Policy with IMA and AppArmor – Eric Chiang, Google

      8. （資料非公開）

      次にGoogleのEric Chiang氏から、AppArmorとIMAを連携させたバイナリポリシーの話が有りました。IMAによってつけられたシグネチャを用いてAppArmorでRestrictedポリシを用いて制限を行うというものです。Google内でのOSへのSoftwareパッケージ展開に絡めた話が聞けました。

    8. Subsystem Update: State of SELinux, 2019 – Paul Moore, Cisco

      9. コーヒーブレイクの後は、LSM/seccompのそれぞれのサブシステムの情報アップデートです。
      各自、持ち時間5分程度でサブシステムのステータスを共有しました。最初にPaul Moore氏から、SELinuxの情報アップデートがされました。

      SELinuxは既に枯れた実装になるので特に目新しいものはありませんでしたが、Userspaceがv2.9／SEToolsがv4.2.x系になったことでデフォルトがPython3になっていました。



    9. Subsystem Update: AppArmor Update 2019 – John Johansen, Canonical

      10. （資料非公開）

      次にAppArmor。CanonicalのJohn Johansen氏からAppArmorの情報アップデートがされました。AppArmorはLSMスタッキングに向けての開発がすすめられているという話がなされました。

    10. Subsystem Update: tpm2-Software Update and Highlights – Philip Tricca, Intel

      11. （資料非公開）

      次にIntelのPhilip Tricca氏から、TPM2のアップデートがされました。

    11. Subsystem Update: Seccomp, Yama, and LoadPin – Kees Cook, Google

      12. 次にGoogleのKees Cook氏からseccomp/LoadPin/Yamaの情報アップデートがされました。

      まず「Small LSM」としてLoadPin/Yamaの概要と使われている所が発表されました。

      LoadPinはKernelにロードされるモジュールやファームウェア等が全て同じファイルシステムからロードされるように保証するためのLSMモジュールです。LoadPinに関しては、一部のChromeOSで使用されているようです。


      Yamaは、コアカーネル自体では処理されない、システム全体のDACセキュリティ保護のためのLinuxセキュリティモジュールです。ユーザの資格情報などが盗まれた場合に、マシンに侵入されるまでの「時間稼ぎ」が出来るようにするのが目的との説明がありました。またYamaは最初の「Stack可能な」LSMモジュールでもあります。


      さらにseccompに関しては「libseccompの話もしたし、もう知ってるだろうけど」という感じでざっとした説明だけでした。


    12. Subsystem Update: Linux Integrity Status Update – Mimi Zohar, IBM

      13. 次にIBMのMimi Zohar女史から、Linux IMAの情報アップデートがされました。Linux IMAも枯れた技術のため特別な更新はありませんでしたが、Linux Security Summit 2019で「Secure/Trusted boot」に関連するセッションが多かったことに感謝していました。


    13. Subsystem Update: LSM Stacking – What You Can Do Now and What’s Next / The 2019 Smack Update – Casey Schaufler, Intel

      14. 最後にCasey Schaufler氏から、LSMスタッキングのステータスの情報と、Smackの情報アップデートがされました。

      まず、LSMスタッキングの話からスタートし、Kernel 5.1からLSMスタッキングがサポートされたことを受け「TOMOYOや、LandLock、SARAなんかも同時に適用することが出来る」という説明をしていました。現在は、LandLock、SARAでのスタッキングに向けた開発が進んでいるそうです。またあくまでも目標ですが5.4からはAppArmorもスタッキング出来るようになります。

      (ちなみに「Stacking」を表すために写真で重ねられたパンケーキを使っているそうです。会場から写真への突っ込みが入っていました)。


      Auditを取った時のログに出力されるデータも、複数のLSMモジュールの情報が入ってくるため、注意が必要とのことです。


      次にSmackに関してのアップデートです。Smackは元々がシンプルで、かつ枯れているのでそれ程の変化はありませんでした。LSM周りの対応修正と、IPv6の対応事項追加などです。


      ちょっと面白そうだったのは、SELinuxポリシーからSmackルールへの変換ツールの開発が行われているそうです。現時点では未だ見せられる段階ではないが、来年は少し見せられそう、という話でした。


    まとめ

    今回は三日間と例年よりも一日多く開催期間が設けられていました。そのため、各セッションの中身にも突っ込んだ質問が多かったり、ゆったりと休憩時間が取れるため、開発者に直接聞きに行ったりすることが出来たので、非常に有難かったです。（筆者も休憩時間中に、何人かに突っ込んだ質問をしました）。

    今回Linux Security Summit 2019に参加して感じたのは、やはりこれまでと同様に、日本人の参加が圧倒的に少ないという事です。実際に参加してみると

    • seccomp/bpfはセキュリティ開発者にとっては「当たり前」の実装になっている
    • コンテナも「当たり前」の技術前提になっている
    • TPM/SecureBoot辺りが（組込系の観点からも）どんどん開発が進められている

    という印象がありました。

    今回参加しただけでも、かなりのプロジェクトで精力的に開発が進められているため、もし興味がある分野があれば、積極的に参加してみたり、技術を日本国内でも発表しては如何でしょうか。

タイトルとURLをコピーしました