fujiihda 2020/1/16 Docker Meetup Tokyo #34 (年明けLT大会) OSの機能から考える コンテナセキュリティ

2 2 @fujiihda 掲載内容は個人の見解であり、 所属する企業やコミュニティの立場、 戦略、意見を代表するものではありません

3 @fujiihda

4 4 @fujiihda 今日は赤の箇所 にフォーカス Whois • 藤井 秀行 (ふじい ひでゆき) – 役割：Infrastructure Engineer / 技術系コミュニティ運営等 – 仕事：技術調査、製品開発、SRE – 経歴：監視、OS (Linux)、コンテナ – 趣味：セキュリティ技術 fujiihda

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 無効

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 無効 今日伝えたいこと - とりあえず無効ヨクナイ！！

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 今日は赤の箇所 にフォーカス

8 8 @fujiihda (参考) コンテナリスクの内訳 • 狭義の意味でのコンテナに関連する次の 5 つ – コンテナランタイムの脆弱性 – コンテナからの無制限なネットワークアクセス – コンテナランタイムの脆弱な設定 – コンテナ上で動作するアプリケーションの脆弱性 – (計画されていない) 不正なコンテナ

9 9 @fujiihda (参考) ホスト OS リスクの内訳 • コンテナを動作させるホスト OS に関連する次の 5 つ – ホスト OS 自体に存在する脆弱性 – カーネルを共有することに起因するアイソレーションレベルの低さ – ホスト OS のコンポーネントの脆弱性 – 不適切なユーザアクセス権限 – ホスト OS のファイルシステムの改ざん

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

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

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

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 (以下略) (実行結果省略) アクションの対象の システムコール名を定義 アクションを定義 デフォルトアクション を定義

14 14 @fujiihda (参考) ありそうな質問と回答 • Q1：いずれか 1 つでも使えば、攻撃を止められるのでは？ • A1：そういうこともあるが、どれか 1 つという考え方ではなく、重ね掛けして 多層防御するという考え方をしてほしい。これらの機能は有効化することで、攻 撃可能な面を減らすことができる。なお、Dirty CoW をはじめとする Linux カーネル脆弱性やハードウェア脆弱性など、これらで止めることができない脆弱 性も存在する。根本対処であるホストを最新に保つことも忘れないでほしい。 • Q2：ベストプラクティスはどれですか？ • A2：重ね掛けを基本としてほしいが、使い分けという意味であれば、Linux ケー パビリティと seccomp は目的が違う。Linux ケーパビリティは目的別で指定で きる反面、粒度が荒すぎる。一方、seccomp は細かい設定ができるが適切に設 定するのは大変で、粒度が細かすぎる。それぞれを必要最低限とすることが好ま しいが、無効化してしまうくらいなら、デフォルト設定を試してほしい。なお、 Linux ケーパビリティのデフォルトはやや過剰なので、デフォルトから剥奪も検 討してほしい。

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