7

私は現在、ACMのようなパブリックプログラミングコンテストシステムのバックエンドに取り組んでいます。このようなシステムでは、すべてのユーザーがコードソースを送信できます。このコードソースは、計算上の問題を解決するために、自動的にコンパイルおよび実行されます（つまり、人間の目の事前モデレーションは実行されません）。

バックエンドはGNU/Linux専用のマシンであり、参加者ごとにユーザーが作成され、そのようなユーザーはすべてユーザーグループの一部になります。特定のユーザーによって送信されたソースは、ユーザーのホームディレクトリに保存され、コンパイルおよび実行されて、さまざまなテストケースに対して検証されます。

私が欲しいのは、ソースに対するLinuxシステムコールの使用を禁止することです。これは、問題にはプラットフォームに依存しないソリューションが必要であるのに対し、安全でないソースのシステムコールを有効にすると、セキュリティ違反が発生する可能性があるためです。このようなソースは、コンパイルされていてもFSに正常に配置される可能性がありますが、実行されることはありません。また、システムコールを含むソースが送信されたときに通知を受け取りたいです。

今では、そのようなチェッカーが配置される可能性のある次の場所が表示されます。

  • フロントエンド/コンパイル前の分析-ソースはすでにシステムにチェックインされていますが、まだコンパイルされていません。システムコール名に対する単純なテキストチェッカー。プラットフォームに依存し、コンパイラに依存せず、言語に依存するソリューション。
  • コンパイラパッチ-システムコールが発生するたびにGCC（またはツールチェーンに含まれる他のコンパイラ）をクラッシュさせます。プラットフォームに依存し、コンパイラに依存し、言語に依存しないソリューション（チェッカーを「十分に」配置した場合）。互換性も失われる可能性があります。実際、私はこの代替案が最も嫌いです。
  • ランタイムチェッカー-システムコールがプロセスから呼び出されるたびに、このプロセスを終了してレポートします。このソリューションはコンパイラと言語に依存しませんが、プラットフォームによって異なります。短期的および中期的に同様のプラットフォームにバックエンドをデプロイするので、問題ありません。

したがって、問題は次のとおりです。GNU/ Linuxは、管理者がユーザーグループ、ユーザー、または特定のプロセスのシステムコールの使用を禁止する機会を提供しますか？これは、セキュリティポリシーまたは軽量のGNUユーティリティである可能性があります。

私はグーグルにしようとしました、しかしグーグルは今日私を嫌いました。

4

2 に答える 2

9

モード1seccompを使用すると、プロセスはそれ自体を正確に4つのシステムコール（、、、、および）に制限できreadます。これは、 seccomp-nurseと同様に、コードを厳しくサンドボックス化するために使用できます。writesigreturn_exit

モード2seccomp（執筆時点では、Ubuntu 12.04にあるか、独自のカーネルにパッチを適用します）は、システムコールのフィルタリングをより柔軟にします。たとえば、最初にフィルターを設定し、次にexecテスト対象のプログラムを設定できます。の適切な使用、chrootまたはそれが他の「興味深い」ものに影響を与えるのunshareを防ぐために使用することができます。exec

于 2012-04-03T21:57:23.053 に答える
3

システムコールをより適切に定義する必要があると思います。つまり、

cat <<EOF > hello.c
#include <stdio.h>
int main(int argc,char** argv) {
  fprintf(stdout,"Hello world!\n");
  return 0;
}
EOF
gcc hello.c
strace -q ./a.out

明らかに些細なプログラムでさえ、最大27のシステムコールを行うことを示しています。あなたは（私が思うに）「標準Cライブラリ」への呼び出しを許可したいのですが、それらはシステムコールの観点から実装されます。私が言おうとしているのは、実行時チェックはあなたが思っているよりも実行可能性が低いということだと思います（straceとにかく使用または同様のもの）。

于 2012-04-03T21:53:16.417 に答える