EN JA
SDOC(7)
SDOC(7) FreeBSD Miscellaneous Information Manual SDOC(7)

名称

sdocマニュアルページの「セキュリティの考察」セクションを追加するためのガイド

解説

この文書は「セキュリティ考察」セクションをマニュアルページに追加するためのガイドラインを提示しています。それは 2 つの典型的な例を提供します。

FreeBSD システムの特徴について記述するそれぞれのマニュアルページを groff_mdoc(7) 指令で FreeBSD マニュアルページを書くためのガイドラインは、その機能の誤用でどんなセキュリティ要件が突破することができるかを説明する「セキュリティの考察」セクションを含むべきです。これらのセクションに書くとき、作者は 2 つの相反する目標の間の妥協点に達成することを試みるべきです: 簡潔さと完全性です。一方では、セキュリティの考察セクションがそれほど冗長であるはずがありません、または忙しい読者はそれらを読みながら、思いとどまられるかもしれません。他方では、セキュリティの考察セクションが不完全であるはずがありません、またはそれらは、どのようにすべての安全でない使用を避けるかに関して読者を指導する目的に失敗するでしょう。この文書は、 FreeBSD システムの与えられた機能のためのセキュリティの考察セクションで簡潔さと完全性のバランスをとるためのガイドラインを提供します。

どこから始めるか

機能の誤用で違反する可能性がある、それらの一般的なセキュリティ要件をリストアップすることから始まります。 4 つのクラスのセキュリティ要件があります:
整合性 (integrity)
(例: 管理者でない者はシステムバイナリを変更するべきではありません)
機密性 (confidentiality)
(例: 管理者でない者はシャドウパスワードファイルを見るべきではありません)
利用可能性 (availability)
(例: ウェブサーバは直ちにクライアント要求に応答するべきです)
正当性 (correctness)
(例: ps プログラムは、それ以上でもそれ以下でもなく、その文書に記述された機能性をリストしてプロセステーブル情報を正確に提供するべきです。)

優れたセキュリティの考察セクションはリスト中のそれぞれの一般的なセキュリティの要件に違反して機能がどのように誤用される可能性があるかを説明するべきです。各説明は、読者が違反を避けるために従うべきである指示が添付してあるべきです。情報を複製するより文書への相互参照と同様に、 Secure Programming Practices マニュアルページ、 sprog(7) に記述された可能性のある脆弱性を参照するとき。可能なときはいつも、それを含む素材を複製するよりむしろこの文書を参照してください。

とこで止まるか

セキュリティ問題はしばしば相互に関連があります。個々の問題には、しばしば広範囲の意味あいがあります。例えば、実質的に任意のダイナミックリンクされるプログラムの正当性は実行時 (ランタイム) リンカの正しい実装と設定に依存しています。このプログラムの正当性は、Thompson によって説明されるように (下記の 関連項目 参照)、順番に、そのライブラリの正当性、それを構築するために使用されるコンパイラ、そのコンパイラを構築するために使用された前のコンパイラの正当性、その他に依存します。

簡潔さを必要とするために、セキュリティの考察セクションは直接マニュアルページの対象である機能に関連する問題だけについて説明するべきです。そこで見つけられる素材を複写するよりむしろ他のマニュアルページを参照してください。

使用例

ほとんどの個々の関数のためのセキュリティの考察セクションは次の簡単な常とう手段に従うことができます:

  1. それぞれの潜在的なセキュリティ問題について説明する 1 か 2 つの文章を準備します。
  2. それぞれの潜在的セキュリティ問題を避ける方法を説明する 1 か 2 つの文章を準備します。
  3. 短い例のコードを準備します。

これは strcpy(3) マニュアルページのためのセキュリティの考察セクションの例です:

strcpy() 関数は悪意があるユーザがバッファオーバフロー攻撃で実行プログラムの機能を独断的に変更することを可能にするやり方で容易に悪用されます。

strcpy() を使用することを避けてください。代わりに、 strncpy() を使用し、保持できる以上の文字が送り先のバッファにコピーされないことを確実にしてください。 strncpy() は、文字列が切り捨てられる場合、送り先の文字列が終了しないままとなっており、送り先のバッファをヌル文字で終了することを忘れないでください。

また、 strncpy() も問題があることに注意してください。文字列が全く切り捨てられないことはセキュリティの心配があるかもしれません。切り捨てられた文字列がオリジナルでないので、完全に異なったリソースを参照するかもしれなくて、切り捨てられたリソースの用法がたいへん不適当な振舞いをもたらすこともあり得ます。例:

void 
foo(const char *arbitrary_string) 
{ 
 char onstack[8]; 
 
#if defined(BAD) 
 /* 
  * 
  * この最初の strcpy は悪い振る舞いです。strcpy() を使用しなこと! 
  */ 
 (void)strcpy(onstack, arbitrary_string);     /* BAD! */ 
#elif defined(BETTER) 
 /* 
  * 次の 2 つの行が strncpy() のより良い使用例です。 
  */ 
 (void)strncpy(onstack, arbitrary_string, sizeof(onstack) - 1); 
 onstack[sizeof(onstack - 1)] = '\0'; 
#elif defined(BEST) 
 /* 
  * これらの行は、切捨てがないかどうかテストするので、 
  * さらに頑強です。 
  */ 
 if (strlen(arbitrary_string) + 1 > sizeof(onstack)) 
  err(1, "onstack would be truncated"); 
 (void)strncpy(onstack, arbitrary_string, sizeof(onstack)); 
#endif 
}

ツールとコマンドのセキュリティの考察セクションは公式に従わない傾向があります。潜在的に違反されたセキュリティ要件のリストをガイドとするようにしてください。それぞれを説明し、できるだけ簡潔な方法で解決策をリストしてください。

次は rtld(1) マニュアルページのためのセキュリティの考察セクションの例です:

LD_LIBRARY_PATH と LD_PRELOAD 環境変数を使用して、悪意あるユーザはそれら自体の工夫された共有ライブラリを set-user-ID/group-ID されていないプログラムを動かすプロセスのアドレス空間にダイナミックリンカでリンクさせることができます。これらの共有ライブラリは、標準のライブラリ関数への呼び出しをそれら自体の呼び出しに取り替えることによって、プログラムの機能を任意に変更することができます。この機能は set-user-ID と set-group-ID プログラムでは無効にされますが、他のプログラムでトロイの木馬を作成するのにまだそれを使用することができます。

すべてのユーザは set-user-ID/group-ID されていないダイナミックリンクされたプログラムの正しい操作がこれらの環境変数の適切な設定に依存することを承知しているべきで、実行時 (ランタイム) リンカを未知の起源の共有ライブラリでリンクされるようにする値にそれらを設定するかもしれない動作を避けることに注意するべきです。

関連項目

groff_mdoc(7), security(7), sprog(7) Edward Amoroso, AT&T Bell Laboratories, Fundamentals of Computer Security Technology, P T R Prentice Hall, 1994. Ken Thompson, Reflections on Trusting Trust, Association for Computing Machinery, Inc., Communications of the ACM, Vol. 27, No. 8, 761-763, August, 1984.

歴史

sdoc マニュアルページは、 FreeBSD 5.0 ではじめて登場しました。

作者

Tim Fraser, NAI Labs CBOSS project. <tfraser@tislabs.com> Brian Feldman, NAI Labs CBOSS project. <bfeldman@tislabs.com>
September 5, 2005 FreeBSD