私はbusyboxベースのLXCコンテナ用に非常に制限のあるseccompホワイトリストを設定しようとしています。私はUbuntuのファイル/usr/share/doc/lxc/examples/seccomp-v1.conf
から始めました。最も有用なシステムコールが含まれているようですが、それ以上文書化されていないようです。
このファイルを使用してコンテナを起動しましたが、ほとんどすべてが機能し、nginx
だけが起動しませんでした。 strace
を使用して、2つのシステムコールが欠落していることを発見しました(*pid*
/*gid*
の何か)。 ausyscall
は、名前を数字に変換するのに役立ちました。その後、nginx
が始まりました。
ここで、ファイルを本当に必要なものに減らしたいと思います。このために、ファイルをループし、一時的に1行を削除し、すべての機能がコンテナーで引き続き機能するかどうかをテストするスクリプトを作成しました。最後に、新しい(より制限の厳しい)ホワイトリストを作成できます。
このプロセスは非常に時間がかかるため、先週は毎晩数回繰り返し実行されていました。現在、lxc-attach fails providing an interactive console
が原因で行き詰まりました。私はデバッグのためのより速い方法を見つけようとしています。syslogまたはLxcがすべてのseccomp違反をログに記録するのが最善です。
カーネルコマンドラインでaudit=1
を設定しようとしましたが、syslogでseccomp関連の監査メッセージが表示されたのは1回だけでした。対照的に、Lxcは「Containerviolated seccomp」のみを表示しますが、これはどのsyscallが問題であるかを見つけるのに役立ちません。 更新:auditd
がインストールされている場合、ログは/var/log/audit/audit.log
に書き込まれ、カーネルコマンドラインパラメータはチェックされなくなります。
Q:便利なseccompホワイトリストを生成するためのより効率的な方法はありますか?また、lxc-default kexec_load
、open_by_handle_at
、init_module
、finit_module
、delete_module
の横に何をブロックするかについての推奨事項はありますか?危険なシステムコールのリストはありますか?
その間に、ausyscallツールを取得するためのauditd
をインストールした後、seccomp監査ログがsyslogではなく/var/log/audit/audit.log
に移動することを発見しました。ツールがないと、ログはどこにも行きません。
ファイルには次のような行が含まれています
type=SECCOMP msg=audit(1444422928.758:649196): auid=0 uid=100033 gid=100033 ses=1 pid=18459 comm="nginx" exe="/usr/sbin/nginx" sig=31 Arch=c000003e syscall=288 compat=0 ip=0x7f2f71555467 code=0x0
これは、どのプロセスとどのシステムコールがルールに違反したかを明確に示しています-これは私に大いに役立ちます。
しかし、私はこの質問を開いたままにしておきます。まだ回答されていない質問があり、try&errorよりもこのようなホワイトリストファイルを設定するためのより効率的な方法を探しています。