2.8. 設計と実装の指針についての情報源

安全なプログラムを書く方法(あるいは、既存のプログラムのセキュリティ上の 問題点をどのように発見するのか)について、役立つドキュメントがいくつか あります。またそれらのドキュメントは、このドキュメントでガイドラインとして これから明確にしていく項目の根拠にもなっています。

汎用的なサーバや setuid もしくは setgid したプログラムについては、役に立つ ドキュメントがたくさんあります(ドキュメントの中には直接見つけるのが困難なも のがあります)。

Matt Bishop[1996, 1997] は、このトピックに関してたいへん素晴らしい ドキュメントを作成したり、発表を行ったりしています。その上彼の Web サイト http://olympus.cs.ucdavis.edu/~bishop/secprog.html でこのトピックを専門に扱っています。 AUSCERT はプログラミングにあたってのチェックリスト [AUSCERT 1996] を公開しています。これは Garfinkel、Spafford 両氏の著作 [Garfinkel 1996] の 23 章で論じている、安全な suid したネットワーク関連のプログラム書法を下敷き にしています。 Galvin [1998a] は、安全なプログラムを開発する工程やチェックリストについて分かりやすく説明 しています。最近になってチェックリストが更新され、 Galvin [1998b] で見られます。 Sitaker [1999] には、「Linux セキュリティ監査」チームが検討している問題について、その一覧が あります。 Shostack [1999] では セキュリティに気を配る必要があるコードをレビューするのに役立つチェックリストを 定義しています。 NCSA [NCSA] では、安全なプログラムのための簡潔かつ役に立つガイドラインを提供しています。 その他で情報源として役に立つのは、 Secure Unix Programming FAQ [Al-Herbish 1999]Security-Audit's Frequently Asked Questions [Graham 1999]Ranum [1998] があります。 アドバイスの中には注意しなければならないものがあります。例えば BSD の man の setuid(7) では [Unknown]、 access(3) の使用を推奨していますが、その使用にともなって生じる競合状態の 危険さを考慮していません。 Wood[1985]には、役に立つものの、古くなってしまったアドバイスが 「Security for Programmers」の章にあります。 Bellovin [1994] には役に立つガイドラインや ftpd の実装をよりシンプルで安全に組み直すといった やり方の具体例がいくつかあります。 FreeBSD は FreeBSD [1999] というガイドラインを用意しています。 [Quintero 1999] は、そもそも GNOME のプログラミング・ガイドラインと関連がありますが、 セクションの 1 つでセキュリティについて検討しています。 [Venema 1996] は、安全なプログラムを組む時にありがちなエラー(ありきたりなので推測可能な パスワードや悪意あるデータによる汚染、ユーザがアクセスできるデータ に含まれてしまっている機密情報、他のプログラムへの依存)について詳しく (例を挙げて)論じています。 [Sibert 1996] は、悪意あるデータが引き起こす脅威について説明しています。

Web のインタフェースである Common Gateway Interface(CGI)は、プログラマ向け ドキュメントとして、セキュリティのガイドラインがたくさん用意してあります。 Van Biesbrouck [1996], Gundavaram [unknown], [Garfinkle 1997] Kim [1996], Phillips [1995], Stein [1999], [Peteanu 2000], and [Advosys 2000].

ある特定の言語について触れたドキュメントはたくさんあります。このドキュメント では、言語に固有な点に触れたセクションでさらに論じます。 たとえば、Perl の配布物の中には、 perlsec(1) というセクションがあり、Perl をより安全に使う方法に ついて論じています。 http://www.cs.princeton.edu/sip にある Secure Internet Programming というサイトは、コンピュータのセキュリティ 全般について扱っていますが、Java や ActiveX、JavaScript といったモバイル・ コードの仕組みに焦点を当てています。 Ed Felten 氏(このサイトの中心人物の 1 人)は Java を安全にする書籍を共著して います。 ([McGraw 1999])。この点に ついては Section 9.6 で扱います。 Sun が出しているコードを安全にするためのガイドラインには、主に Java や C について触れたものがいくつかあります。 http://java.sun.com/security/seccodeguide.html で利用できます。

Yoder[1998]には、アプリケーションのセキュリティに取り組む際に利用できるパタン がいろいろあります。 ガイドラインとしては具体性に欠けますが、日常よく使うプログラミング・パタン として役に立つと思います。 Schmoo グループは、安全なコードを書く方法についての情報リンクを Web サイトに 載せ続けています。http://www.shmoo.com/securecode

別の側面から問題を論じているドキュメントも、たくさん存在します(たとえば 「システムをクラックするには」)。 一例として McClure[1999]があげられますし、インターネットという世界で見れば、 さらに莫大な資料がころがっています。 また、あるコンピュータ・アーキテクチャを攻撃するにはどのように開発すれば よいか等についても、より広範囲なドキュメント(たとえば [LSD 2001]のような) が存在しています。 Honeynet プロジェクトは、実際にどのように攻撃を行っているのかについて、情報 (統計を含め)を集めています。 http://project.honeynet.org を見れば詳細な情報が得られます。

既存のプログラムにおいて、脆弱性が既に確認されている情報も多量に出回っています。 この情報は、「そうしないようにする」という点では役に立ちます。しかし、たくさん の具体的な例から、一般的に利用できるガイドラインを見つけ出すのはかなり大変 です。 セキュリティについて議論するメーリングリストがあります。最も有名なものの 1 つに Bugtraq があります。このメーリングリストは脆弱性の一覧を作成する ことに熱心に取り組んでいます。 CERT Coordination Center(CERT/CC)は、代表的な機関の 1 つで、インターネット 関連のセキュリティ上の問題を報告しています。 CERT/CC はちょくちょく勧告を発行し、深刻なセキュリティ上の問題やその 影響度合いを解説し、パッチや善後策をどうやって得たらよいのかを説明 しています。詳しい情報は、 http://www.cert.org を見てください。 ただし注意して欲しいのは、もともと CERT は小型コンピュータ緊急対応チーム であって、公式に「CERT」がセキュリティについての代表機関となっているわけ ではない点です。 米国エネルギー省の機関である Computer Incident Advisory Capability (CIAC) も脆弱性について報告をあげて います。 それぞれのグループは同じような脆弱性を報告していますが、ばらばらな呼び方 をしています。 この問題を解決するために、MITRE は、「あきらかな脆弱さと起こる可能性がある 脆弱さの共通化」(Common Vulnerabilities and Exposures(CVE))の一覧を作成して います。この一覧では、共通で一意に決まる識別子(name)を作って、一般的に広く 知られている脆弱性と誰かが発見したセキュリティ上の問題を載せています。 http://www.cve.mitre.org を見てください。 NIST の ICAT はコンピュータの脆弱性を検索可能な形でまとめたものです。CVE の 脆弱性のカテゴリにもとづいているので、後で検索や比較が可能になっています。 http://csrc.nist.gov/icat を見てください。 【訳註:MITRE と CVE の詳細は、 about MITREabout CVE を参照してください】

このドキュメントは、私が最も有益かつ重要だと考えたガイドラインをまとめた ものです。 優秀なプログラマがこれを読んだだけで、かなり上手に安全なプログラムを実装 できるよう、下地を作ることを目標にしています。 この目標を単独でカバーできるドキュメントにはお目にかかったことはありません が、この取り組みは意義があると信じています。 方針はバランスを取ることです。「考えられるだけのガイドラインをリストアップ する」(エンドレスな作業でいつまでたっても形にならない)こと、「簡潔な」リスト をいろいろあげてオンラインで利用できれば、有益かつ簡潔にはなるものの、重大な 問題が省略されてしまうことが多く、この両者のバランスが大切です。 はっきりしない場合は、手引きを記載してあります。そういう場合は、誰もが 「これさえ見ればすべて OK」的なドキュメントを読んで、その情報を活用できる ようになっている方が、より効果的だと考えるからです。 このドキュメントの構成(一覧はすべて、独自でさまざまな構成になっています)は、 私自身が作成し、ガイドライン(特にケイパビリティや fsuid のような Linux 独自 のもの)の中にも、私自身が書いたものがあります。 上記にあげた関連ドキュメントをすべて読むことを強くお薦めします。しかし、 それは現実的ではないですね。