FAPolicyD のオーバーヘッドによりサーバーの速度が低下する

Question

実行されたプログラムのリストを許可する機能は、最も効果的なセキュリティ機能の 1 つです。この機能がないと、侵害されたユーザーアカウントが任意のペイロードを実行できてしまいます。または、ユーザーがホームディレクトリにインストールすべきでないプログラムをインストールしてしまう可能性があります。ただし、これはオプション機能なので、有効にするかどうかはユーザーが決定します。

このようなファイルシステム呼び出しをすべて検査すると、パフォーマンスが低下します。ただし、ルールとデータベースを最適化することでオーバーヘッドを最小限に抑えることができます。

ユーザーの観点からパフォーマンスが許容できるかどうかを測定します。「アプリケーション API 呼び出しの 99.9% が 1 秒以内に完了する」などの応答時間に重点を置いた目標は、リソース使用率の傾向だけでなく、実際の問題を検出します。

まずfapolicydの背景については、パフォーマンスの紹介をご覧ください。READMEを読む:

パフォーマンス

プログラムがファイルを開いたり、execve を呼び出したりすると、そのスレッドは fapolicyd が決定を下すまで待機する必要があります。決定を下すために、fapolicyd はプロセスとアクセスされているファイルに関する情報を検索する必要があります。fapolicyd が実行する必要がある各システムコールは、システムの速度を低下させます。

処理速度を上げるために、fapolicyd は検索したすべてのものをキャッシュし、その後のアクセスでは最初から検索するのではなくキャッシュを使用します。ただし、キャッシュのサイズには限りがあります。ただし、キャッシュはユーザーが制御できます。サブジェクトキャッシュとオブジェクトキャッシュの両方を大きくすることができます。プログラムが終了すると、次のようなパフォーマンス統計が /var/log/fapolicyd-access.log または画面に出力されます。
Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)
このレポートでは、内部リクエストキューが 7 で最大になったことがわかります。これは、デーモンが最大 7 つのスレッド/プロセスを待機していたことを意味します。これは、デーモンが少しバックアップされていたものの、リクエストをかなり迅速に処理していたことを示しています。この数値が大きい場合 (200 を超える場合など)、q_size を増やす必要がある場合があります。1015 を超える場合は、systemd に 1024 を超える記述子を許可するように指示する必要がある場合があることに注意してください。fapolicyd.service ファイルで、LimitNOFILE=16384 またはキューよりも大きい数値を追加する必要があります。

注目すべきもう 1 つの統計は、ヒット対エビクションの比率です。リクエストに情報を配置する場所がない場合、スペースを確保するために何かを削除する必要があります。これは、使用されていないものを自然に判断し、そのメモリを再利用可能にする LRU キャッシュによって行われます。

上記の統計では、サブジェクトヒット率は 95% でした。オブジェクトキャッシュはそれほど幸運ではありませんでした。ヒット率は 79% でした。これはまだ良い値ですが、さらに改善の余地があります。これは、そのシステムのワークロードでは、キャッシュをもう少し大きくできる可能性があることを示しています。キャッシュサイズに使用される数値が素数である場合、共通の分母がある場合よりも衝突によるキャッシュチャーンが少なくなります。キャッシュサイズに考慮できる素数には、1021、1549、2039、4099、6143、8191、10243、12281、16381、20483、24571、28669、32687、40961、49157、57347、65353 などがあります。

また、ポリシー内のルールが増えるほど、決定を下すために反復しなければならないルールの数も増えることにも留意する必要があります。システムパフォーマンスへの影響については、これはワークロードに大きく依存します。一般的なデスクトップシナリオでは、実行されていることに気付かないでしょう。短時間に多数のランダムファイルを開くシステムでは、影響が大きくなります。

パフォーマンスに影響を与える可能性があるもう 1 つの構成オプションは、整合性設定です。これを sha256 に設定すると、オブジェクトキャッシュでミスが発生するたびに、アクセスされているファイルでハッシュが計算されます。トレードオフの 1 つは、sha256 ではなくサイズチェックを使用することです。これはそれほど安全ではありませんが、パフォーマンスに問題がある場合はオプションになります。

do_stat_report = 1config で統計レポートを有効にし、最近 fapolicyd を再起動していない場合は再起動します。/var/log/fapolicyd-access.log どの PID がどのファイルを開いているかのパターンを分析して記録します。

「ヒット」と「ミス」の比率に注意してください。ヒット率が高いほど良いです。メモリ内データベースへのアクセスは、ファイルシステムへのアクセスと処理よりもはるかに高速です。obj_cache_sizeシステムが一度に持つファイルの数に応じて構成を増やします。考えられる上限は、出力からのデータファイルシステムで使用されている inode の数ですdf -i。これは多すぎるかもしれませんが、メモリがある場合は、数十万のエントリをキャッシュしてみてはいかがでしょうか。

fapolicyd.conf の設定を確認してください。またはintegrity以外の値ではチェックサムが計算され、オーバーヘッドが発生します。特に、新しいファイルの処理でミスが多数発生する場合、CPU の使用量がかなり多くなることがあります。アクセスレポートの「最大キュー深度」よりも大きくする必要がありますが、キューサイズを増やす必要はないと思います。nonesizeq_size

ルールを、rules.d のcompiled.rulesで確認してください。RHEL と Fedora は、rpm から信頼できるファイルを作成し、不明なファイルの実行を許可せず、ld.so トリックを許可せず、ほとんどのオープンを許可します。ルールを変更する場合は、そのオープンシステムコールが待機している間にさらに多くのことを実行することによるパフォーマンスへの影響を考慮してください。

そしていつものように、トラブルシューティング中に何が起こっているかを正確にプロファイルできます。CPU perf top上の関数を出力します。debuginfo がインストールされているとさらに良くなります。bcc-tools パッケージには、open および exeve 呼び出しをリアルタイムで一覧表示する opensnoop および execsnoop という便利なスクリプトがあります。

最終的に、許可されていないプログラムの実行のみを許可するには、どのような制御を導入するかを決めるのはあなたです。fapolicyd のように、exec 呼び出しですぐにリストを許可するのは、もちろん非常に強力です。それほど包括的ではない代替案としては、シェルアクセスを制限することが考えられます。つまり、対話型シェルをユーザーに許可せず、ホームディレクトリのアクセス許可をロックダウンします。または、データファイルシステムにプログラムをまったく含めない場合は、noexec でマウントすることを検討してください。適切なセキュリティ監査では、チェックリストを不変として扱うのではなく、導入されている代替制御とその理由をリストします。

Answer 1