連載 / IJN Ⅸ知恵袋ーの 逆引きデータベース (localhost. rev ファイル ) 図 12 図 13 192 .36. 148 . 17 1 IN IN IN SOA NS PTR ns. f00 . co ・」 p ・ 1 10800 1800 4320000 86400 ) ns . f 00. co ・ J p ・ postmaster. f00. CO. 」 p , 通し番号 ; 3 時間経過したら問合せ ; 30 分ごとに再試行 ; 50 日で無効化 有効時間は 1 日 localhost . f00. co ・ JP ・ ) レート・ネームサー / 、一一覧 (root. cache ファイル ) 3600000 IN NS A . ROOT—SERVERS . NET . B . ROOT—SERVERS . NET . C . ROOT—SERVERS . NET . D . ROOT—SERVERS . NET . E . ROOT-SERVERS . NET . F . ROOT—SERVERS . NET . G . ROOT—SERVERS . NET . H . ROOT—SERVERS . NET . I . ROOT—SERVERS . NET . J . ROOT—SERVERS . NET . K . ROOT—SERVERS . NET . 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 3600000 A NS A NS A NS A NS A NS A NS A NS A NS A NS A NS A 図 14 resolv. conf ファイル domain f00 . CO ・」 p nameserver 127.0.0. 1 ルートサーバーの情報 自分が管理するドメインより上位のドメインの言 t 算機 名に対する問合せを受けたネームサーバーは、ルート・ ネームサーバーへ問合せにいかねばなりません。ルー ト・ネームサーバーの情報は起重加芋にファイルから読み 込みます。現在、世界には 11 のルート・ネームサーバ ーがあります。最新のルート・ネームサーバーの情報は ftp://ftp.rs.internic.net/domain/named.root から入 34 A . ROOT—SERVERS . NET. 198 .41.0.4 B . ROOT—SERVERS . NET . 128.9 . 0 . 107 C . ROOT—SERVERS . NET . 192.33.4. 12 D . ROOT—SERVERS . NET . 128.8. 10.90 E . ROOT—SERVERS . NET . 192 .203.230. 10 F . ROOT—SERVERS . NET . 192. 5 . 5 .241 G . ROOT—SERVERS . NET . 192. 112 .36.4 通常は /etc/named. boot を設定ファイルとして読み込み ためのオプション・スイッチです。指定しなかった場合、 を起動してみましよう。 -f は、設定ファイルを指定する 以上で、準備するファイルは終りです。ネームサーバー この数値は古い日罸にの名残です。 を特別に扱っているため、無効になることはありません。 すが、現在の BIND ではルート・ネームサーバーの情報 図 13 で、 2 列目の数値はレコードの有間の指定で ます。 になっており、そのまま root. cache ファイルとして使え します。図 13 は、ネームサーバーのデータベースの形式 手できます。図 13 にルート・ネームサーバーの情報を示 K . ROOT—SERVERS . NET . J . ROOT—SERVERS . NET . I . ROOT—SERVERS . NET . H . RO OT- SERVERS . NET . 198.41.0. 11 198.41 . 0. 10 128 . 63.2.53 ます。 UNIX MAGAZINE 1997.4

UNIX & Security 2 ■ 図 1 ソフトフックの利用 OS カーネル OS ファンクション リソース ネットワーク接続 プロセス ファイル アプリケーション プログラム システムへの ログイン 監査記録 特権アクセス accept ソフトフック accept connect open kill read ユーザー CO n nect close setuid 要求された アクション open 許可検査 setuid イス ュタ セデ イベント捕捉 メカニズム システムサービス または svc テープル ため、大規模な利用は難しい。さらに重要なのは、 UNIX 設けたりする。あるいは、セキュリティ上の不正がなかっ における最大のセキュリティ問題は、 root はいかなるセ たかを調べる方法もある ( モニタリング ) 。その結果、セ キュリティ対策の対象にもならない点である。 キュリティ対策の担当者や監査者は、新たに報告された OS のバグやセキュリティ・ホールを見張り、 OS のべン root であれは、いかなるファイルへのアクセスも可能 ダーからの定期的なバグフィックスやパッチに頼らざるを で、すべてのプロセスを終了させたり、システムを使えな えない。したがって、組織はセキュリティ侵害や不正侵 いようにすることができる。不正侵入の標的になるのはた 入を予防するのではなく、嘶変対策に追われるようになっ いてい root であり、その結果、 root の無制限の権限が てしまう。 悪用されてしまう。 root は監査言当求の変更や削除ができ るので、侵入者カイ為装したり、侵入窈亦を消すことも可 UNIX を全面的に書き直さなければ、予防的でセキュ 能になる。 root に糸寸的な権限が集中しているからこそ、 リティ侵害を防ぐ包括的なセキュリティ対策を実現し、 もっとも狙われやすいのだ。 root の権限を制御したうえでプライバシーや整合性、問題 の報告をおこなう機能は提供できないのだろうか。 MVS ■ UNIX のセキュリティの改善 におけるセキュリティ機能の実装方法をみれば、その答は 意外なことに、、書き直す必要はない " である。 MVS で用 UNIX の基本言には、包才乱勺なセキュリティ対策が いられている去を利用し、 OS の外部で稼動するセキュ 立てにくい要素がある。従来の手法の大半は UNIX のも リティ・システムをオ剽純勺に実装すれば、包括的なセキュ リティ対策が実現できる。高度な、ソフトフック " または つ制約の枠内での補足的な対策にすぎす、制約そのものに 踏み込むものではない。たとえば、いくつかの手法では、 リダイレクション手法の利用により、システムで発生する さまざまな出来事を把握し、制御できる。ソフトフック root のアカウントへのアクセスを制限するために、強力 な認証方式を導入したり、システムへのログインに制約を は、ユーサーのコードからシステムに移るところ、も・しく 118 UNIX MAGAZINE 1997.4

連載 / IJN Ⅸ知恵袋ーの 図 1 ネームサーバーの言聢ファイル列 0 . 0.127. in—addr. arpa directory cache pr lmary pr lmary pr lmary /var/named f00. co ・」 p 10 . 159. 133 . in—addr. arpa root . cache f00.20 Ⅱ e f00. 10ca1host . rev ・ノレート・ネームサーノヾー 30 は f00. co. jp です。 ち一 E げることにします。 ns. foo. co. jp カ壻理するドメイン IP アドレスが 133.159.10.1 であるネームサーバーを立 なお、今回の説明のために、 ns. foo. co. jp という名前で の書式を順ら細早説していきます。 以後これら窈青報を言当するデータベース・ファイル 算機名の場合、右にいくにしたがってより上位の組織を表 機名と IP アドレスの階層構造の違いによるものてす。計 スの記去か通常と逆になっています。この理由は、計算 始まる IP アドレスを示します。逆引きの場合、 IP アドレ ことです。 10.159.133. ⅲ - addr. arpa が 133.159.10. で は、その名のとおり、 IP アドレスから引・算機名を調べる データベース・ファイル名を指定しています。逆引きと しています。次の primary 行は、逆引き用のドメインと のデータベース・ファイル名が f 。。 . zo Ⅱ e であることを示 ることを宣言し、計算機名を IP アドレスに変換するため す。最初の primary 行は、 foo ・ co ・ jp ドメインを管理す ンを指定し、そのデータベース・ファイル名を指示しま primary で始まる行はネームサーバーカ壻理するドメイ バーの情報ですから、ドメインはルート (. ) になります。 した情幸ゞ央されるドメインです。ルート・ネームサー イル名です。 2 列目の、、 . " は root. cache ファイルに言当 タベース・ファイル名を指定します。 root. cache がファ cache 行はルート・ネームサーバーの情報を収めたデー データベース・ファイルを置くことが多いようです。次の クトリを指定します。 /var/named/ ディレクトリ以下に directory 行はデータベース・ファイルがあるディレ /etc/named. boot です。図 1 を見てください。 ルを書きます。通常、ネームサーバーの設定ファイルは 最初に、ネームサーバーか起重加こ読み込む設定ファイ ネームサーバー設定ファイル すようになりますが、 IP アドレスは逆に、右にいくにし たがってより下位の細織を表します。そのため、言当去が 逆になっています。最後の primary 行はローカルホスト の逆引きの設定です。 127.0.0.1 という IP アドレスから localhost. f00. co. jp という名前を引くために必要です。 ネームサーバーの設定ファイルは以上で完了です。た だし、ネームサーバーをより強靱にしたいと考えるのであ れは、ネームサーバーを多重化し、たとえ 1 つがダウン しても代わりのネームサーバーが対応するような仕組みを 作っておくべきでしよう。成疋ファイルのなかに primary という行がありましたが、これはプライマリ・ネームサー バーの成疋ファイルてイ吏われるものです。ネームサーバー にはプライマリ・ネームサーバーとセカンダリ・ネーム サーバーがあります。プライマリ・ネームサーバーはデー タベースの元締めで、あらゆる変更はプライマリ・ネーム サーバー上でおこなわれます。セカンダリ・ネームサーバ ーは負荷分散やバックアップを目的としたミラーサーバー です。セカンダリ・ネームサーバーは定期的にプライマリ・ ネームサーバーに接続し、最新のデータベース・ファイル を取得します。 セカンダリ・ネームサーバーの設定は彳あすることにし、 まずプライマリ・ネームサーバーのデータベース・ファイ ルの書き方をみていきましよう。 計算機名から IP アドレスへ DNS データベースのレコードの書式を図 2 に示しま す。 ん e リがデータベースを検索するときのキーです。 IP アド レス・データベースなら、計算機名になります。 s 。 c ← れ佖 me はデータベースのレコードの不鶤頁を示す文字列が入 ります。 DNS データベースのレコードには、表 1 て示す ような不軽頁があります。 表 1 に示したようなレコードを総称して、資源レコー UNIX MAGAZINE 1997.4

はユーザーのコードに戻るところに設けられる。 UNIX に も MVS にも基本的な機能 ( システムコールまたは SVC) から構成されるカーネルがあり、簡単なテープルを利用し てシステムの機能 (open や close など ) との対応をとっ ている。 MVS では SVC テーフフレ、 UNIX では syscall テープルがこれにあたる。 MVS の SAF では、この部分 でセキュリティに関するものは外部のセキュリティ・シス テムに受け渡すようになっている。 UNIX の脆弱性を補強 する場合も、このテープルカ硬われるだろう。事実、 SAF 機能力甘是供されるまで、 MVS はこのテープルによってセ キュリティに関連する出来事を孑足し、制御をセキュリ ティ・エンジンに渡していた ( 図 1 ) 。 この簡潔な実装により、効率的で容易な運用が可能にな ったのである。このようなアーキテクチャは、 UNIX の既 存のセキュリティ・メカニズムの変更を必要とせす、むし ろもともとの UNIX では捕らえられないものを孑﨓足する 補完的なシステムにすることかできる。このセキュリティ の実装は OS にとってほとんど邪魔にならす、また OS の機能への依存もきわめて小さい。このメカニズムの醐長 は、セキュリティに関する事柄が発生したという事実窈前 捉にあり、そオ功ゞいかにして起きたかは対象としない。 このアーキテクチャの実装には、従来の UNIX でとら れてきたセキュリティ対策より優れている点がいくつかあ る。これによって、 root の匍卩、 UNIX のセキュリティ の統一、ユーサーの牛付きアクセス、円滑な制が可能 になる。このガ去は、予防的なセキュリティ対策の実堤 ほかのガ去とは異なるセキュリティ対策の自重加勺な実施を 可能にする。いかなるルールでセキュリティを実施するか を決め、それを設定しさえすれば、その他のことはこのメ カニズムかすべて引き受けてくれる。 ソフトフックを用いて UNIX のセキュリティ上の弱 点を補強すれは、いちしるしい利朸ゞ得られる。このガ去 は、誰かが r 。。 t になりすますのを防ぐだけでなく、 root やプログラムの権限を制御し、 root のもっ弱点を克服す る。また、ユーザー・アカウントを作成したりパスワード を無効にできるアカウント管理者や、システム構成ファイ ルを保守するシステム管理者など、複数の管理者の root としての権限を制限できる。いかなる管理者も監査言求の 変更はできない。さらに、問題が発生しやすい sendmail や RPC などのようなサプシステムがシステム本に景 UNIX MAGAZINE 1997.4 UNIX & Security 2 0 をおよばさないようにすることもできる。 r 。。 t の権限で動 く sendmail プログラムについても、 /var/spool/mail にしかファイルを書き込めないようにして悪用を防げる。 システムを管理する権限は無条件に root に - 学えるのでは なく、システムの管理にあたる複数のイ頁できる管理者だ けに付与・してもよい。たとえーヨ殳ューサーが root になる 方法をみつけたとしても、 root の権限を悪用してシステ ムに損害を - 学えることはできなくなる。 MVS にならった UNIX セキュリティの : 見には、い くっか鮹夬すべき譏題か残っている。この力法を実用化す るには、 OS 内部の機能への依存がきわめて小さく、カー ネルの手直しが不要なアーキテクチャを使わねばならな い。したがって、可能なかぎりソフトフックに似たアーキ テクチャを利用する必要がある。さらに、最適なパフォー マンスを囎軍し、許可要求を効率的に処理してネットワー クのセキュリティ対策にともなう高コストという問題を回 避するものでなければならない。 このような間題か解決さ適切なアーキテクチャか利 用されれは、 UNIX でも MVS と同様なセキュリティを 実現できるだろう。 セキュリティ関連の製品およひ統合パッケージの研究発をおこ なう Memco Software のマーケティング担当部長。 10 年以 - E にわたって情幸支術の仕事に携わり、そのうちの数年間は大企業 ■ Dorin Miller ◎ 1996 , UNIX REVIEW (). S. A. ) UNIX REVIEW 1996 年 11 月号より 「 Security: UniX VS. Mainframes 」 を対象としたコンサルタントとして活重劜 119

UNIX & Security 2 ■ きるようになる。 UNIX で、ユーサー A がユーザー B の ID の代わりに自分のユーザー ID を使い、ユーサー B の権限を行使する 1 つの方法は、 su コマンド ( また は setuid システムコール ) を実行して有効なパスワード をユーサー B のユーサー ID に渡すことである。この手 法を利用した場合、ユーサーのパスワードが公表さセ キュリテイか破られたり不都合が生したりするおそ功ゞあ る。パスワードの変更を世界中に知らせ、そのパスワード がハードコードされている多数のスクリプトを更新しなけ ればならなくなるかもしれないのだ。しかも、このイはみ では John に特定の機能に限定した実行権限を与えるので はなく、 Linda ができることはすべて John にも実行可 能にしてしまう。 一方、 MVS ではユーサーにバッチジョブの投入を許 可し、ジョブ制御言語 (JCL) でユーザー名とパスワー ドを指定して (//JOBABC JOB( … ),USER=SOME BODY PASSWD=ACBDE) 、そのジョブに関する別 のユーザーの実行権限を与える。ただし、ユーザー ID の 入替えをより確実に管理するために、 MVS のセキュリテ イ・システムでは代理ユーサー (surrogate-user) という 考え方を導入している。このイ督はみ (ASID チェックとも 呼はれる ) では、ユーザーがはかのユーサーの権限を行使 できるのは、実行可能な権限がセキュリティ・データベー スに言当されており、かっパスワードを使用しない場合に 限定される。このようなイはみであれば、パスワードを配 布する必要はない。その代わり、ユーサー John が実行で きること ( ューザー Linda の権限て特定のタスクを実行 する ) を正確に主している。 MVS では、さらに監査ロ グによって該当するユーサーの行動とユーサー ID の入替 えをトレースできる。 UNIX では、パスワードカ印隹ーの認 証去であり、しかも多くのシステムでは、あるユーザー がほかのユーザー ID を使い始めると同時に監査言当求はも とのユーザー ID による行動を央しなくなってしまう。 特権ユーサー ID UNIX では、すべてのセキュリティ・チェックをくぐ り抜けられるスーパーユーサー (root) という仕組みか設 計にとりいれられており、これが多くの鮹夬困難な問題を もたらしている。 root はシステムの所有者なので、シス テムのシャットダウンなどの牛讚勧勺な操作を実行する場合 116 にも権限をあらためて証明する必要はない。 MVS にもセ キュリティに関する定義の設定、変更ができる特権ユー サーという機能があるが、 UNIX のような無制限の権限 をもっスーパーユーサーにある落し穴を避けるさまざまな 対策か講しられている。 MVS は、 UNIX の root のよ うに無制限の権限をもつシステム管理者やセキュリティ管 理者を想定していない。あらかしめ決められた管理者やそ れに類する竹喋をおこなう者は、管理上の限定された権限 しかもてない。監査言当求の整缶生を保つ規則はハードコー ドされており、誰も変更できない。ところが、 UNIX の root は自らのキ罸雀により、システムの監査言求をはしめ、 あらゆるものを削除、変更して不当な活動の亦を隠せる のである。 特権プロクラム UNIX では、 su コマンドや setuid を用いたプログラ ムにより、権限をもたないユーサーにあらかしめ決められ た特権的なアクセスを認める。所有者が root のプログラ ムをユーサーか実行するとき、そのユーサーは事実 - ヒ root として行重丿ける。 setuid によるプログラムは、もともとは キを行使する機能を個々のユーザーが使えるようにカプ セル化するためのものだったが、やかてセキュリティに破 綻をきたしかねない要因になった。クラッカーは、このよ うなプログラムにあるセキュリティ・ホールやバグを使っ たり、あるいは UNIX のほかの振舞いを利用してこれら のプログラムを操作し、不正なアクセスを実現する強力な 武器にすることができる。 MVS にも同様な操作ができる機能があり、通常のプ ログラムには認められていない特権的な機能を実行できる APF (Authorized Program FaciIity) というプログラ ムがある。しかし、これらのプログラムがいかなる牛罸雀を もっていても、標準のセキュリティ・チェックをすべて受 け、それ ( ン以しなけれはならない。 MVS は包キ甜勺な監 査機能によってこれらのプログラムの活動をトレースする とともに、プログラムか変更されないようにしている。つ まり、 MVS は特権プログラムの問題について実践的なア プローチをとっているのである。 UNIX と同様、 MVS にもセキュリティ上の問題はあ るが、一貫した方法で解決している。 UNIX は、 MVS の ガ去から何を学びとれるのだろうか。 UNIX MAGAZINE 1997.4

連載 / UN Ⅸ知恵袋ーの 図 21 下位ドメインの艮委譲 IN soft . f00. co ・」 p ・ ns . soft . f00. CO ・ jp. IN NS A ns . soft . f00. CO ・ JP ・ 133. 159.49.1 図 22 下位ドメインの引きの権限委譲 49.159.133. i Ⅱー addr. apra. IN NS Ⅱ s. soft . f00. co ・ JP ・ 図 23 セカンダリ・ネームサーパーの言聢ファイル directory cache S e C ondary S e C ondary pr lmary /var/named f00 ・ co ・」 p root . cache 133.159.10.1 backup/foo . zone 10.159.133. in—addr. arpa 133.159.10.1 backup/foo . rev 0.0.127. in-addr. arpa 10ca1host . rev 2 のガ去を用いる場合は、 ns. foo. co ・ jp の設定と同し手 順で soft. foo. co. jp のネームサーバーを用意します。た とえは・、 ns. S0仕 . f00. co. jp ( 133.159.49.1 ) というネーム サーバーを用意したとしましよう。そして ns. foo ・ co ・ jp から ns. soft. f00. co. jp へ、 so 仕 . f00. co. jp ドメインの権 限を委譲します。具イ勺には、図 21 の行を foo. zone に 付け加えることになります。 あとの設定は ns ・ foo ・ co ・ jp を設疋したときと同様です。 そして、忘れすに 159.133. in-addr. arpa. を管理するネ ームサーバーに逆引きの権限を委譲してもらいます。図 22 を 159.133. in-addr. arpa. のデータベース・ファイ ルに追加する必要があります。 セカンダリ・ネームサーバーの運用 ネームサーバーをより強固にするため、一ヨ勺には複数 のセカンダリ・ネームサーバーを用意します。セカンダリ・ ネームサーバーは簡単に実現できますから、計算機に余裕 があれはぜひ運用したいところです。図 23 にセカンダリ・ ネームサーバーの設疋ファイルを示します。 プライマリ・ネームサーバーの成疋ファイル ( 図 1 ) と 見くらべてください。 f00. co ・ jp と 10.159.133. ⅲ - addr . arpa の行が primary から secondary に変更されて います。ネームサーバーのデータベース・ファイル名の 代わりにプライマリ・ネームサーバーの IP アドレスを 指定し、その後ろにプライマリ・ネームサーバーから入 手したデータベース・ファイルをバックアップしておく ためのファイルの位置を指定します。 root. cache ファイ UNIX MAGAZINE 1997.4 ルと localhost. rev ファイルはプライマリ・ネームサー ーと同しものですから、セカンダリ・ネームサーバー の /var/named/ ディレクトリにコピーしておきます。 プライマリ・ネームサーバーカ種力いている状態で、セカ ンダリ・ネームサーノヾーを起動してみてください。正しく 設疋されていれは、 /var/named/backup/ ディレクトリ にプライマリ・ネームサーバーからコピーされてきたデー タベース・ファイルができているはすです。 ネームサーバーを利用する言 t は、 /etc/resolv. conf ファイノレの nameserver 行を〕旦加し、セカンダリ・ネーム サーバーのアドレスを指定しておきます。そうすれば、万 ープライマリ・ネームサーバーがダウンしていた場合も、 セカンダリ・ネームサーバーのバックアップ・データを利 用してネームサービスを利用することができます。 ☆ 今回は、ネームサーバーの立ち上げに必喫な設定を解説 しました。次回は、今回紹介できなかった資原レコードに ついて説明します。 ( しま・けいいちシャーフ ) 37

MVS のセキュリティ UNIX MAGAZINE 1997.4 加されても、 OS にはそれほどの負担にならない。 ら冗長なセキュリティ・チェックのためのプログラムが追 確かっ単しかも安全な能力を」助日できるので、あとか どには立ち入らない。この区別によって、 OS の機能に明 められた操作だけであり、ファイルシステムの内音財冓造な の権限、ファイルのセキュリティ関係のアクセス権、求 い。同様に、セキュリティ・システムが扱うのはユーサー 確認するようなセキュリティ対策に手を出してはならな るが、ファイルアクセスについて特定のユーサーの権限を OS はファイルに対して適切な入出力をおこなう必要はあ を区別し、そのギャップを埋める働きをする。たとえば、 SAF は OS の機能とセキュリティ・エンジンの機能 軟で多様な牛にもとづいて資源をイ描隻する。 工ンジンは、 ACL (Access ControI List) をイ尉寺し、柔 ティ・エンジンに渡す。これを受け取ったセキュリティ・ クセス方法といった必要な情報をすべて外部のセキュリ れているアクセスの種別 ( 読出し、更新、変更など ) 、ア めに応して、ユーザー ID やアクセス対象の資源、求めら これらを許可するか否かを決める際、 MVS は SAF の求 インできないといった措置か講じられている場合もある。 グインできる日計帯カ鴃まっている、または平日しかログ べースにアクセスできなかったり、あるいはシステムにロ れたアプリケーション・プログラムを使わなけれはデータ のアクセスが認められないことがある。たとえば、決めら ときには、一定の細かな条件を満たさなけれはユーサー を含むセキュリティ機能の才長が可能になる。 の糸財寺、信頼生の高い包括的監査言求の作成、特別な機能 ムでは、イベントか起きる前の制御、正確な報告システム ある集中的なセキュリティ管理が可能になる。このシステ に厳密になる。このようなアプローチ窈采用で、一貫性の り、セキュリティ・エンジンの判陸皀カか強化ささら ティ・エンジンに提供する。 MVS からの情報の取得によ る情報を SAF インターフェイスを通して外部のセキュリ し、 MVS は許可・不許可を決定するために必なあらゆ ログラムに委ね、自らは権限の付与にかかわらない。しか MVS は、すべてのセキュリティ許可の仕事を外部のプ UNIX & Security 2 ■ 制御と root 117 法によるファイルの一描は細かな部分しか対象にならない ID の入替えなどには適用されない。けっきよく、この方 されるのはファイルアクセスだけで、デーモンやユーサー 問題は依然として角夬されていない。また、 ACL か利用 テムの柔軟性は増すが、冗長性と一貫性のない管理という 用している。これによって、糸ムみのセキュリティ・シス ジョンの UNIX では、アクセス許可の処理に ACL を利 をコピーして実行される危険性がある。一部の新しいバー いでファイルの言囚みやコピーは可能なので、プログラム 実行できないようにすることはできる。しかし、設定しだ えは、ファイルの許可モードの設疋により、プログラムが 用を許す整合生のとれない状況に陥るおそれがある。たと 与えるイはみはない。さらに、 UNIX の去では、不正利 護モードや所有者の変更といった個々の操作ごとに権限を ば、もともとの UNIX には、生成や変更、ファイルの保 くっかの重要なセキュリティの要件を満たせない。たとえ ているので、このイは重要である。しかし、これではい 記述された設定ファイルによってセキュリティを実現し ある。はとんどの UNIX システムでは、単純な文字列で する読出し、書込み、実行の許可によるファイルの一で しい。その基盤になっているのは、 9 ビットの↑帯長で識別 UNIX のセキュリティは整合生に欠け、その管理は難 ポーネントから橢友されている。 リティ機能は、相圧の連携に欠け、不統一な数多くのコン の入力を要求する。このように、 UNIX におけるセキュ ほかのユーサーのユーザー ID を利用する前 0 ン以ワード 必要である。 setuid システムコールは、あるユーサーが コールでプログラムを終了させるには、 root ID の権限が とまったく同し許可権限をチェックする。 kill() システム の許可権限を調べる。 exec() システムコールは、 open() 叩 en ( ) は、 i ノードの 9 ピットて指定されているファイル とえば、ファイルへのアクセスを扱うシステムコールの れはシステムのほかの機能とは完全に独立している。た テムコールがセキュリティ・チェックをおこなうが、そ るようなセキュリティ上の仕組みはない。あらゆるシス の機能によって個別に実行される。認証をまとめて検査づー UNIX のセキュリティは分散しており、システムの個々

連載 /FreeBSD ノートー① チとともに則記の URL から入手できる。 以下では、 setlocale() がどのように実行されるか、ど のようにセキュリティ・ホールとなりうるか、といった点 について解説する。このセキュリティ・ホールを悪用すれ ば、最終的には一ヨ殳ューサーが root キ罸在を手に入れるこ とができる。実際に root キ罸雀を取得するにはかなりの技 術力が必要なので、 こで具イ勺な解見はしない。 今回セキュリティ・ホールがみつかったのは、 FreeBSD 上で動くすべてのプログラムに含まれている crt0 という ライプラリである。 crt0 の彳齬リをみるために、ます空のプ ログラム foo. c を C 言語で作成して、どのようにコンパ イルされるかを調べてみよう。 以下に示すのは、 2.1.5-RELEASE での実彳引列である。 ソースコードの場所は、 2.1.5-RELEASE の配布中のソ ースをすべて展開した場合を想定している。 コンパイルの仕組み コンパイルの具イ勺な内容は、 cc (FreeBSD の場合は、 cc で GNU のコンパイラ gcc か呼び出される ) にオプショ gcc version 2.6.3 miffy% cc —v f00. c main() miffy% cat f00. c ン—v を指定することによって分かる。 ar/tmp/cc0141501.0 /usr/lib/libgcc. a —lc /usr/li /usr/bin/ld —e start —dc —dp /usr/1ib/crtO.0 /v 014150. s /usr/bin/as ー 0 /var/tmp/cc0141501.0 /var/tmp/cc by GNU C version 2.6.3. GNU C version 2.6.3 ( 80386 , BSD syntax) compiled mpbase f00. c —version ー 0 /var/tmp/cc014150. s /usr/libexec/ccl /var/tmp/cc014150. i —quiet —du End of search list . /usr/include . > search starts here : #include く . search starts here : #include " GNU CPP version 2.6.3 ( 80386 , BSD syntax) ( i386 ) —Amachine(i386) f00. c /var/tmp/cc014150. i ー D ーー i386 —Asystem(unix) —Asystem(FreeBSD) —Acpu —D__FreeBSD__=2 —D__unix ー D ーー i386 ー 2 —D__unix_ —D__GNUC_MINOR__=6 —Dunix ー Di386 —D__FreeBSD /usr/libexec/cpp —lang—c —v —undef —D——GNUC——=2 2. C 言語からアセンプリ言言の変換 3. アセンプリ言語からオプジェクト・ファイルへの変換 4. オプジェクト・ファイル ( ーイ殳には複数 ) をリンクして 実行形式に変換 という流オ功、らなり、それぞオし cpp 、 ccl 、、 ld という 下請けプログラムにより実行される。 cc の彳難リはオプショ ンを判別してこれらのプログラムを適切に呼び出すことで ある。ファイルの受渡しにはディレクトリ /var/tmp/ 以 下の中間ファイルカ吏われていることが分かる。 cc のオプションとして—pipe を指定すると、最初の 3 つ の過程で中間ファイルの代わ引ンヾイプを使って受渡しができ る。こちらのはうがメモリをよけいに消費するが、ファイルへ のアクセスかる。したがって、メモリが - ト分にあればコンパ イルが速くなる。 この空のプログラム foo. c にはインクルード・ファイル やマクロがないため、 cpp は素通りする。次のステップで どのようなアセンプリ言語に変換されているかをみてみよ う。 cc で -S オプションを指定すると、 . s て終るファイ ルにアセンプリ言語に変換して出力する。 miffy% cc —S f00. c miffy% cat f00. s . file gcc2—compi1ed. " f00. C " ・ align 2 —gnu—compiled—c : . text . g10b1 _mam : LI : Lfe1: ma111 ・ type _main, @function pushl %ebp movl %esp , %ebp call _maxn leave ret . SIZe main, LfeI—_main b/libgcc . a コンノヾイルは、 102 1. インクルード・ファイルの言囚み、 マクロの鮹夬 関数 main() のエントリが -main というラベルにな っているのが分かる。このように、 C 言語の識別子の頭 ー " を付けたものがアセンプリ言語のレベルでの識別子 UNIX MAGAZINE 1997.4 という関数を呼び出して戻るだけである。 ムの本体である。けっきよく、 main() の中身は --main( になる。ラベルー main から ret 命令までカゞ、このプログラ

連載 /FreeBSD ノートー リスト 1 簡略化した start() start() struct kframe { int char char char kargc ; *kargv [ 1 ] ; kargstr [ 1 ] ; kenvstr [ 1 ] ; / * size depends on kargc * / / * Size varies * / ALL REGI STER VARIABLES ! ! ! if (argv [ 0 ] ) environ = targv; —targv; if (targv > = (char * * ) (*argv) ) / * void * / for (argv = targv = &kfp—>kargv [ 0 ] , register Char **argv ; register char **targv ・ register struct kframe *kfp ; *targv 十十 ; if ( (——progname —strrchr(argv [ 0 ] , = argv [ 0 ] ; —progna-me 十十 __progname ; if (getenv ( "ENABLE—STARTUP_LOCALE" ) ! = NULL) —startup—setIocaIe(LC—ALL, exit (main(kfp—>kargc , argv , environ) ) ; -LOCALE に定義されているデフォルトの値 (/usr/ share/locale) カイ吏われる。 そしてリスト 3 のように、下請けの関数 startup- setrunelocale() 中で name というノヾッフアに内容をコ ピーしている。 セキュリティ・ホールの正体 こで問題になるのが、バッファ name の長さであ る。 name の長さ PATH- MAX は /usr/include/sys /syslimits. h で定義され、 1024 となっている。一方、 環境変数を設定する関数 setenv() (/usr/src/lib/libc/ stdlib/setenv. c のなかで定義されている ) を見ると分か るように、どんなに長い文字列でも ( イ瓦想メモリカ戦って いれは ) 環竟変数に設疋できるようになっている。 もし、竟変数 PATH-LOCALE の長さが 1 , 024 を 超えている場合には、 strcpy() によってバッファⅡ ame の 104 具イ勺には、悪意をもったユーサーか不正に root やそ グラムについても同様である。 あるいは setgid されたプログラムから呼び出されるプロ 不正ロ限を入手することが可能になる。これは、 setuid 数 PATH-LOCALE に特殊な文字列を設定して実行し、 め、このようなプログラムか第踵カ作するように、故意に変 るユーサーの権限ではなく別の権限で実行される。そのた は間題がさらに大きい。こういったプログラムは、実行す しかし、 setuid や setgid されているプログラムの場合 な景グが出ることはなさそうである。 やデータカ皸壊されることはあってもシステム自体凵リ 響がおよぶことはない。したがって、ユーザーのファイル アクセス制御により、実行したユーサーの権限を越えて影 設罰 j 作がおこりうる。通常のプログラムならば UNIX の タか破壊されてプログラムが正常に実行されなかったり、 長さを超えてコピーがおこなわれてしまう。すると、デー UNIX MAGAZINE 1997.4

DAEM 〇 NS & DRAG 〇 NS の Aut0CIient の導入 UNIX MAGAZINE 1997.4 年 3 月号 ) を参照してはしい。 1 調主 : 本連載の「キャッシュ・ファイルシステムの利去」 ( 1997 ファイルシステムは、 NFS あるいは ( アクセスのはとん ション (/ と /usr) がキャッシュされる。はかのすべての 域として使われる。キャッシュ領域には OS のパーティ する。ローカルディスクはスワップおよびキャッシュ領 クレス・クライアントと同しメカニズムを用いてプート ータの入っていないディスクをローカルにもち、ディス ファイルシステム (cachefs) を利用する。システムはデ AutoClient システムは、前回 1 紹介したキャッシュ・ AutoClient の概要 る管理の容易さを兼ね備えている。 システムの処理速度と、ファイルシステムの集中化によ レス・ワークステーションである。スタンドアローン・ Sun が開発した AutoCIient は、次世代のディスク うになった。 NFS サーバーに置くというシステム設定をおこなうよ をローカルなディスクに置き、データは従来のように く、より安価になってきた。これにより、管理者は OS ワークの速度が停滞気味なのに対し、ディスクはより速 ムファイルを取得するために NFS が使われた。ネット ス・クライアントの次の実装では、サーバーからシステ ロード可能なファイルシステムが含まれる。ディスクレ TFTP によってディスクレス・クライアントへダウン イスクを利用していた。ネットワーク・ディスクには、 の実装では、サーバーがもっているネットワーク・デ Sun ワークステーションがごく一般的であった。最初 10 年ほど前はディスクレスの 前回述べたように EDinah McNutt 、 Peter Galvin from UNIX REVIEW どか読出しの場合は ) cachefs によってマウントされる。 ローカルにスワップ領域をもっことにより、サーバーの 負荷を軽減し、ディスクレス・クライアント全体のパフ ォーマンスを向上させる。これに加え、 cachefs によって さらにパフォーマンスか高められる。前回の記事を読ん でいない方のために付け加えておくと、 cachefs は NFS クライアントにローカルなキャッシュ領域をもたせるこ とで、読出しのみ、あるいははとんどか第売出しのファイ ルシステムに対する NFS によるアクセス性能を改善で きる。 AutoClient は、ローカルなデータをもたない FRU2 として最適である。システムか動かなくなったときはハ ードウェアを取り替えてすぐにプートできるので、新た なハードウェアを入手するだけでよく、修復に要する時 の封象となる AutoCIient のクライアント ( 以ード、 略 ) には AutoClient のプログラムのほかに、サポート AutoCIient サーバー ( 以下、たんに、、サーバー AutoClient サーバーの作成 間を短縮できる。 2 訳注 : FRU は field-replaceable unit の略で、交換部品を意味す ーは、 Solaris 2.4 または 2.5 でなければなら を用意する必要がある。 トに対しては、 /export/root に 20MB のディスク空間 /export に 17MB の容量が必要である。各クライアン は、ルート・ファイルシステムに IMB 、 /usr に 4MB 、 意しなければならない。 AutoCIient 自体を置くために ライアント " と略 ) のためのディスク領域をそれぞれ用 る。 59