私はビジボックスベースのLXCコンテナに対して非常に厳しいseccompホワイトリストを設定しようとしています。私はUbuntuのドキュメントから始めました/usr/share/doc/lxc/examples/seccomp-v1.conf。これには、最も便利なシステムコールが含まれているように見えますが、これ以上文書化されていないようです。
このファイルを使ってコンテナを起動しましたが、ほとんどすべてがうまくいきますが、nginx起動しません。これを使用して、2つのシステムコール（/を含むエントリ）が見つからないことがstraceわかりました。名前を数字に翻訳するのに役立ちます。その後始まりました。*pid**gid*ausyscallnginx
さて、実際に必要なファイルにファイルを減らしたいと思います。このために、ファイル全体を繰り返し、一時的に行を削除し、すべてがコンテナでまだ機能しているかどうかをテストするスクリプトを作成しました。最後に、新しい（より制限的な）ホワイトリストを作成できます。
このプロセスは時間がかかるため、先週、毎晩何度も繰り返し実行された。私は現在。ので詰まっていますlxc-attach fails providing an interactive console。デバッグするためのより速い方法、好ましくはすべてのseccomp違反を記録するsyslogまたはLxcを見つけようとしています。
カーネルコマンドラインで設定しようとしましたが、audit=1syslogでseccomp関連の監査メッセージを見たのは1回だけでした。対照的に、Lxcは「コンテナがseccompに違反しました」のみを表示します。これは問題のあるシステムコールを見つけるのに役立ちません。修正する:インストールされている場合はauditdログが記録さ/var/log/audit/audit.logれ、カーネルコマンドライン引数は確認されなくなりました。
尋ねる：有用なseccompホワイトリストを生成するより効率的な方法はありますか？これを防ぐために、lxc-default 、、kexec_loadおよびlxc-default以外の提案はありますか？危険なシステムコールのリストがありますか？open_by_handle_atinit_modulefinit_moduledelete_module
答え1
同時にausyscallをインポートするためのツールをインストールした後、/var/log/audit/audit.logsyslogの代わりにseccomp監査ログに移動することがわかりました。auditdこのツールがない場合、ログは移動する場所がありません。
ファイルには次のような行が含まれています。
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
どのプロセスとどのシステムコールがルールに違反したかを明確に伝えました。これは私にとって非常に役立ちました。
しかし、私はその質問に答えなかった。まだ答えられていない質問があり、私はこのようなホワイトリストファイルを設定するために試行錯誤よりも効率的な方法を探しています。