10.11. その他

下記の内容は、セキュリティ・ガイドラインなのですが、何処にも分類できない ものです。

少なくとも前提条件の一部は、プログラムで事前にチェックしてください(たとえば、 プログラムが開始されるところで)。 たとえば、あるディレクトリで「sticky」ビットが立っていることを前提にしている なら、本当にそうなっているかをテストしてください。そのようなテストには時間は かかりませんし、それによって深刻な問題を防げるはずです。 もしそれぞれの呼び出しでテスト実行時間がかかることが気になるなら、せめて インストール時に行うようにしてください。アプリケーション起動時に行うと さらに良いです。

組み込みでスクリプト言語を使っているなら、その言語が環境変数を設定して、 スクリプトから実行されるプログラムに悪影響を与えるかもしれません。 これは防いでください。

複雑な設定用言語が必要なら、その言語にコメント文字があり、コメントアウト した安全な例がたくさんあるようにしてください。 「#」はコメントとしてよく使われますが、これは「この行の残りはコメント」 を意味します。

なるべく root に setuid や setgid したプログラムを作成しないでください。 かわりに、ユーザには root でログインするようにさせてください。

コードに電子署名をしてください。利用者は送られてきたものが利用できるものか どうかをチェックできます。

安全性が求められるプログラムを作成する場合は、静的にリンクを行うことを検討して みてください。 安全性が求められるプログラムが動的リンクを使わないようにすれば、動的なライブ ラリのリンク機能を狙った攻撃に対抗できます。 しかしこの方法には欠点もあります。 使用するディスクやメモリが増える傾向にあります(同じルーチンを複数個コピー するからです)。 さらに悪いのは、ライブラリの更新(たとえば、セキュリティの脆弱性を防ぐため) が面倒になるなる点です。たいていのシステムでは自動的には更新できず、独自に 更新を追いかけて実装するしかありません。

コードを眺めている時には、条件にマッチしないケースすべてを検討してください。 たとえば switch 文があった場合、どのケースにもマッチしなかった場合どうなる のか? 「if」文があれば条件が偽になった場合にどうなるのか?などなど。

単にファイルを「削除」しても、ディスクからファイルのデータは除去されません。 システムの多くは、ただ「削除した」印をつけ、後で再利用できるようにします。 またデータが一時的に他の所に置かれている場合もよくあります(メモリや swap ファイル、テンポラリ・ファイルとして)。 実際、しつこい攻撃者に対抗するには、データの上書きでは十分ではありません。 磁気メディアを消去する上での問題については、古典的なドキュメントである Peter Gutmann 氏の 「Secure Deletion of Data from Magnetic and Solid-State Memory」 があります。 しつこい攻撃者は、別の手段を使うこともできます。たとえば、コンピュータから放出 される電磁波を監視したり(軍事システムは、電磁波盗聴規則に従い、これに対抗 しています)、秘密裏に攻撃をかけます(キーボードに隠した監視装置等)。

セキュリティ上の脆弱性を修正する時には、「警告」の追加を考慮し、(今修正した) 脆弱性を侵そうとする試みを検知し、そのログを取るようにしてください。 こうすることで、攻撃の機会を減らします。攻撃が進行していることがあらわになる ことで、特に攻撃者が攻撃できるかどうか、事前に調べる方法がなくなります。 つまり、脆弱性が侵入検知システムになるわけです。 これは、認証以前にサーバプログラムのバージョンを公開すると、セキュリティ上 好ましくないことも示しています。公開してしまうと、攻撃者がそのバージョンで 動作する攻撃に絞ってやすやすと攻撃できるからです。 プログラムには、ユーザに対して故意にバージョンを「偽る」ことができるものが あります。そうすると攻撃者は「間違った」攻撃をすることになり、攻撃を検出でき ます。 脆弱性はネットワークで起きるので、必ずセキュリティ・スキャナで脆弱性を検知 できるようにしてください。 Nessus(http://www.nessus.org) と連絡をとって、彼らのオープンソースなセキュリティ・スキャナが問題を検出できる かどうかを確かめてください。 そうすれば、ソフトウェア更新に無頓着なユーザは、セキュリティの脆弱性をスキャン することで、問題を知ることになります(やるべきことをやるかもしれません)。

時には、このドキュメントのようなセキュリティガイドラインをレビューして ください。 せめて Chapter 11 にある結論は再読してください。 そして気楽に「はじめに」(Chapter 1)に戻って、再読 しましょう。