Index: Secure-Programming-HOWTO.sgml =================================================================== RCS file: /JF/JF/docs/Secure-Programming-HOWTO/Secure-Programming-HOWTO.sgml,v retrieving revision 1.1 diff -u -r1.1 Secure-Programming-HOWTO.sgml --- Secure-Programming-HOWTO.sgml 2000/02/03 14:41:02 1.1 +++ Secure-Programming-HOWTO.sgml 2000/02/03 17:52:04 @@ -69,14 +69,14 @@ --> この論文は，安全なプログラムを Linux システム用に書くための設計と実装 のガイドラインを集めたものである． -この論文の目的である「安全なプログラム」とは，安全な場所とそうでない場 -所の境界上にあり，プログラムと同等の権限を持たないデータを入力する -プログラムのことである． +この論文の目的である「安全なプログラム」とは，安全な位置とそうでない位置 +との境界上に置かれ，自分とは同等の権限を持っていないソースからの入力を +扱うプログラムのことである． これに該当するプログラムには，リモートデータのビューアとして使われる プログラム，CGI スクリプト，ネットワークサーバ，setuid/setgid して使用 するプログラム等がある． 本論文で説明する原則の多くは Linux カーネルにも当てはまるが，この論文 -ではカーネル自身の修正には触れない． +ではカーネルそのものの修正には触れない． この論文で述べるガイドラインは，安全なプログラムを作る方法に関するさま ざまな情報から「学んだ教訓」のまとめとして作成され(筆者が加えた意見も ある)，より大きな原則として整理し直されている． @@ -112,6 +112,7 @@ (SE-CMM), ISO 9000 (および ISO 9001, ISO 9001-3), ISO 12207 等の文書で定義されている．

+ この論文の書式は， Linux Documentation Project (LDP, ) -に容易に加えられるように意図してある．この論文のオリジナルは +に容易に加えられるように意図して整形してある．この論文のオリジナルは から入手できる．

1984 年に Richard Stallman 率いる Free Software Foundation (FSF) は GNU プロジェクトを開始した．このプロジェクトはフリーな版の UNIX OS を作ろ -うとするものである．「フリー」という言葉によって，Stallman は自由に +うとするものである．Stallman は「フリー」という言葉によって，自由に 使い，読み，変更し，再配布できるソフトウェアを表そうとした． -1991 年に Linux Torvalds はある OS のカーネルの開発を始めた．Linus は -これに「Linux」と名付けた[Torvalds 1999]． +1991 年に Linux Torvalds は OS のカーネルの開発を始めた．Linus は +これを「Linux」と名付けた[Torvalds 1999]． このカーネルは FSF のツール群や他の品々と組み合わせることができ，自由 -に配布可能で，しかも非常に役立つ OS を作ることができた． +に配布可能で，しかも非常に役立つ OS だった． この論文ではカーネル本体を「Linux カーネル」と呼び，組み合わせて作られ た全体のものを「Linux」と呼ぶことにする(この組み合せでなく，GNU/Linux という言葉が使われる場合も多い)． @@ -237,12 +238,12 @@ 色々な組織によって，利用可能な品々が色々な形で組み合わせられている． それぞれの組み合わせを「ディストリビューション」と呼び，ディストリビューション を開発している組織を「ディストリビュータ」と呼ぶ． -一般的なディストリビューションとしては RedHat, Mandrake, SuSE, +有名なディストリビューションには RedHat, Mandrake, SuSE, Caldera, Corel, Debian 等がある． この論文は特定のディストリビューションに依存しない．この論文で仮定する のは，カーネルのバージョンが 2.2 以降であることと，C ライブラリが glic 2.1 以降であることである．この仮定は，現在の主要な Linux ディストリビューション -に対しては本質的に有効である． +に対しては基本的に有効である．

このような「フリーソフトウェア」への注目が高まるとともに， -フリーソフトウェアの定義し説明する必要性が高まってきた．広く用いられて +フリーソフトウェアを定義し，説明する必要性が高まってきた．広く用いられて いる用語は「オープンソースソフトウェア」であり，その定義は [OSI 1999] で詳しく述べられている． Eric Raymond [1997, 1998] はフリーソフトウェアの開発プロセスを考察した @@ -276,7 +277,7 @@ 意図的に UNIX に似せてある． したがって，UNIX の教訓は Linux にも当てはまり，それはセキュリティにつ いても言える． -この論文に書かれている情報の多くは実際にはどのような UNIX 的 OS にも当 +この論文に書かれている情報の多くは，実際にはどのような UNIX 的 OS にも当 てはまるが，Linux の利用者が Linux の機能を生かせるようにするため， Linux 固有の情報も意図的に加えている． この論文は扱う対象を絞るため，意図的に Linux だけに焦点を当てている． @@ -295,10 +296,10 @@ Section 3 summarizes key Linux security mechanisms. --> -Linux は UNIX に似せてあり，UNIX のセキュリティ機構を備えている． +Linux は UNIX に似せて作られたものなので，UNIX のセキュリティ機構を備えている． その機構に含まれるのは，各プロセスに対するユーザ ID と グループ ID (uid と gid)， -ファイルシステムの読み取り，書き込み，実行のパーミッション(ユーザ， -グループ，全体に対する)，System V のプロセス間通信(IPC)，ソケットベース +ファイルシステムの読み取り/書き込み/実行の(ユーザ/グループ/全体に対する) +パーミッション，System V のプロセス間通信(IPC)，ソケットベース の IPC(ネットワーク通信を含む)等である． UNIX システムに関する一般的な知識については Thompson [1974] や Bach [1986] を参照すること．これらの文献では基本的なセキュリティ機構についても述べ @@ -359,13 +360,14 @@ as well as ensuring that it receives widespread review and that any identified problems are fixed [Schneier 1999]. --> -防御機構は攻撃者に中身を知られないことに頼ってはならない．その逆に， -防御機構そのものの内容は公開されているべきで，パスワード等の比較的少数 -(しかも容易に変更可能な)要素に頼るべきである．そうすれば，数多くの +防御機構は，「攻撃者が機構の仕組みを知らないこと」をあてにしてはならない． +逆に防御機構そのものの内容は公開されているべきで，機構の安全性は +パスワード等，比較的少数の +(しかも容易に変更可能な)要素に依存すべきである．そうすれば，数多くの 第三者の検証を受けることが可能となる． Bruce Schneier は，賢い技術者は「セキュリティに関することは全て -オープンソースコードに頼るべき」であると指摘しており，また， -オープンソースコードは多くの人に検閲されることと識別された問題は全て +オープンソースコードに頼るべき」であると指摘している．彼はまた， +オープンソースコードは多くの人に検閲されること，見付かった問題は全て 解決することを確かめている[Schneier 1999]． + バッファオーバーフローのような問題(後述)には注意すること． -バッファオーバーフローが起きると，信頼できないユーザがビューアに任意の -プログラムを実行させることを許してしまうことがある． +バッファオーバーフローが起きると，信頼できないユーザが +ビューア経由で任意のプログラムを実行できてしまうことがある． + システム管理者(root)が使うアプリケーションプログラム． -この種のプログラムは，システム管理者でないユーザが設定できる情報を信用 +この種のプログラムは，システム管理者でないユーザが変更できる情報を信用 すべきでない． -この論文の大部分では C で書いたプログラムに偏った説明をしており， -C++, Perl, Python, Ada95, Java といった他のプログラムについては，多少 -の注意をしているに留まっている． +この論文の大部分では， C で書いたプログラムに対する暗黙の偏向がある． +ただし C++, Perl, Python, Ada95, Java といった他のプログラムについても， +多少記述している． その理由は，Linux 上で安全なプログラムを実装するためのもっとも一般的な 言語が C だからであり(ただし CGI スクリプトは除く．この分野では Perl が よく使われる)，他の多くの言語の実装も C ライブラリを呼び出すからである． @@ -580,9 +586,12 @@ can be profoundly different. --> 安全なプログラムを書く上で最も難しいのは，このようなプログラムを書く際 -には普段とは違った心持ち，つまり神経質な心持ちが必要な点である． +には普段とは違った心構えが必要となる点である．短く言えば「神経質な心構え」 +が必要となる． その理由は，間違い(欠陥，バグとも呼ばれる)がもたらす影響が大きく異なる からである． +

一般目的のサーバおよび setuid/setgid されたプログラムについては，重要 -な文献がたくさんある(ただし，その一部は参考文献としての紹介がなければ +な文献がたくさんある(ただし，その一部はどこかで引用されていなければ 探すのが困難である)． 勧められていることの中には注意して扱わなければならないものもある． -例えば Anonymous [不明] は，通常 access(3) に伴って起こる危険な -競合状態に触れないで access(3) の使用を推奨している． +例えば，access(3) に通常存在する危険な +競合状態に触れずに access(3) の使用を推奨している [不明] ような人もいる．

-この論文は，最も役立つガイドラインであると筆者が考えるものをまとめたも +この論文は，非常に役立つと筆者が考えたガイドラインのをまとめたも のである．したがって，全ての可能性を網羅したガイドラインではない． この論文の構成は筆者独自のものであり(各リストはそれぞれ独自の異なる 構成を持つ)，Linux 専用のガイドライン(例: ケーパビリティや fsuid 値等) @@ -892,7 +902,7 @@ makes it easier to use. --> これらの情報の多くが分散している．重要な情報をひとつのまとまった -文書にしておくと使いやすいと考えられる． +文書にしておけば使いやすい． 多くのプログラミングガイドは，Linux のセキュリティ関連の部分を切り詰め， -重要な情報を飛ばしている．特にこのようなガイドでは，何かの「使い方」を -一般的な言葉で説明しているが，その使い方に影響を与えるセキュリティ属性 +重要な情報を飛ばしている．特にこのようなガイドでは，何かの「使い方」の +一般的な内容は説明しているが，その使い方に影響を与えるセキュリティ属性 については体裁しか整えていないことが多い．その逆に，マニュアルページ には個々の関数についての詳しい情報が載っているが，マニュアルページでは 往々にして森の中に木が埋もれてしまうことになる． @@ -1027,8 +1037,8 @@ --> まずは基礎を説明する． Linux は基本的に 2 つの部分に分けられる．すなわち Linux カーネル -(カーネルモジュールを含む)と「ユーザ空間」である．ユーザ空間においては -様々なプログラムがカーネル上で動作する． +(カーネルモジュールを含む)と「ユーザ空間」である．ユーザ空間は +カーネルの上にあり、様々なプログラムがここで動作する． ユーザがログインすると，そのユーザ名はそのユーザが所属する 「UID(user id の意味)」と「GID(group id の意味)」を表す整数値に割り当てられる． UID 0 は特殊な権限(役割)を持つユーザで，伝統的に「root」と呼ばれる． @@ -1052,8 +1062,8 @@ then performs optimizations to get thread-level speeds). --> Linux では，ユーザレベルの動作はプロセスの実行として実装されている． -多くのシステムは「スレッド」を別にサポートしている．Linux では， -複数のスレッドを複数のプロセスを用いて実装されていることもある(この場 +多くのシステムは分離された「スレッド」をサポートしている．Linux では， +複数のスレッドが複数のプロセスを用いて実装されていることもある(この場 合，Linux カーネルはスレッドレベルの速度を得るための最適化を実行する)． -グループ群 - ユーザが所属しているグループ(GID)のリスト． +groups - ユーザが所属しているグループ(GID)のリスト． Linux バージョン 2.2 で「POSIX ケーパビリティ」の内部サポートが追加さ -れた．POSIX ケーパビリティは，通常は root が持っている権限を多数の，よ -り細かい権限に分割するといった機能に対応する． +れた．POSIX ケーパビリティは，通常は root が持っている権限を，よ +り細かい多数の権限に分割するといった機能に対応する． POSIX ケーパビリティは IEEE 標準のドラフトで定義されている．したがって， これは Linux 固有の機能ではないが，他の UNIX 的システムではあまり サポートされていない． @@ -1193,8 +1204,8 @@ A sample tool that takes advantage of this is LCAP at . --> -最終的な目的は，ファイルシステム内のファイルにケーパビリティを割り当て -られるようにすることであるが，この論文の執筆時点では，その機能にはまだ +最終的には，ファイルシステム内のファイルにケーパビリティを割り当て +可能にすることが目指されているが，この論文の執筆時点では，その機能にはまだ 対応していない． ケーパビリティの転送機能には対応しているが，この機能はデフォルトで無効 にされている． @@ -1232,8 +1243,8 @@ A process can execute a different program by calling execve(2), or various front-ends to it (for example, see exec(3), system(3), and popen(3)). --> -プロセスの生成は fork(2), 使用が勧められない vfork(2)，そして Linux 固有の -clone(2) を使って生成できる．これらのシステムコールは全て，既にある +プロセスの生成には， fork(2), 使用が勧められない vfork(2)，そして Linux 固有の +clone(2) が使える．これらのシステムコール全ては，既にある プロセスを複製し，2 つのプロセスを作成する． プロセスは execve(2) とその各種フロントエンド(例えば exec(3), system(3), and popen(3) を参照)を呼び出すことによって別のプログラムを @@ -1250,7 +1261,7 @@ --> プログラムが実行された時にそのファイルの setuid ビットか setgid ビット が立っていると，そのプロセスの EUID (setuid の場合)または EGID (setgid -の場合)がそのファイルに設定される． +の場合)がファイルの値に設定される． Linux では，シェルスクリプト等の普通のスクリプトではこのような操作は行 われない点に注意すること．この操作をスクリプトに対して行うのは セキュリティ的な危険が多くあるからである(他の UNIX 的 OS には setuid @@ -1286,9 +1297,8 @@ RUID, EUID, SEUID, or current FSUID values. --> FSUID プロセス属性は，NFS サーバ等のプログラムに対し， -プロセスにシグナルを送る UID パーミッションを与えることなしに -指定されたいくつかの UID に関するファイルシステムの権限だけに限定して -与える許可を行うための属性である． +ある UID の権限をファイルシステム関係のものに限って許可するためのものである。 +その UID 権限でプロセスにシグナルを送ることはできなくする。 EUID が変更されると，FSUID は必ず新しい値に変更される．つまり， FSUID 値 は setfsuid(2) (Linux 固有のシステムコール)を使わなくても変わ る場合がある． @@ -1316,8 +1326,8 @@ キャラクタ特殊(デバイス)ファイル，ブロック特殊(デバイス)ファイルのいず れでもよい(このリストは find(1) コマンドで表示される)． ファイルシステムオブジェクトはファイルシステム上に集められる． -ファイルシステムは親となるファイルシステム上のディレクトリにマウントや -アンマウントが行える． +ファイルシステムは親となるファイルシステム上のディレクトリに +マウント/アンマウントできる． ファイルシステムはファイルと少し異なるアクセス制御属性を持ち， アクセス制御はマウント時に選択したオプションの影響を受ける． -追加限定ビット - ファイルシステムオブジェクトには追加のみが許可 +追加限定ビット - ファイルシステムオブジェクトに追加のみが許可 される．このビットの設定と解除を行えるのは root だけである． この機能をサポートしているのは ext2 ファイルシステムだけであり，全ての UNIX システムで(あるいは全ての Linux 用ファイルシステムでさえ)広く使え @@ -1463,6 +1473,7 @@ ファイルシステムによっては，一部のアクセス制御値をサポートしていないこ とがある．繰り返しになるがこのようなファイルシステムの扱いについては mount(1)を参照すること． +

作成時の初期値

+