Kentaro Shirakata
argra****@users*****
2006年 11月 2日 (木) 18:10:36 JST
Index: docs/perl/5.6.1/perlsec.pod
diff -u /dev/null docs/perl/5.6.1/perlsec.pod:1.1
--- /dev/null Thu Nov 2 18:10:36 2006
+++ docs/perl/5.6.1/perlsec.pod Thu Nov 2 18:10:36 2006
@@ -0,0 +1,492 @@
+=encoding euc-jp
+
+=head1 NAME
+
+=begin original
+
+perlsec - Perl security
+
+=end original
+
+perlsec - Perl のセキュリティ
+
+=head1 DESCRIPTION
+
+Perlは、プログラムが setuid や setgid されるような特別な権限を付加されて
+実行されたときでもセキュリティ保持が容易になるように設計されています。
+スクリプトの一行ごとの多重置換を行うことに基づいているような大部分の
+コマンドラインシェルとは違って、Perl は隠れた障害が少ないような、
+より便利な評価手法を用いています。
+それに加えて Perl はより多くの組み込み関数を持っているので、
+ある目的を達成するために(信頼できないかもしれないような)
+外部プログラムを使うことが少なくてすむのです。
+
+Perl は、そのプログラムが異なる実ユーザー ID、実効ユーザー ID、実グループ ID、
+実効グループ ID を使って実行されることを検出したときに、
+自動的に I<汚染モード> (taint mode) と呼ばれる特別なセキュリティチェックの
+セットを有効にします。
+UNIX パーミッションにおける setuid ビットはモード 04000 で、
+setgid ビットはモード 02000 です。
+これらは重複してセットすることもできます。
+汚染モードは、コマンドラインフラグ B<-T> を使って陽に有効にすることもできます。
+このフラグはサーバープログラムであるとか、
+CGI スクリプトのような、他の誰かにすりかわって実行されるプログラムに
+使うことを B<強く> 勧めます。
+
+このモードで動作しているとき、Perl は明白な罠と隠れた罠の両方に対処するために
+I<汚染検査> (taint check) と呼ばれる特別な警戒を行います。
+これらのチェックの幾つかは、単純です。
+path ディレクトリが他から書き込み可能でないことを検査するといったことがそうです。
+注意深いプログラマーは常にこれらのことはチェックしています。
+このほかのチェックはしかしながら、言語自身によって最も良くサポートされます。
+そして、これらのチェックは特に set-id された Perl プログラムを
+対応する C プログラムよりも安全にするのに貢献するのです。
+
+=begin original
+
+You may not use data derived from outside your program to affect
+something else outside your program--at least, not by accident. All
+command line arguments, environment variables, locale information (see
+L<perllocale>), results of certain system calls (readdir(),
+readlink(), the variable of shmread(), the messages returned by
+msgrcv(), the password, gcos and shell fields returned by the
+getpwxxx() calls), and all file input are marked as "tainted".
+Tainted data may not be used directly or indirectly in any command
+that invokes a sub-shell, nor in any command that modifies files,
+directories, or processes, B<with the following exceptions>:
+
+=end original
+
+自分のプログラムの外側から来たデータをプログラムの外の何かに影響を
+及ぼすために使うことは、少なくともアクシデントででもなければ、できません。
+すべてのコマンドライン引数、環境変数、ロケール情報(L<perllocale> を参照)、
+幾つかのシステムコールの結果(readdir(), readlink(), shmread() の変数、
+msgrcv() が返したメッセージ、パスワード、getpwxxx() 呼び出しが返した
+gecos フィールドとシェルフィールド)、すべてのファイル入力といったものは
+“汚染された”(tainted) と目印が付けられます。
+汚染されたデータは直接、間接を問わずサブシェルを起動するコマンドに使うことも、
+ファイルやディレクトリ、プロセスに変更を加えるようなコマンドに
+使うこともできません。但し B<以下の例外> があります。
+
+=over 4
+
+=item *
+
+=begin original
+
+If you pass a list of arguments to either C<system> or C<exec>,
+the elements of that list are B<not> checked for taintedness.
+
+=end original
+
+C<system> あるいは C<exec> に対する引数リストの
+要素として渡した場合には、その要素に対する汚染検査は B<行われません>。
+
+=item *
+
+=begin original
+
+Arguments to C<print> and C<syswrite> are B<not> checked for taintedness.
+
+=end original
+
+C<print> と C<syswrite> の引数に対する汚染検査は B<行われません>。
+
+=back
+
+=begin original
+
+Any variable set to a value
+derived from tainted data will itself be tainted, even if it is
+logically impossible for the tainted data to alter the variable.
+Because taintedness is associated with each scalar value, some
+elements of an array can be tainted and others not.
+
+=end original
+
+以前に汚染されていた値を参照していた式において設定された値はすべて
+汚染されます。
+これはたとえ、論理的に汚染された値が、式の値に影響を及ぼさないと
+言い切れる場合であっても変わりません。
+汚染は各スカラー値に結び付けられるので、配列の幾つかの要素が汚染されていて、
+そのほかの要素はそうではないということもありえます。
+
+=begin original
+
+For example:
+
+=end original
+
+例を示します:
+
+ $arg = shift; # $arg は汚染された
+ $hid = $arg, 'bar'; # $hid も汚染された
+ $line = <>; # 汚染された
+ $line = <STDIN>; # これも汚染された
+ open FOO, "/home/me/bar" or die $!;
+ $line = <FOO>; # まだ汚染されている
+ $path = $ENV{'PATH'}; # 汚染されているが、下記を参照のこと
+ $data = 'abc'; # 汚染されていない
+
+ system "echo $arg"; # 安全ではない
+ system "/bin/echo", $arg; # 安全 (shを使いません)
+ system "echo $hid"; # 安全ではない
+ system "echo $data"; # PATHを設定するまでは安全ではない
+
+ $path = $ENV{'PATH'}; # $path が汚染された
+
+ $ENV{'PATH'} = '/bin:/usr/bin';
+ delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
+
+ $path = $ENV{'PATH'}; # $path は汚染されていない
+ system "echo $data"; # これで安全!
+
+ open(FOO, "< $arg"); # OK - 読み込みのみのファイル
+ open(FOO, "> $arg"); # Not OK - 書き込みしようとしている
+
+ open(FOO,"echo $arg|"); # Not OK, but...
+ open(FOO,"-|")
+ or exec 'echo', $arg; # OK
+
+ $shout = `echo $arg`; # 安全でない。$shoutは汚染された。
+
+ unlink $data, $arg; # 安全でない
+ umask $arg; # 安全でない
+
+ exec "echo $arg"; # 安全でない
+ exec "echo", $arg; # 安全 (シェルを使いません)
+ exec "sh", '-c', $arg; # 安全と解釈される。ああ!
+
+ @files = <*.c>; # 安全でない (readdir() のようなものを使う)
+ @files = glob('*.c'); # 安全でない (readdir() のようなものを使う)
+
+安全でないことをやろうとすると、"Insecure dependency" や
+"Insecure $ENV{PATH}" のような致命的エラーとなるでしょう。
+安全でない B<system> もしくは B<exec> を書くことはできるけれども、
+それは先の例で"安全である"あったようなことを陽にやることによってのみだと
+いうことに注意してください。
+
+=head2 Laundering and Detecting Tainted Data
+
+(汚染されたデータの検出と洗浄)
+
+ある変数が汚染されたデータを保持しているかどうかを検査するため、そして、
+"Insecure dependency" メッセージの引き金になる可能性があるかどうかを
+検査するために、あなたの最も身近にある CPAN のミラーサイトで
+F<Taint.pm> モジュールを探してみてください。
+これは 1997 年の 11 月に入手できるようになるでしょう。
+あるいは、以下のような関数 I<is_tainted()> を使うことができます。
+
+ sub is_tainted {
+ return ! eval {
+ join('', ＠ _), kill 0;
+ 1;
+ };
+ }
+
+この関数はある式のどこかにある汚染されたデータが式全体を汚染してしまうことを
+利用しています。これはすべての演算子に対して、
+そのすべての引数が汚染されているかどうかの検査をするので効率は良くないでしょう。
+その代わりに、一部の式において汚染された値にアクセスして
+式全体が汚染されたとみなされるような場合には、もっと効率が良くて
+保守的な方法が使われます。
+
+しかし、汚染の検査は面倒です。あなたのデータの汚染を取り除くだけと
+いうこともあるでしょう。汚染検査機構をバイパスするためのただ一つの方法は、
+マッチした正規表現のサブパターンを参照することです。
+Perl は、あなたが $1、$2 などを使って部分文字列を参照したときに、
+あなたがパターンを記述したときに何を行うのかを知っていたと仮定します。
+つまり、汚染されていないものを束縛しないか、機構全体を無効にするということです。
+これは、変数がなんらかの悪いキャラクターを持っているかどうかを
+検査するというのではなく、変数が良いキャラクターのみを持っていることの
+検査には都合が良いです。
+これは(あなたが考えもしないような)悪いキャラクタを見失うことがあまりにも
+簡単であるからです。
+
+以下に示す例は、データに“語”(アルファベット、数字、アンダースコア)の
+キャラクター、ハイフン、アットマーク、ドット以外のものが入っていないことを
+検査するものです。
+
+ if ($data =~ /^([-\@\w.]+)$/) {
+ $data = $1; # $data は汚染されていません
+ } else {
+ die "Bad data in $data"; # これをどこかで記録する
+ }
+
+これはかなり安全です。なぜなら C<\w+> は通常シェルのメタキャラクターには
+マッチしませんし、ドットやダッシュなどのシェルにとって特別な意味を
+持つようなものにもマッチしないからです。
+C</.+/> を使うのは、これはすべてを通してしまうのに Perl はそれを
+チェックしませんから、理論的には安全ではありません。
+汚染を取り除くときには、自分のパターンについて十二分に注意せねばなりません。
+正規表現を使ったデータの洗浄は、先に説明したより低い特権度の子プロセスを
+fork するための戦略を使うまでは汚れたデータの汚染除去 B<のみ> の機構です。
+
+先の例では、C<use locale> が有効であるときには $data の汚染除去を行いません。
+なぜなら、C<\w> にマッチするキャラクターはロカールによって決定されるからです。
+Perl は、ロカールで決まることを、それがプログラムの外から来たデータから
+構成されているという理由によって信用できないものとみなします。
+もしロカールを考慮したプログラムを書いていて、C<\w> を含んだ正規表現で
+データの洗浄を行いたいというのなら、式の置かれたのと同じブロックの前の部分に
+C<no locale>を置きます。L<perllocale/SECURITY> に詳しい説明と例があります。
+
+=head2 Switches On the "#!" Line
+
+("#!" 行のスイッチ)
+
+自分の作ったスクリプトをコマンドのように使えるようにしたとき、システムは
+perl に対して、スクリプトの #! の行からコマンドラインスイッチを渡します。
+Perl は、setuid(あるいは setgid) されたスクリプトに与えられた
+コマンドラインスイッチが #! 行にあるものと本当に一致するかどうかを検査します。
+一部の UNIX や UNIX 風の環境では #! 行には一つのスイッチしか置けないので、
+そういったシステムでは C<-w -U> といった形式ではなく
+C<-wU> のようにする必要があるでしょう(これは #! をサポートしていて、
+setuid や setgid スクリプトが使える UNIX 環境や UNIX に似た環境でのみ
+行なわれることです)。
+
+=head2 Cleaning Up Your Path
+
+(実行パスを洗浄する)
+
+"Insecure C<$ENV{PATH}>" メッセージに対処するために、C<$ENV{'PATH'}> に
+既知の値を設定する必要があります。そして path に含まれている各ディレクトリは、
+そのディレクトリの所有者やグループ以外からの書き込みを
+禁じていなければなりません。実行しようとしているファイルをフルパスで
+書いたとしてもこのメッセージがでるので、びっくりすることがあるかもしれません。
+このメッセージはプログラムのフルパスを書かなかったから出力されるではなく、
+環境変数 PATH を設定しなかったり安全でない値を
+設定したりしたために出力されるのです。
+Perl は対象となっている実行ファイルが自分自身を方向転換したり、
+PATH を参照して別のプログラムを起動したりするかどうかを知ることができないので、
+確実に自分で PATH を設定するようにします。
+
+=begin original
+
+The PATH isn't the only environment variable which can cause problems.
+Because some shells may use the variables IFS, CDPATH, ENV, and
+BASH_ENV, Perl checks that those are either empty or untainted when
+starting subprocesses. You may wish to add something like this to your
+setid and taint-checking scripts.
+
+=end original
+
+この問題を引き起こす環境変数は PATH だけではありません。
+一部のシェルでは、IFS、CDPATH、ENV、BASH_ENV のような環境変数を
+使っていますから、Perl はこれらの変数がからであるかあるいは
+サブプロセスが起動したときに汚染されていないかどうかチェックします。
+setid していたり、汚染検査をするスクリプトに
+以下のような行を付け加えたくなるかしれません。
+
+ delete @ENV{qw(IFS CDPATH ENV BASH_ENV)}; # %ENVを安全にする
+
+このほかの、汚染された値を使っているかどうかに注意を払わないような
+操作によってトラブルに巻込まれる可能性もあります。
+ユーザーが使うようなファイル名を扱うファイル検査の使用を賢明なものにします。
+可能であれば、ファイルをオープンした B<その後で> 適切にスペシャルユーザー
+(グループも!)の特権を落とします。
+Perl はあなたが読み出しのために汚染されたファイル名を使ってファイルを
+オープンすることを妨げませんから、出力の際には注意しましょう。
+汚染検査機構はばかばかしいミスに対応するためのものであって、
+必要なことを取り除くものではありません。
+
+Perl は、C<system> や B<exec> に対してシェルのワイルドカードが
+あるかもしれないような文字列ではなく陽にパラメータリストを渡した場合には、
+ワイルドカードの展開のためにシェルを呼び出したりしません。
+残念なことに、B<open>、B<glob>、逆クォートといったものはそういった別の
+呼び出し手順を提供していないので、より多くのごまかしが必要とされます。
+
+Perl は、setuid や setgid されたプログラムから安全にファイルやパイプを
+オープンする方法を提供しています。これは単に、汚れ仕事をするための
+制限された権利を持った子プロセスを生成するというものです。
+まず最初に、パイプによって親プロセスと子プロセスとを繋ぐ構文の
+特別な B<open> を使って子プロセスをforkします。
+このとき、子プロセスはその ID セットをリセットしさらにその他の
+プロセス毎の属性をリセットして、オリジナルの、
+もしくは安全な既知の値へと戻します。
+それからもはや何の特別のパーミッションも持っていない子プロセスが
+B<open> などのシステムコールを実行します。
+ファイルやパイプは親プロセスよりも低い特権の元で実行されている
+子プロセスでオープンされたので、すべきではないようなことを
+ごまかしておこなうことはできません。
+
+以下に示すのは、安全に逆クォートを行う方法です。
+どのようにして B<exec> はシェルが展開するかもしれない文字列を伴って
+呼び出されないようになっているかに注目してください。
+これはシェルをエスケープする目的には最善の方法というわけではありません。
+これは単に、シェルを呼び出さないというだけです。
+
+ use English;
+ die "Can't fork: $!" unless defined($pid = open(KID, "-|"));
+ if ($pid) { # parent
+ while (<KID>) {
+ # do something
+ }
+ close KID;
+ } else {
+ my @temp = ($EUID, $EGID);
+ my $orig_uid = $UID;
+ my $orig_gid = $GID;
+ $EUID = $UID;
+ $EGID = $GID;
+ # Drop privileges
+ $UID = $orig_uid;
+ $GID = $orig_gid;
+ # Make sure privs are really gone
+ ($EUID, $EGID) = @temp;
+ die "Can't drop privileges"
+ unless $UID == $EUID && $GID eq $EGID;
+ $ENV{PATH} = "/bin:/usr/bin"; # Minimal PATH.
+ # Consider sanitizing the environment even more.
+ exec 'myprog', 'arg1', 'arg2'
+ or die "can't exec myprog: $!";
+ }
+
+C<readdir> を代わりに使うことができるにしても、同様の戦略が C<glob> を
+通じたワイルドカードの展開でも有効です。
+
+汚染検査は、農場をくれてやる (give away the farm)ためのプログラムを
+記述することを自分自身に任せないということではなくて、
+最終的にそれをつかって良からぬなにかを行おうとしているだれかを
+信頼する必要がないというときに最も便利なものです。
+これは、set-id プログラムや、CGI プログラムのように誰かに
+すり変わって起動されるようなプログラムに便利なセキュリティチェックです。
+
+しかしながら、これは良からぬなにかを行おうはしないコードの作者を
+信用しないということとは明らかに違います。
+これは誰かが、プログラムをあなたが今まで見たことのないようにいじって
+"Here, run this" といわせるようなときに必要な種類の信用です。
+この種の安全性のために、Perl の配布パッケージに標準で含まれている
+Safe モジュールをチェックしてみてください。
+このモジュールはプログラマーがすべてのシステム操作をトラップし、
+名前空間のアクセスが注意深く制御されるような
+特別な仕切り(compartment)をセットアップすることを許します。
+
+=head2 Security Bugs
+
+(セキュリティバグ)
+
+スクリプトと同じくらい柔軟に特別な権限をシステムに与えて
+しまう類の明白な問題の他に、多くの UNIX では、set-id されたスクリプトは
+本質的に安全でない権利を最初から持っています。その問題とは、
+カーネルにおける競合条件です。インタープリターを実行するために
+カーネルがファイルをオープンするのと、(set-id された)インタープリターが
+起動してファイルを解釈するために再度オープンするその間に、
+問題のファイルが変更されるかもしれません。
+特に、使っているシステムがシンボリックリンクをサポートしている場合には。
+
+幸運なことに、このカーネル“仕様”は使用禁止にできることもあります。
+残念なことに禁止には二つのやり方があります。
+システムは set-id ビットがセットされているスクリプトを単純に禁止することが
+できますが、このときはなにもできません。
+もう一つ、スクリプトに付けられた set-id ビットを単純に
+無視してしまうことができます。
+後者の場合、Perl スクリプトにある setuid/gid ビットが無用なものではないと
+Perl が認識したときに、Perl は setuid や setgid の仕掛けを
+模倣(emulate)することができます。
+この機能は、必要とされるときに自動的に起動される B<suidperl> と呼ばれる
+特別な実行ファイルを通じて行なわれます。
+
+しかし、kernel set-id スクリプト機能が禁止されていなければ、Perl は
+あなたの set-id スクリプトは安全ではないとやかましく主張することでしょう。
+このとき、あなたは kernel set-id スクリプト機能を禁止するか、
+スクリプトを C のラッパーで包んでしまうかのいずれかが必要です。
+C ラッパーは、Perl プログラムを呼び出すことを除いては
+何もしないプログラムです。
+コンパイルされたプログラムは set-id されたスクリプトに関する
+カーネルのバグには影響されません。
+次の例は、C で書いた単純なラッパーです。
+
+ #define REAL_PATH "/path/to/script"
+ main(ac, av)
+ char **av;
+ {
+ execv(REAL_PATH, av);
+ }
+
+このラッパーをコンパイルして実行ファイルにし、スクリプトではなく
+B<この実行ファイル> を setuid したり setgid します。
+
+近年、ベンダーはこのようなセキュリティバグに対する耐性を備えたシステムを
+提供しはじめました。
+そのようなシステムでは、インタープリターを起動するためにカーネルに
+set-id スクリプトが渡されたときにそのパス名をそのまま使うのではなく、
+代わりに I</dev/fd/3> を渡します。
+これはスクリプトでは、あらかじめオープンされている特別なファイルですから、
+邪悪なスクリプトをこじ入れるためにつかうことはできません。
+こういったシステムにおいては、Perl は
+C<-DSETUID_SCRIPTS_ARE_SECURE_NOW> を付加してコンパイルすべきでしょう。
+Perl を構築する B<Configrue> プログラムは自分自身でこれを
+見つけ出そうとするので、あなたが特別な何かをしなければならない、
+ということはありあません。SysVr4 の最近のリリースのほとんどや BSD4.4 は
+このアプローチをカーネルの競合条件を避けるために使っています。
+
+=begin original
+
+Prior to release 5.6.1 of Perl, bugs in the code of B<suidperl> could
+introduce a security hole.
+
+=end original
+
+リリース 5.6.1 以前の Perl では、B<suidperl> にあったバグによって、
+セキュリティホールが持ち込まれる可能性がありました。
+
+=head2 Protecting Your Programs
+
+(あなたのプログラムを守る)
+
+ここで挙げるのは、あなたの Perl プログラムのソースコードをさまざまな
+“セキュリティ”のレベルで隠す方法です。
+
+しかしまず最初にいっておきますが、ソースコードの読み込み権限を
+落とすことは B<できません>。
+なぜなら、ソースコードは、コンパイルやインタープリットするために
+読めるようになっていなければならないからです(これは、CGI スクリプトのソースが
+web の利用者から見ることができないというのとは違います)。
+このため、パーミッションは 0755 レベルにしておかなければならないのです。
+これによってあなたのローカルシステム上のユーザーはあなたのソースを
+見ることだけになります。
+
+一部の人達はこれをセキュリティ上の問題であると考えています。
+あなたのプログラムが安全でないことを行っていて、
+他人がそういったセキュリティの隙間をこじ開ける方法を知らないことに
+頼っているのなら、それは安全ではないのです。
+これはある人が安全でないことがらを見つけだし、
+ソースを見ることなしにそれをこじ開けることの要因となります。
+明快さを通したセキュリティはバグを直すのではなく隠すことに比べれば、
+セキュリティをほんの少しだけしか傷つけません。
+
+ソースフィルター(CPAN にある Filter::*)を通して暗号化しようと
+することはできますが、クラッカーがそれを複号化することは可能でしょう。
+先に説明したバイトコードコンパイラーとインタープリターを使うことも
+できますが、クラッカーはそれを逆コンパイルすることができるかもしれません。
+ネイティブコードコンパイラーを使おうとしても、クラッカーはそれを
+逆アセンブルできるかもしれません。こういったことは、他人があなたの
+プログラムを手に入れようとすることを難しくしたりしますが、
+プログラムを決定的に隠すことは誰にもできないのです(このことは、
+Perl に限らずすべての言語にあてはまります)。
+
+他人があなたのプログラムから受ける利益について気にしているのであれば、
+制限つきライセンスがあなたに法的な安全を与えるでしょう。
+あなたのソフトウェアのライセンスに、“本ソフトウェアは XYZ Corp.による、
+公表されていない独占的ソフトウェアです。あなたが使用するために
+これにアクセスすることは許可されておらず云々”のような脅し文句を
+付けておきます。あなたのライセンスが確実に有効なものとなるように、
+弁護士と相談したほうが良いでしょう。
+
+=head1 SEE ALSO
+
+=begin original
+
+L<perlrun> for its description of cleaning up environment variables.
+
+=end original
+
+L<perlrun> には環境変数を洗浄する方法が記述されています。
+
+=begin meta
+
+Created: KIMURA Koichi
+Updated: Kentaro Shirakata <argra****@ub32*****>
+
+=end meta
+