6

サーバー上で任意の (潜在的に危険な) バイナリを実行したいと考えています。したがって、objcopy「メイン」シンボルの名前を「other_main」に変更して、other_main を呼び出す前に適切な値を設定しRLIMIT_CPUてフラグを切り替える独自の小さなメイン関数にリンクできるようにしSECCOMPました。これまでのところ、このソリューションに非常に満足しています。

問題は、サードパーティのプログラム コードに malloc の呼び出しが含まれている可能性があることです (sbrk は許可されていません)。SECCOMPしたがって、malloc / realloc / calloc / free で使用する必要がある設定の前に、適切なサイズの配列 (20MB など) を事前に割り当てたいと思います。残念ながら、最後のステップをアーカイブする方法がわかりません。これら 4 つの機能をすべて自分で実装する必要がありますか? 独自の関数を stdlib に挿入するにはどうすればよいですか (たとえば、printf が内部で malloc を呼び出すとどうなりますか?)。

4

3 に答える 3

3

すべての malloc 実装が sbrk() に基づいているわけではありません。たとえば、GNU mmallocがあります。このドキュメントは、カスタム実装が必要な場合にも役立ちます。

+ 2 つの単純な malloc 実装がここに

于 2012-07-13T20:47:50.237 に答える
2

malloc と free の場合、プログラムは独自のバージョンを定義するだけで済みます。私が見たほとんどの libc 実装 (glibc、klibc、dietlibc を含む) は、メモリ アロケータ ルーチンを問題なく使用します。したがって、seccomp モードに入る前に、mmap または sbrk を使用して大量のメモリ チャンクを割り当ててから、このチャンクから malloc/free を割り当てます。 memmgrは、固定バッファーからの割り当てに簡単に適応できる単純なヒープ アロケーターです。

seccomp の本当の問題は、それが許可する一連のシステム コール (読み取り、書き込み、終了、および sigreturn) が、多かれ少なかれそこにある libc に対してリンクされたプログラムを実行するのに十分ではないことです。例えば：

  • glibc では、exit と _exit は exit_group を呼び出します
  • glibc では、printf は mmap を呼び出すことができます
  • Dietlibc では、scanf は ioctl を呼び出すことができます
  • などなど

通常、これらの呼び出しが必要な理由には十分な理由があります。たとえば、dietlibc は ioctl を使用して、入力が stdin から読み取られるときに stdin が tty であるかどうかをチェックし、stdout をフラッシュします。これは、出力が行バッファリングされている場合に対話型入力を読み取る前にプロンプ​​トが表示されるようにするための標準的な動作です。

したがって、元の seccomp モードは多かれ少なかれ役に立たないという結論に達しました。ただし、モード 2 (別名「フィルター モード」) は、特定のシステム コールをホワイトリストに登録できるため、はるかに便利です。私の github ページには、プログラムを seccomp モード 2 で実行する概念実証がありますが、それらは printf と scanf を使用でき、malloc/free を使用してメモリを割り当てることができます。

于 2012-07-26T21:17:01.180 に答える
1

seccompsandbox：

  • あるスレッドでseccompを有効にします。これにより、同じプロセスで別の（seccomp以外の）スレッドへのRPC（事前に割り当てられたスレッドをread介して）が実行され、次のような特権操作を実行できます。writesocketpairmmap
  • mallocseccomp-safeラッパーにリダイレクトするための（メモリ内、実行時）などのパッチ機能

ChromiumのseccompSandboxには、その仕組みに関する詳細がいくつかあります。

于 2012-07-13T22:24:59.407 に答える