web-dev-qa-db-ja.com

LXCコンテナーの `seccomp`ルールをロードしないことはどれほど危険ですか？

環境

LXCをRaspbianで実行する への私の「探求」では、/usr/share/lxc/config/debian.common.confでコメントアウトすることにより、コンテナーの起動時に seccomp 構成のロードを無効にすることを余儀なくされる可能性があります：

# Blacklist some syscalls which are not safe in privileged
# containers
#  lxc.seccomp = /usr/share/lxc/config/common.seccomp

（a.t.m.）としてthanのみコンテナが起動します（そうでない場合はエラーが発生します）。

コンテナ化/サンドボックス化に深く関係しているこのような基本的なセキュリティ設定をオフにすることは、ある程度、LXCの目的を損なうことになります。セキュリティ/安定性の観点から、LXCコンテナを実行するときにほとんどのシステムコールをブラックリストに登録し続けたいと思います（/usr/share/lxc/config/common.seccompのLXCデフォルトで構成されています）。

2
blacklist
[all]
kexec_load errno 1
open_by_handle_at errno 1
init_module errno 1
finit_module errno 1
delete_module errno 1

質問

'LXCコンテナーのseccompルールをロードしない' yield：

  1. 重要*セキュリティの問題？
  2. 他の技術的（アプリケーションまたは安定性）の問題はありますか？

*「マザー」システムとそのLXCコンテナーを使用しているのは私だけだと仮定します（そうでない場合は明らかです）。

securitylxccontainerstability
2
woosting

そうですね、seccompルールは、コンテナがホストカーネルを変更するのを防ぎます。それらがないと、コンテナー内のUID 0はkexec（Raspbianでも機能するかどうかはわかりません）を使用して、新しいカーネルをロードし（明らかに起動しない）、insmod/rmmodこれらのsyscallはユーザーの名前空間を正しく考慮しないため、特にモジュールをロード/アンロードします。

これが重大なセキュリティ問題であるかどうかはあなた次第です-コンテナ内のUID0がコンテナ外で効果的にUID0になる可能性があることを覚えておく必要があります。つまり、細工されたモジュールをロードすることでrootがコンテナをエスケープできるようになります。例えば。

4
maxf