https://connpass.com/event/84151/

1. Copyright©2018 NTT Corp. All Rights Reserved.
NTT ソフトウェアイノベーションセンタ
須田 瑛大
Rootlessコンテナ
ContainerSIG LT (2018/05/28)
https://slideshare.net/AkihiroSuda

2. 2
Copyright©2018 NTT Corp. All Rights Reserved.
• コンテナ関連OSSのメンテナ(いわゆるコミッタ)を務めている
• Docker Moby メンテナ (2016年11月～)
• 2017年4月，OSSプロジェクトとしてのDockerはMobyに名前が変わった
• 商用製品としてのDockerはMobyをベースとして開発されている
• Moby BuildKitメンテナ (2017年夏 プロジェクト発足時～)
• 次世代 `docker build`
• CNCF containerdメンテナ (2017年9月～)
• Kubernetesなどで利用できる次世代コンテナランタイム
: ≒ :
RHEL Fedora
自己紹介

3. 3
Copyright©2018 NTT Corp. All Rights Reserved.
コンテナは本当に安全なのか?
ユーザがデプロイするアプリケーション
オーケストレータ (例: Kubernetes)
高位ランタイム (例: containerd)
低位ランタイム (例: runc)
カーネル
VM
ハードウェア
コンテナ技術での対策は一般に
困難 (例: Meltdown)
バグを含んでいても，コンテナを
用いることで影響を限定できる

4. 4
Copyright©2018 NTT Corp. All Rights Reserved.
コンテナは本当に安全なのか?
課題
ユーザがデプロイするアプリケーション
オーケストレータ (例: Kubernetes)
高位ランタイム (例: containerd)
低位ランタイム (例: runc)
カーネル
VM
ハードウェア

5. 5
Copyright©2018 NTT Corp. All Rights Reserved.
• Kubernetes CVE-2017-1002101
• volumeMounts.subPath 内のシンボリックリンクの扱いのバグのため，悪意を持った
コンテナがホストのファイルシステムをマウントすることが可能
• Kubernetes CVE-2017-1002102
• secret, configMap及びdownward APIの扱いのバグのため，悪意を持ったコンテナ
がホストのファイルシステム上の任意のファイルを削除することが可能
オーケストレータのバグの例
https://kubernetes.io/blog/2018/04/04/fixing-subpath-volume-vulnerability/
https://github.com/kubernetes/kubernetes/issues/60814

6. 6
Copyright©2018 NTT Corp. All Rights Reserved.
• Docker CVE-2014-9357
• LZMAアーカイブの扱いのバグのため，悪意を持ったコンテナがホスト上で任意のバイ
ナリを実行可能
• containerd #2001
• イメージレイヤの扱いのバグのため，悪意を持ったコンテナが(起動されなくてもpull
されるだけで)ホスト上の/tmpを削除可能
• runc CVE-2016-9962
• プロセスの属性設定の扱いのバグのため，悪意を持ったコンテナが，`runc exec`で
新たに起動されたプロセスのファイルディスクリプタを奪うことが可能
• runc CVE-2016-3697
• UID文字列のパーズのバグのため，悪意を持ったコンテナが，ユーザの意図しないUID
で動作することが可能
ランタイムのバグの例

7. 7
Copyright©2018 NTT Corp. All Rights Reserved.
• コンテナランタイムやオーケストレータを，非root権限で動かすことで，これら
のバグの影響範囲を限定できる
• runc: 既に凡そrootlessで動く
• 後述の通り，一部はSUIDバイナリ
を使う必要がある
• containerd: runc側のパッチのマージ待ち
• POCは既に動いている
• cri-o: 未着手
• Kubernetes, Docker: 未着手
rootless container
既にimg (イメージビルダ)や
Guardian (Clound Foundryのランタイム層)で
用いられている
注: Dockerの--userns-remapは似ているが別の機能
(コンテナ内のrootを別ユーザにマップするが，
Docker daemon自体はrootで動く)

8. 8
Copyright©2018 NTT Corp. All Rights Reserved.
• コンテナに複数のUID・GIDを割り当てる方法
• aptなどの実行に必要
• 方法が2つある
• SUIDビットつきのnewuidmap, newgidmapを使う
→ 真のrootlessではない (セキュリティ上の懸念あり)
• ptraceで複数のUID・GIDをエミュレートする
→ 遅い (が，seccompでアクセラレーション可能)
• 理想的には，そもそもコンテナは単一のUID・GIDだけで動作すべき
• ネットワークのルーティング
• initial netnsとrootless netnsとをつなぐvethが作れないので，IPマスカレードでき
ない
• これも方法が2つある
• SUIDビットつきのバイナリでvethを作る
• TAPを使ってユーザモードのネットワークスタックを動かす (slirpなど)
rootlessコンテナの課題

9. 9
Copyright©2018 NTT Corp. All Rights Reserved.
• cgroupsの設定
• 現状，SUIDバイナリが必要
• CoWファイルシステム
• vanillaなoverlayfsは，rootlessでは動かない
• Ubuntuなら動く
• XFSなら，rootlessでもreflink (copy_file_range(2)) を使ったCoWが可能
• ただしファイル毎にreflinkするオーバヘッドがある
rootlessコンテナの課題

10. 10
Copyright©2018 NTT Corp. All Rights Reserved.
• コンテナランタイムやオーケストレータにはバグがあるかもしれない
• 非root権限で動かすことで，これらのバグの影響範囲を限定できる
• SUIDバイナリをいかに排除するか(あるいは妥協するか)が課題
• 近々KubernetesやDockerもrootlessで動くようになる(はず)
まとめ
https://github.com/rootless-containers