Webサーバーが伝統的にスーパーユーザーとして起動するのはなぜですか？

POSIXにはCAP_NET_BIND_SERVICEを含む機能標準がありますが、これは役に立ちません。一貫性そしてある意味ではそうかもしれません互換性がないLinuxなどのプラットフォームで実装されています。

ApacheなどのWebサーバーは単一のプラットフォーム用に作成されていないため、root権限を使用することが最も移植性の高い方法です。私はこれがLinuxとBSD（またはサポートが検出された場所）で特に実行できると思いますが、これは動作がプラットフォームなどによって異なる可能性があることを意味します。

私の考えでは、すべてのWebサーバーがこのように使用できるようにシステムを構成できるようです。以下は、このWRT Apacheに関するいくつかの（おそらく不器用な）提案です。ルート以外のポートバインディング。

それから彼らはなぜ伝統的に後で暗黙のセキュリティ問題を排除するためにすべてのタスクが完了したら、rootで起動しますか？

通常、特権ポートへのアクセスが必要なので、ルートで始まります。伝統的にこれが唯一の方法です。後でダウングレードする理由は、権限を必要とせず、サーバーで一般的に使用される多数のサードパーティのアドインによる潜在的なダメージを制限するためです。

特権アクティビティは非常に制限されており、慣例によって他のinetデーモン（たとえばsshd）を含む他の多くのシステムデーモンがルートとして実行され続けるため、これは無理ではありません。

CAP_NET_BIND_SERVICEを使用して権限のないユーザーとして実行できるようにサーバーをパッケージ化した場合どのHTTP（S）サービスを開始する権限がないユーザーは、より大きなリスクを引き起こす可能性があります。

Unixベースのシステムで特権ポートをリッスンするサービスには、システム管理者権限が必要です。これは、信頼できる（少なくとも管理者）ユーザーがサービスを実行していることを示します。これらのサービスのユーザーは、サーバーアプリケーションの管理者の一部があることを信頼できます。この信頼の価値は、過去数十年間ほど大きくはないかもしれません。

多くのWebサーバーは、権限のないユーザーとして起動して実行するために必要な機能をサポートしていない古いオペレーティングシステムカーネルで実行されます。必要なカーネルの変更は比較的新しいものであり、オペレーティングシステムのカーネル全体で標準化されていません。このような環境では、ソフトウェアを条件付きでコンパイルできます。ただし、これらの変更はほとんどのプラットフォームでは機能しないため、完全にテストされていないか、予想どおりに安全ではない可能性があります。

デーモンは通常、root アクセスを必要とするすべての操作を実行するために root として実行され、次に権限のない UID に切り替えます。これにより、プログラムの実行後にあまりにも多くのダメージを与えないようにしながらリソースを保護できます。 Webサーバーの場合、悪意のあるサーバーアプリケーションがSSLキーを読み取ることを保護する必要がありますが、SSLリスナーを構成するにはSSLキーを読み取る必要があります。分割権限を使用すると、リソースへの分割ブレインアクセスが可能になり、セキュリティを大幅に向上させるために使用できます。

Webサーバーを刑務所に閉じ込めることが可能であっても、多くのシステムでは、刑務所にファイルシステムのかなりの部分を含めることができます。これは設定が難しく、エラーが発生しやすくなります。アプリケーションを刑務所に置くことは、一般的により安全な設定を意味します。この場合、誤った刑務所を構成するリスクが原因で、この信頼が誤って配置される可能性があります。刑務所がなくても、アクセスの問題を診断するのは難しいかもしれません。大規模なファイルシステムを刑務所から保護することははるかに困難です。

Webサーバーをrootとして起動するには、いくつかの理由があります。

• ポート80にバインドします（1024未満のポートはルート用に予約されているため、リモートユーザーが低ポートのサービスに接続すると、そのサービスがルートで承認されたことがわかります）。
• chroot などの制限を設定します。
• 該当する場合は、ユーザーのWebページを読み、提供します。

最も重要ではない理由は不適切な設定です。これらの設定を保護する最も簡単な方法は、ユーザーにページを公開するように求めることです。これは、ユーザーがアクセス制御が可能な個人のWebページを望む場合には機能しません（たとえば、教授はネットワークを介してテストテキストを共有したいが、学生が大学のコンピュータに表示されないようにしたい場合など）。この場合、より洗練されたアプローチが必要です（たとえば、Webサーバーがそのページを読むことを可能にするACLがWebページに存在する必要があります）。

root で起動された Web サーバーは通常、root としてのみ起動された後、専用ユーザーとして権限が縮小されます。権限を放棄する前に、ポート80をバインドし、一部のファイル（SSL秘密鍵ファイルなど）を読み取り、他の抑制を実行することもできます。

[なぜできませんか？]実行中のバイナリでwithを使用しますかsetcap(8)？CAP_NET_BIND_SERVICE

これは可能ですが、その機能をサポートするシステムが必要です。これはUnixの歴史に関して比較的新しいものであり、Webサーバーの歴史に関してもそうです。

[なぜですか？] （rootではない）ユーザーがそこに書き込むことができるようにログフォルダを設定しますか？

通常、これは行われます。それ以外の場合、WebサーバープロセスはUnixまたはインターネットソケットを介してロギングデーモンに書き込みます。

[できない理由] chrootが役立つ場合は、chrootまたはlxcを使用してWebサーバーを「閉じ込め」ますか？

これは、WebサーバーがSSL秘密鍵などのすべての構成ファイルを読み取ることができることを意味します。場合によっては、脆弱性が原因でリモート攻撃者が任意のファイルを検索する可能性があります。サーバーが構成ファイルにアクセスできないように制限すると、このような状況で露出を回避できます。

ほとんどのUNIXシステムの1つの弱点は、許可されていないプロセスが逃げることができない制限領域を設定することを許可しないことです。 Linuxではこれが可能です。カーネル3.8のネームスペースの改善、まだ広く使用されていません。