Jump to content 日本-日本語
日本HPホーム 製品とサービス サポートとドライバ ソリューション ご購入方法
≫  お問い合わせ
日本HPホーム
製品とサービス  >  ソフトウェアとOS  >  HP- UX Developer Edge

「だれもがroot」を解消するSecurity Containment・後編
HP-UX 11i v3 Update 3 ミッションクリティカル環境での仮想化機能を強化
UNIXの教科書 応用編 2日目：ファイルの検索
HAクラスタの教科書 第2日目：ネットワークを設定する
特集：第4世代の仮想化ソフトウェアIntegrity VM4.0の魅力を徹底解剖
コンテンツに進む
「だれもがroot」を解消するSecurity Containment・後編

Security ContainmentのRBACにより、root権限の一部を一般ユーザに付与し、rootの利用を最小限にとどめられる。とはいえUNIXでは、たとえrootユーザとしてログインしていなくても、自覚のないままroot権限を行使しているケースが実は数多くある。それは、“setuidされたコマンド”の実行時である。

Fine-grained Privilegeは、root権限をおよそ40種類に細分化し、個々のプロセスに付与することでsetuid問題を解決する。これらの新機能をシステム提案にうまく取り入れれば、ITのセキュリティに対して広まりつつある不安も、SIerにとってはむしろ追い風となるはずだ。
「だれもがroot」を解消するSecurity Containment・後編
≫ setuid問題を解決するFGP
≫ コンパートメント＋リソース管理＝SRP
2005年7月
テクニカルライター　 吉川和巳

setuid問題を解決するFGP
前編で説明したRBACを利用すれば、rootの管理権限の一部を必要に応じて一般ユーザに付与し、rootの利用を最小限にとどめることができる。とはいえUNIXでは、たとえrootユーザとしてログインしていなくても、自覚のないままroot権限を行使しているケースが実は数多くある。それは、setuid(suid)ビットが設定されたコマンドを実行したときだ。

例えば、一般ユーザがpasswdコマンドを実行し、自分のアカウントのパスワードを変更する場合を考えてみよう。新たに入力されたパスワードは、/etc/passwdファイルに保存される。しかし同ファイルは、当然のことながらrootユーザでなければ書き込みできないパーミッション設定になっており、本来ならば一般ユーザが起動したコマンドからは内容を変更できない。

UNIXでは、このジレンマを解く手段として、ファイル・パーミッションのsetuidビットを用いている。例えば、HP-UXのpasswdコマンドのパーミッションを確認してみよう。

　 # ls -l /usr/bin/passwd

-r-sr-xr-x 5 root bin 107240 Aug 27 2004 /usr/bin/passwd		 　

ここで、パーミッションを表す左端の文字列にて「s」と記されている部分が、setuidビットの状態を示している。このように“setuidされたコマンド”を一般ユーザが起動すると、そのコマンド・ファイルの所有者(上記例ではroot)に成り変わってコマンドを実行できる。そのため、一般ユーザでも/etc/passwdなどのファイルを変更可能になる。もうすこし正確に言えば、起動したpasswdプロセスのeuid(実効uid)として0(root)がセットされるため、ファイル・オープンなどのシステム・コール呼び出し時にroot権限を行使できる仕組みだ(図1)。
　
setuidによるroot権限の付与
図1：setuidによるroot権限の付与
  UNIXではこのsetuidのメカニズムが随所で利用されており、例えばHP-UXでもlogin、df、netstat、rcp、rlogin、shutdown、ping、tracerouteをはじめ、無数のコマンドがsetuidされている。その多くが、パーミッション保護されたファイルへのアクセスや、低レベルのネットワークAPIや特権ポートへのアクセスなど、システム・コール時にroot権限を必要とするコマンドである。このように、OSの水面下でも「だれもがroot」のセキュリティ・リスクが存在するのが実情だ。万が一、setuidされたコマンドにバッファオーバーフローなどのセキュリティ・ホールが存在すると、一般ユーザになりすましたクラッカーがroot権限を獲得する手段として悪用されてしまう。

Security Containmentの3つめの機能、Fine-grained Privilege(FGP)は、この課題の解決を目的としたものだ。簡単にいえば、RBACがroot権限の一部を「一般ユーザ」に付与するのに対し、FGPは「プロセス」に付与する。具体的には、およそ40種類に細分化された権限をプロセスに与えることができる。以下の表は、その権限の一部を抜粋したものである。

＜表：FGPで利用できるおもな権限(抜粋)＞
名前 権限
PRIV_CHOWN ファイルの所有者の変更
PRIV_NETADMIN ネットワーク管理機能の利用
PRIV_NETPRIVPORT ネットワークの特権ポート(0〜1023番)の利用
PRIV_NETRAWACCESS IPパケットの直接利用
PRIV_REBOOT システムのリブート
PRIV_SYSATTR ホスト名やドメイン名、クオータなどのシステム設定値の変更
PRIV_SYSNFS NFSサービスの利用

では、実際のプロセスへの権限付与を見てみよう。ここでは、setuidビットを使用しない「safe_ping」という新しいコマンドの導入を想定する。従来のpingコマンドでは、相手ホストにIPパケットを送るために、root権限によるシステム・コールを必要としていた。そこでsafe_pingコマンドでは、root権限の代わりにPRIV_NETRAWACCESS権限を用いることにする。そのためには、以下のsetfilexsecコマンドを実行する。

　 # setfilexsec -c safe_ping -p NETRAWACCESS -P NETRAWACCESS ./safe_ping 　

ここで、「-c safe_ping」とある部分では、コンパートメントsafe_pingの内部でプロセスを起動することを意味する。また-pおよび-Pオプションは、プロセスに付与する最小権限と最大権限を表す。最後の「./safe_ping」部分が、対象となるプロセスの実行可能ファイル名である。

このようにFGPでは、プロセスに与える権限を「最小」から「最大」まで幅を持たせることができる。FGPが提供するAPIを用いると、必要なときに必要な特権だけを付与するようなアプリケーションをコーディングできる。特権が必要な場合以外は最小限の権限だけを使用するようにコーディングしておけば、万が一プロセスが不正利用されたとしても、その被害を小さい範囲に食い止められる。

以上のようなFGPの設定により、safe_pingプロセスによるシステム・コール呼び出し時にPRIV_NETRAWACCESS権限の存在がチェックされ、pingパケットの送出が許可される。こうして、setuidビットを使わずともroot権限の一部をプロセスへ委譲できるメカニズムである(図2)。
 
FGPによる細分化された権限の付与
図2：FGPによる細分化された権限の付与
トップへ 　 次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。
印刷用画面へ
プライバシー 本サイト利用時の合意事項 ウェブマスターに連絡
© 2008 Hewlett-Packard Development Company, L.P.