Google グループは Usenet の新規の投稿と購読のサポートを終了しました。過去のコンテンツは引き続き閲覧できます。
表示しない

Is it a bad idea to start Apache with SSL by non-root?

閲覧: 1 回
最初の未読メッセージにスキップ

Yasushi Shinjo

未読、
2004/01/27 1:33:062004/01/27
To:
新城@筑波大学情報です。こんにちは。

Linux に特化した話ではないので、fj.comp.security にふります。

In article <bv0i43$bmb$1...@news511.nifty.com>
名称不定 <dev_...@anet.ne.jp> writes:
> Apache 2 + mod_ssl について相談です。
> iptables を使ってポート80をポート8000へリダイレクト
> することで、 Apache を最初から httpd ユーザ権限で
> 開始させることはできます。

面白いですね。そういう方法があったんですね。

> しかし、最初から root を使わないので Apache が
> クラックされたとしても root 権限を奪われることは無いと
> 思うのですが、その代償として httpd ユーザ権限を
> 奪われるだけでサーバ証明書ファイル等を読まれてしまいます。
>
> mod_ssl を使う場合はやっぱり root で開始させるべき
> なのでしょうか?

まだ root 権限奪われるよりは被害が少ないから、ある特定の権限
で動かした方がいいんじゃないですか。

> httpd.conf の中で root で開始された場合に子プロセスを
> 一般ユーザ権限で動作させる指定ができるのでその指定を
> 使うべきでしょうか? root で開始した場合、子プロセスが
> クラックされた際に何らかの方法で root 権限で動作している
> 親プロセスまでクラックされてしまうのではないかと心配です。

Apache を普通に動作させると、root のものが1つと後は特定の一
般ユーザ(たとえば nobody とか www とか apache とか)で動きま
すよね。root のものは、たぶん、ネットワークからのデータを
read() しないようく作ってあると思います(私ならそうする)。
そういう意味では、安全なのでしょう。あと問題は、プロセス間共
有メモリを見るかですが、どうなっているのでしょうか?

> 一度、 server.key を FIFO にして動作するかどうか
> 試したのですが、 mod_ssl が「ファイルサイズが 0 である」
> というエラーを発生させてしまうのでうまくいきませんでした。
> 開始スクリプトで root が鍵ファイルの内容を FIFO に書き込んで
> httpd ユーザ権限で開始した Apache がその FIFO から読み出す
> (1回しか読めないのでクラックされても証明書ファイル等を
> 読み出せなくする)というのが狙いだったのですが・・・。

サーバのメモリ中には証明書があるんですよね。ファイルだけ守っ
てもしょうがないということはないですか。

\\ 新城 靖 (しんじょう やすし) \\
\\ 筑波大学 電子・情報       \\

名称不定

未読、
2004/01/27 10:11:322004/01/27
To:
こんにちは、新城@筑波大学情報さん。

Yasushi Shinjo wrote:
>>mod_ssl を使う場合はやっぱり root で開始させるべき
>>なのでしょうか?
>
> まだ root 権限奪われるよりは被害が少ないから、ある特定の権限
> で動かした方がいいんじゃないですか。

なるほど。

横道に逸れますが、現在、システムやWebコンテンツ等の
改竄を防ぐことを目的として CD-ROM で動作する Linux を開発しています
(そのデモ内容として Apache + SSL を使っているわけです)が、
root 権限を奪われてもバックドアとかの設置は不可能だと考えています
(実際にインターネット上に晒してクラック耐久実験をしたわけでは
ありませんが)。

でも、ハードディスクで運用する普通のシステムでの参考にしたいので、
「root 権限を奪われたらどんな被害が生じるか判らない」という仮定で、
Apache with mod_ssl を root で開始することの是非について
もっと他の方々からも意見を伺いたいです。


> すよね。root のものは、たぶん、ネットワークからのデータを
> read() しないようく作ってあると思います(私ならそうする)。
> そういう意味では、安全なのでしょう。あと問題は、プロセス間共
> 有メモリを見るかですが、どうなっているのでしょうか?

はい。でも、ソースコードが複雑すぎて、どこが main() かさえ
見つけられませんでした。 (^^;;
最初のプロセスが特権ポートに bind() + listen() + accept() をして、
そのファイルディスクリプタを子プロセスに渡すようにすることで
最初のプロセスは read() をしないようになっているのかなぁ。


> サーバのメモリ中には証明書があるんですよね。ファイルだけ守っ
> てもしょうがないということはないですか。

そうですね。確かに、コアダンプを作られてそれを読まれてしまえば
それまでですよねぇ。すると、証明書ファイルを隠しても
あまり意味無いのかもなぁ。

ちゃんとログを残して、クラックされたことが判明したら即刻
証明書ファイルを更新するというのが必要なのかも。
(ちなみに、 Apache のログファイルを FIFO にしても動きます。
クラックされてログを削除しようとしても、既にそこにはログが
残っていないという妙な裏技です。)


引き続き、よろしくお願いします。

Yasushi Shinjo

未読、
2004/01/28 12:24:352004/01/28
To:
新城@筑波大学情報です。こんにちは。

In article <bv5v2t$jml$1...@news511.nifty.com>


名称不定 <dev_...@anet.ne.jp> writes:
> 横道に逸れますが、現在、システムやWebコンテンツ等の
> 改竄を防ぐことを目的として CD-ROM で動作する Linux を開発しています

そんなあなたに世界OS。SFのパラレルワールドを実現したよう
なOSです。コピー・オン・ライト的に子世界を作って、ファイル
が書き換えられたも、その世界を消してしまえば、一発で元にもど
ります。

http://www.ipsj.or.jp/members/Journal/Jpn/4306/article014.html

> (そのデモ内容として Apache + SSL を使っているわけです)が、
> root 権限を奪われてもバックドアとかの設置は不可能だと考えています

「バックドアの設置が不可能」というよりは、「リブートすれば、
仕掛けられていても回復できる」ということでしょう。

root 権限でリブートできないよううに意地悪したりして。あと、
昔ながらの NVRAM に潜り込んだり。

> はい。でも、ソースコードが複雑すぎて、どこが main() かさえ
> 見つけられませんでした。 (^^;;
> 最初のプロセスが特権ポートに bind() + listen() + accept() をして、
> そのファイルディスクリプタを子プロセスに渡すようにすることで
> 最初のプロセスは read() をしないようになっているのかなぁ。

root 権限がいるのは、bind() だけです。listen() は一発やって
終り。accept() は、root でない方のプロセスでやっているんじゃ
ないかな。

Apache だと Pthread を使うものあるのですが、この辺りどうなん
でしょうね。

> > サーバのメモリ中には証明書があるんですよね。ファイルだけ守っ
> > てもしょうがないということはないですか。
>
> そうですね。確かに、コアダンプを作られてそれを読まれてしまえば
> それまでですよねぇ。

直接メモリを見に行ってもいいんじゃないですか。

> ちゃんとログを残して、クラックされたことが判明したら即刻
> 証明書ファイルを更新するというのが必要なのかも。

証明書再発行でもお金かかるので、負けかも。
GeoTrust でも3万4800円。VeriSigh やめたのはすっきりしました。
DNS のあの使い方は、許せない。

> (ちなみに、 Apache のログファイルを FIFO にしても動きます。
> クラックされてログを削除しようとしても、既にそこにはログが
> 残っていないという妙な裏技です。)

なるほど。問題は、ログに残るかどうかと、クラックされたことを
判定すことかな。

dependable で最後に問題になるのは、壊れたかどうかの判定なん
ですよね。世界OSでも、それは分からないです。

KATOH Yasufumi

未読、
2004/01/29 2:55:212004/01/29
To:
加藤泰文です.

>>> On Wed, 28 Jan 2004 00:11:32 +0900
in message "Re: Is it a bad idea to start Apache with SSL by non-root?"
名称不定(dev_...@anet.ne.jp)-san wrote:

> そうですね。確かに、コアダンプを作られてそれを読まれてしまえば
> それまでですよねぇ。すると、証明書ファイルを隠しても
> あまり意味無いのかもなぁ。

細かいハナシですが,「証明書ファイル」は隠しても意味ないですよね.その
サーバにブラウザで SSLで接続すれば送られてきますし.

隠すのは秘密鍵.証明書ファイルは秘密鍵とペアで置き換えられないように注
意すれば良いのではないですか? 秘密鍵は…,パスフレーズを知られないよう
にすれば良いのではないかなぁ.

秘密鍵盗まれたら,置き換え必要でしょうけどね.

あれ? ボケてます,私? (^_^;)

--
==============================================
(((( 加藤泰文 karma @ prog.club.ne.jp
○-○ http://www.ae.wakwak.com/%7Ekarma/
==============================================
(仮称)新 fj.* の歩き方の作成完了部分の公開
http://www2s.biglobe.ne.jp/~kyashiki/fj/arukikata/

名称不定

未読、
2004/01/29 7:54:222004/01/29
To:
こんにちは、加藤泰文さん。

KATOH Yasufumi wrote:
> 細かいハナシですが,「証明書ファイル」は隠しても意味ないですよね.その
> サーバにブラウザで SSLで接続すれば送られてきますし.
>
> 隠すのは秘密鍵.証明書ファイルは秘密鍵とペアで置き換えられないように注
> 意すれば良いのではないですか? 秘密鍵は…,パスフレーズを知られないよう
> にすれば良いのではないかなぁ.
>
> 秘密鍵盗まれたら,置き換え必要でしょうけどね.
>
> あれ? ボケてます,私? (^_^;)
>

あ~、ボケてるのは私です。証明書ファイルと秘密鍵ファイルの区別が
付いていませんでした。隠すべきは server.key じゃないとすると、
どのファイルなのかなぁ?(^o^;

RH9 をインストールしても、初回起動時に勝手にパスフレーズ無しの鍵を
作ってしまうようなので、インストールしたっきりパスフレーズは設定
していません。(設定したらリモートから再起動した時に Apache を
自動的に開始させることが出来なくなってしまいますよね? ssh で
入って手動で起動させてやれば良いだけの話かもしれませんが。)

すると、何らかの方法で秘密鍵ファイルを読まれるのは止むを得ないとして、
それをパスフレーズで守るというのが最終的な防御策ということでしょうか。
だとすれば、一般ユーザ権限で読まれてしまう設定(=非rootで開始)も
実運用上ありそうですね。

ありがとうございます。

KATOH Yasufumi

未読、
2004/01/29 10:58:572004/01/29
To:
加藤泰文です.

>>> On Thu, 29 Jan 2004 21:54:22 +0900


in message "Re: Is it a bad idea to start Apache with SSL by non-root?"

名称不定-san wrote:

> あ~、ボケてるのは私です。証明書ファイルと秘密鍵ファイルの区別が
> 付いていませんでした。隠すべきは server.key じゃないとすると、
> どのファイルなのかなぁ?(^o^;

ファイル名はなんとでも付けられるのでアレですが,server.key という名前
からするとそれが秘密鍵です.というか設定で SSLCertificateKeyFileで指定
されているのが隠すべきファイルで,SSLCertificateFileは公開鍵証明書です
から隠す必要なしです.

> RH9 をインストールしても、初回起動時に勝手にパスフレーズ無しの鍵を
> 作ってしまうようなので、インストールしたっきりパスフレーズは設定
> していません。(設定したらリモートから再起動した時に Apache を
> 自動的に開始させることが出来なくなってしまいますよね? ssh で
> 入って手動で起動させてやれば良いだけの話かもしれませんが。)

SSLPassPhraseDialog で例えば
echo passphrase
なんてシェルスクリプトにしておけばパスフレーズありでも OK ですが,そう
すると今度はこのパスフレーズを書いたファイルを隠して... って必要があり
ますね.

> すると、何らかの方法で秘密鍵ファイルを読まれるのは止むを得ないとして、
> それをパスフレーズで守るというのが最終的な防御策ということでしょうか。

うーん,どうかなあ.今のところそんな気がするけど,違う解決策もありそう
な気もするなあ.この辺りは識者にまかせましょう.(^_^;)

> だとすれば、一般ユーザ権限で読まれてしまう設定(=非rootで開始)も
> 実運用上ありそうですね。

そうですね.普通は root しか読めないようにしておきますものね (秘密鍵).

--
karma @ prog.club.ne.jp / 加藤泰文

Yasushi Shinjo

未読、
2004/01/31 3:07:382004/01/31
To:
新城@筑波大学情報です。こんにちは。

In article <bvbak7$2oge$1...@news1.wakwak.com>


KATOH Yasufumi <ka...@prog.club.ne.jp> writes:
> ファイル名はなんとでも付けられるのでアレですが,server.key という名前
> からするとそれが秘密鍵です.というか設定で SSLCertificateKeyFileで指定
> されているのが隠すべきファイルで,SSLCertificateFileは公開鍵証明書です
> から隠す必要なしです.

そうですね。文脈としては、隠すべきものをどうするかという話な
ので、だいたい通じていたとは思います。

> そうですね.普通は root しか読めないようにしておきますものね (秘密鍵).

それを一般ユーザの権限(たとえば www )で読めるようにしたとす
ると、今度は、一般ユーザが cgi か何かで読み出しちゃうと。
suExec 使うと、この辺りは何とかなるんでしょう。

CGI でなくて ln -s でもいいかもしれないけれど。

秘密鍵を暗号化して置いておくと、今度は起動時に暗号を解くため
のパスワードを要求してくるから、運用上面倒です。

CGI はいいとして、PHP とか mod_perl とか怖い感じがしますが、
どうなんでしょうか。

KATOH Yasufumi

未読、
2004/02/03 3:16:172004/02/03
To:
加藤泰文です.

>>> On 31 Jan 2004 08:07:38 GMT


in message "Re: Is it a bad idea to start Apache with SSL by non-root?"

Yasushi Shinjo(y...@is.tsukuba.ac.jp)-san wrote:

> suExec 使うと、この辺りは何とかなるんでしょう。

なるほど.でもなんでもかんでも CGI で動かさないとダメってのは非常に面
倒ですね.静的なページを作るにもスクリプトにしなければいけない? (^^;)

> CGI はいいとして、PHP とか mod_perl とか怖い感じがしますが、
> どうなんでしょうか。

ちなみに CGI 版の PHP ってのもありですね.:-)

元の質問とは回答ずれているかも知れませんが,Trusted OS 使ったらどうに
かならんのかな? あまり考えずに言っているので,ボケている可能性大.

Yasushi Shinjo

未読、
2004/02/13 14:32:232004/02/13
To:
新城@筑波大学情報です。こんにちは。

In article <sa6smhspoha.wl%ka...@prog.club.ne.jp>
KATOH Yasufumi <ka...@prog.club.ne.jp> writes:
> 加藤泰文です.


> > suExec 使うと、この辺りは何とかなるんでしょう。
> なるほど.でもなんでもかんでも CGI で動かさないとダメってのは非常に面
> 倒ですね.静的なページを作るにもスクリプトにしなければいけない? (^^;)

たしかに。

> ちなみに CGI 版の PHP ってのもありですね.:-)

そうなんですか。どこにあるのですか。

suExec があれば、 Squirrel Mail みたいな WWW Mail を IMAP な
しで作れるんじゃないかと思いました。SSL は前提ですけれど。

> 元の質問とは回答ずれているかも知れませんが,Trusted OS 使ったらどうに
> かならんのかな? あまり考えずに言っているので,ボケている可能性大.

Trusted OS とは何なんでしょうね。

Secure だと DoD の規格に合格したものでTrusted だともう少しい
い加減みたない話をどこかで見た気もしますが。日経Linuxだった
かなあ。

たとえば、SysGuard が入った OS は、Trusted? Secure?
Dependable?

http://www.ipsj.or.jp/members/Journal/Jpn/4306/article013.html

名称不定

未読、
2004/02/14 6:40:132004/02/14
To:

Yasushi Shinjo wrote:
> Trusted OS とは何なんでしょうね。
>
> Secure だと DoD の規格に合格したものでTrusted だともう少しい
> い加減みたない話をどこかで見た気もしますが。日経Linuxだった
> かなあ。
ほぇ?
セキュリティ強化OSの内、どっかの認証を受けたものが
Trusted OS と呼ばれると思ってたけど・・・。(^^;;

> たとえば、SysGuard が入った OS は、Trusted? Secure?
> Dependable?

セキュリティ強化OSで良いのでは?

Yasushi Shinjo

未読、
2004/02/15 5:42:582004/02/15
To:
新城@筑波大学情報です。こんにちは。

In article <c0l1em$4g7$1...@news511.nifty.com>


名称不定 <dev_...@anet.ne.jp> writes:
> > Secure だと DoD の規格に合格したものでTrusted だともう少しい
> > い加減みたない話をどこかで見た気もしますが。日経Linuxだった
> > かなあ。
> ほぇ?
> セキュリティ強化OSの内、どっかの認証を受けたものが
> Trusted OS と呼ばれると思ってたけど・・・。(^^;;

なー。

MAC (Mandatory Access Control) が入ったのが Trusted OS だっ
たかな。MAC というのは、一般ユーザじゃなくて管理者ががガリガ
リとアクセス制御をかけられるという意味です。その反対が DAC
(discretionary Access Control)。chmod みたいに個人が変えられ
るのは、DAC。BSD に MAC を入れると Trusted BSD。

http://www.trustedbsd.org/docs.html

> > たとえば、SysGuard が入った OS は、Trusted? Secure?
> > Dependable?
> セキュリティ強化OSで良いのでは?

SysGuard は、MAC を実現するにも使えないことはないなあ。

MAC 入ったから偉いというのも、何だかなあという来もするけれど。
MAC は、軍隊で自分の所の兵隊も信じないというモデルを作るとい
うのに似たような話ですよね。

一般ユーザがトロイの木馬を実行しても、管理者の MAC で情報の
流出を止められるという話があるのかもしれないけれど、でも、普
通の WWW ブラウザでの WWW サーフィンとトロイの木馬による
HTTP での情報発信と区別できるようなMAC のルールが書くのは大
変そう。

KATOH Yasufumi

未読、
2004/02/17 21:45:492004/02/17
To:
加藤泰文です.

>>> On 13 Feb 2004 19:32:23 GMT
in message "Protecting CGI and modules with Secure/Trusted OS"
Yasushi Shinjo(y...@is.tsukuba.ac.jp)-san wrote:

> > ちなみに CGI 版の PHP ってのもありですね.:-)
> そうなんですか。どこにあるのですか。

普通の PHP のソースパッケージを取ってきて,configure でオプション指定
すれば出来ます.

以前は普通に(?)構築したらモジュール版と CGI 版が出来てましたが,最近の
だとモジュール版とコマンドライン版が出来上がります.

新着メール 0 件