前回の連載が掲載されたあと,
さて,
この連載は,
非特権コンテナが行う操作
この連載の第16回で紹介したように,
この機能を使って,
このユーザ名前空間内のrootユーザは,
これはもちろん,
このように非特権コンテナ/dev
以下のデバイスファイルを作成したり,
デバイスファイルには,/dev/
,/dev/
などはコンテナ内で作成しても安全でしょう。
デバイスファイルに関しては,
それでも,
ファイルシステムのマウントに関しては,
事前に必要なマウントがわかっている場合は,
しかし,
現在のようにコンテナ上でアプリケーションを実行することが一般的になってきている状況では,
つまり
- コンテナ内のタスクは非特権コンテナから実行できない操作を行う,
つまりシステムコールを発行する可能性があります
このような場合,
- コンテナマネージャはそのシステムコールを非特権コンテナ内で実行しても安全であることを知っている可能性があります
しかし,
- コンテナマネージャはいつそのシステムコールが発行されるのか,
発行されたのかを知ることができません - もし,
いつ発行されるのか, 発行されたのかを知っていたとしても, 必要な検査を行う方法がありません
というような問題がありました。
システムコール
ここまでなんの前提もなく
通常,
これによりカーネルに対する操作の共通的なインターフェースが提供でき,
先に書いたデバイスファイルの作成やマウントなども,
- ※1)
- 実際はユーザー空間のプログラムとカーネルの間にglibcなどのライブラリが存在するので,
プログラムから使うのはライブラリのインターフェースですが, ここでは説明を簡単にするために 「ユーザー空間」 「カーネル空間」 のみを取り上げています。
seccomp
さて,
これはseccompと呼ばれ,
seccompは2005年,
その後,
フィルタリングの指定は,
図2のように,
実行が許可されていないシステムコールが実行された場合の動作として,
seccomp notify
このように,
しかし,
また,
そこで,
- ※2)
- 特に正式に決まった機能名があるわけではありません。"Seccomp notify",
"Seccomp trap to userspace", "seccomp user notifications"などと紹介されていたりします。
この機能を使うには,SECCOMP_
というフラグを設定します
呼び出し元のタスク自体は,
ファイルディスクリプタを渡されたコンテナマネージャは,ioctl
を呼び出し,
そして,
コンテナマネージャは②で送られた通知を読み取ります。この通知からは,
ここでコンテナマネージャ内で必要な検査を行い,
もしコンテナマネージャが呼び出されたシステムコールによる操作が許可できる操作であると判断した場合は,
もしコンテナマネージャが呼び出されたシステムコールによる操作を許可しない場合は,
これがseccomp notify機能の概要です。
- ※3)
- seccomp notifyの結果,
カーネルがシステムコールの実行を続けられるようになったのは5. 5カーネルからです。