SystemCallFilter=によるシステムサービスの競合の解決

SystemCallFilter=によるシステムサービスの競合の解決

OpenSUSEでは、coturn-4.5.2-4.1.x86_64この.serviceファイルには、許可された機能とシステムコールを含む生成されたように見えるセクションが含まれています。脆弱性が発生した場合に備えてサンドボックスを試すこともできます。開始するとすぐに、プロセスがほぼすぐに終了し、犯人を見つけるためにすべての制限を1つずつ削除する必要があることを除いて、すべてが大丈夫でした。

SystemCallFilter=~ ... @privileged ...

サービスが終了すると、システムログに有用な情報は記録されません。ただ

基本プロセスが終了します。コード=killed、ステータス=31/SYS

このマニュアルには次のように記載されています。

@privilegedスーパーユーザー機能を必要とするすべてのシステムコール(capability(7))

実際に失敗した実際のシステムコールと欠落している機能を知りたいです。

答え1

サービスがシステムコールに含まれていないシステムコールを実行する場合SystemCallFilter=設定、デフォルトの動作はプロセス終了です。SIGSYSしたがって、プロセスは1つのコアをダンプします。したがって、コアファイルを確認し、その中でシステムコール番号を見つけることができます。

例:

# coredumpctl debug
(gdb) p $rax
157

システムコールの例も同様です157。次の表でこれを参照できます。

https://github.com/torvalds/linux/blob/v5.15/arch/x86/entry/syscalls/syscall_64.tbl

つまり

157 common  prctl           __x64_sys_prctl

したがって、prctlに追加する必要がありますSystemCallFilter=

別のシステムコールが再起動に失敗する可能性があるため、いくつかの反復が必要になる場合があります。

また、確認することができますシステムの実行(5)不足している可能性があるシステムコールグループの場合は、以下を追加できます。SystemCallFilter=処理速度が速くなる可能性があります。

また、以下を使用して、現在実行中のsystemdに含まれる複数のグループのシステムコールを正確に確認できます。

systemd-analyze syscall-filter

サービスファイルも含まれている場合は、そのSystemCallErrorNumber=ファイルを削除してプロセスでコアダンプを許可する必要があります。

関連情報