OSの機能から考えるコンテナセキュリティ / lets consider container security from os

Dd7fa413be25d8672c03a487db6a8fe6?s=47 fujiihda
January 16, 2020

OSの機能から考えるコンテナセキュリティ / lets consider container security from os

Docker Meetup Tokyo #34

Dd7fa413be25d8672c03a487db6a8fe6?s=128

fujiihda

January 16, 2020
Tweet

Transcript

  1. 4.

    4 4 @fujiihda 今日は赤の箇所 にフォーカス Whois • 藤井 秀行 (ふじい

    ひでゆき) – 役割:Infrastructure Engineer / 技術系コミュニティ運営等 – 仕事:技術調査、製品開発、SRE – 経歴:監視、OS (Linux)、コンテナ – 趣味:セキュリティ技術 fujiihda
  2. 5.

    5 5 @fujiihda # docker container run --cap-add=ALL (以下略) (または

    --privileged) (以下略) # docker container run --security-opt="seccomp=unconfined" (以下略) # vim /etc/selinux/config SELINUX=disabled (以下略) 今日伝えたいこと - よく聞く話 Linuxケー パビリティ 無効 seccomp 無効 SELinux 無効
  3. 6.

    6 6 @fujiihda # docker container run --cap-add=ALL (または --privileged)

    (以下略) # docker container run --security-opt="seccomp=unconfined" (以下略) # vim /etc/selinux/config SELINUX=disabled (以下略) Linuxケー パビリティ 無効 seccomp 無効 SELinux 無効 今日伝えたいこと - とりあえず無効ヨクナイ!!
  4. 7.

    7 7 @fujiihda コンテナ特有のセキュリティリスクと対策 • 米国国立標準技術研究所 (NIST) が “Application Container

    Security Guide” (NIST SP 800-190) とい う文書で、コンテナ特有のリスクと 対策を次の 5 つに分類 – イメージリスク:3.1 節 – レジストリリスク:3.2 節 – オーケストレータリスク:3.3 節 – コンテナリスク:3.4 節 – ホスト OS リスク:3.5 節 参照元:https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf 今日は赤の箇所 にフォーカス
  5. 8.

    8 8 @fujiihda (参考) コンテナリスクの内訳 • 狭義の意味でのコンテナに関連する次の 5 つ –

    コンテナランタイムの脆弱性 – コンテナからの無制限なネットワークアクセス – コンテナランタイムの脆弱な設定 – コンテナ上で動作するアプリケーションの脆弱性 – (計画されていない) 不正なコンテナ
  6. 9.

    9 9 @fujiihda (参考) ホスト OS リスクの内訳 • コンテナを動作させるホスト OS

    に関連する次の 5 つ – ホスト OS 自体に存在する脆弱性 – カーネルを共有することに起因するアイソレーションレベルの低さ – ホスト OS のコンポーネントの脆弱性 – 不適切なユーザアクセス権限 – ホスト OS のファイルシステムの改ざん
  7. 10.

    10 10 @fujiihda コンテナリスクとホスト OS リスクへの対処 (1/2) • 基本対処 –

    ホスト は常に最新にして、なるべく脆弱性のないようにする – コンテナ は最小構成にして、ユーザ権限 / 通信先 / ファイル システムへのアクセスも必要最低限にする – アプリケーション に脆弱性を作りこまないための努力をする – 環境 は 本番、試験、検証 などの用途に応じて分割して、 信用できない状況ではマルチテナントを避け、 ログをはじめとする監査に役立つ情報はしっかりと残す あれ?当たり前かも? (コンテナリスクとホスト OS リスクに限定しているため)
  8. 11.

    11 11 @fujiihda コンテナリスクとホスト OS リスクへの対処 (2/2) • 基本対処 +

    α (思い付いたものだけなのでもっとあるはず) – OS のセキュリティ機能を有効活用 • seccomp / Linux ケーパビリティ など – 攻撃時のふるまい検知 • Sysdig など – コンテナと親和性の高そうな仕組みの活用 • DevSecOps / 静的コード解析 など (個人的には バイナリ解析 / API のファジング) 今日は赤の箇所 にフォーカス
  9. 12.

    12 12 @fujiihda コンテナ で使える OS のセキュリティ機能の一部 • seccomp (今日紹介するのは

    mode 2 seccomp filter モード) – プロセスが利用できるシステムコールを制限できる – Docker では、コンテナ内のプロセスが実行するシステムコールを 制限できる – 定義したシステムコールが呼ばれたときの制御を、許可、拒否、 終了などのアクションから選択でき、種類だけでなく、引数との 組み合わせも定義可能 – 任意のコマンドが実行されたとしても、影響範囲を最小限に抑える ことが可能 • Linux ケーパビリティ – root 権限を目的別に約 30 個に分割した特権機能群 – 必要に応じて付与 / 剥奪 今日は赤の箇所 にフォーカス
  10. 13.

    13 13 @fujiihda seccomp の使い方のイメージ (簡易版) # vim profile.json {

    "defaultAction": "SCMP_ACT_ALLOW", "syscalls": [ { "name": "chmod", "action": "SCMP_ACT_ERRNO" }, { "name": "fchmodat", "action": "SCMP_ACT_ERRNO" } ] } # docker container run --security-opt seccomp=profile.json (以下略) (実行結果省略) アクションの対象の システムコール名を定義 アクションを定義 デフォルトアクション を定義
  11. 14.

    14 14 @fujiihda (参考) ありそうな質問と回答 • Q1:いずれか 1 つでも使えば、攻撃を止められるのでは? •

    A1:そういうこともあるが、どれか 1 つという考え方ではなく、重ね掛けして 多層防御するという考え方をしてほしい。古い例だが、CVE-2016–5195 (通称:Dirty COW、コンテナ内のユーザがホストの特権ユーザになれる) で 悪用された madvise() システムコールは、Linux ケーパビリティのデフォルト 設定でも止められるし、seccomp でも止められる。また、ホストを最新に保つ ことも重要だと考える。 • Q2:ベストプラクティスはどれですか? • A2:重ね掛けを基本としてほしいが、使い分けという意味であれば、Linux ケー パビリティと seccomp は目的が違う。Linux ケーパビリティは目的別で指定で きる反面、粒度が荒すぎる。一方、seccomp は細かい設定ができるが適切に設 定するのは大変で、粒度が細かすぎる。それぞれを必要最低限とすることが好ま しいが、無効化してしまうくらいなら、デフォルト設定を試してほしい。
  12. 15.

    15 15 @fujiihda まとめ • コンテナ特有のセキュリティリスクと対策は NIST SP 800-190 で整理されている

    • コンテナリスクとホスト OS リスクに限定すれば、 セキュリティの基本的な考え方の多くはコンテナでも 通用する (ただし、それ以外も含めたときは考慮する べきことが増える) • OS のセキュリティ機能をコンテナで使うときは – 基本的な考え方は多層防御 – 求められる要件や粒度に応じて重ね掛けしつつ使い分ける – 無効化よりデフォルト設定