Webサーバーが従来スーパーユーザーとして起動されたのはなぜですか？

Question

将来のWebサーバーのセットアップについて考えると、何らかの理由でWebサーバーは通常rootとして開始し、ワーカープロセスの特定の権限（setuid）を削除することに気付きました。さらに、多くの場合chrootが関係していますが、これはセキュリティ対策として正確に意図されているわけではありません。

私が疑問に思っていたのは、なぜWebサーバー（Apache、lighttpdからnginxまですべてを管理した）が_CAP_NET_BIND_SERVICE_などの機能システム（ capabilities(7) ）を使用できないのですか？、Linuxで、root以外のユーザーとして起動しますか？ ...この方法でも、1024未満の特権ポートでリッスンしています。

それ以上に、それらのほとんどは可能だと思いますが、なぜそれが一般的な方法ではないのですか？何故なの ...

実行中のバイナリで_CAP_NET_BIND_SERVICE_を使用して setcap(8) を使用しますか？
（root以外の）ユーザーがそこに書き込むことができるようにログフォルダーを設定します
...、chrootがまったく役に立ったと感じた場合は、chrootまたはlxcを使用してWebサーバーを「投獄」しますか？

（ワーカー）子プロセスが親を殺す可能性があること以外に何もありません。それは、rootとして完全に開始するよりもこれをあまり有益ではないものにする可能性があります。

では、その後、それに伴う暗黙のセキュリティ問題を取り除くためにすべてが行われるのに、なぜ伝統的にルートとして開始されるのですか？

goldilocks · Accepted Answer

POSIXには、CAP_NET_BIND_SERVICEを含むと思われる機能の標準がありますが、これらは conformance には必須ではなく、Linuxなどの実装では incompatible になる可能性があります。

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

どのWebサーバーもこのように使用できるようにシステムを構成できるように思えます。このWRTApacheに関するいくつかの（おそらく不器用な）提案がここにあります： NonRootPortBinding 。

では、なぜそれらは伝統的にrootとして開始され、その後、それに伴う暗黙のセキュリティ問題を取り除くためにすべてが行われるのですか？

通常は特権ポートにアクセスする必要があるため、rootとして開始され、従来はこれが唯一の方法でした。後でダウングレードする理由は、後で特権を必要とせず、サーバーで一般的に使用される無数のサードパーティアドオンソフトウェアによってもたらされる潜在的な損害を制限するためです。

特権アクティビティは非常に制限されており、慣例により、他のinetデーモン（sshdなど）を含む他の多くのシステムデーモンが継続的にrootを実行するため、これは不合理ではありません。

サーバーがCAP_NET_BIND_SERVICEを使用して非特権ユーザーとして実行できるようにパッケージ化されている場合、これによりany非特権ユーザーが起動できることに注意してください。 HTTP（S）サービス。これはおそらくより大きなリスクです。

BillThor · Answer

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

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

デーモンプロセスがrootとして実行され、rootアクセスを必要とするすべてのことを実行してから、非特権UIDに切り替えるのが一般的です。これにより、リソースを保護しながら、実行後にプログラムが大きなダメージを与えるのを防ぐことができます。 Webサーバーの場合、SSLキーはルージュサーバーアプリケーションによって読み取られないように保護する必要がありますが、SSLリスナーを構成するために読み取る必要があります。分割特権により、セキュリティを大幅に向上させるために使用できるリソースへの分割アクセスが可能になります。

Webサーバーをジェイルすることは可能ですが、多くのシステムでは、ジェイルにファイルシステムのかなりの部分が含まれている可能性があります。これは、構成が難しく、エラーが発生しやすい可能性があります。アプリケーションをジェイルすることは、一般的に、それがより安全な構成であることを意味します。この場合、刑務所が正しく構成されていないというリスクのために、その信頼が誤って配置される可能性があります。刑務所がなくても、アクセスの問題を診断するのは難しい場合があります。ファイルシステムの大きなチャンクをjailから除外すると、これはさらに困難になります。

Gilles &#39;SO- stop being evil&#39; · Answer

ルートとしてWebサーバーを起動する理由はいくつかあります。

ポート80にバインドする（1024未満のポートはrootに予約されているため、リモートユーザーが低いポートでサービスに接続している場合、このサービスがrootによって承認されていることがわかります）。
閉じ込めを設定するため、例えばchroot;
該当する場合、ユーザーのWebページを読んで提供するため。

その最小の理由は、セットアップが不十分なことです。このような設定を保護する最も簡単な方法は、ユーザーにWebページを公開するように要求することです。これは、ユーザーがアクセス制御を備えたプライベートWebページを持ちたい場合（たとえば、教授がWeb経由で試験テキストを共有したいが、学生にそれらを見せたくない大学のマシン）には機能しません。この場合、より高度なアプローチが必要です（たとえば、WebページにWebサーバーがそれらを読み取れるようにするACLが必要です）。

Rootとして起動されるWebサーバーは、多くの場合rootとしてのみ起動しますが、その後、専用ユーザーに特権をドロップします。特権を削除する前に、ポート80をバインドし、場合によっては一部のファイル（SSL秘密鍵ファイルなど）を読み取り、場合によっては他の封じ込めを実行します。

[なぜ]実行中のバイナリでsetcap(8)をCAP_NET_BIND_SERVICEとともに使用しますか？

それは可能ですが、機能をサポートするシステムが必要です。 Unixの歴史、さらにはWebサーバーと比較しても、これは比較的最近のことです。

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

それは通常行われます。または、WebサーバープロセスがUnixまたはインターネットソケットを介してログデーモンにログを記録します。

[なぜ] chrootがまったく役に立ったと感じたら、chrootまたはlxcを使用してWebサーバーを「jail」しますか？

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

ほとんどのUNIXシステムの弱点は、特権のないプロセスが、抜け出すことができない閉じ込め領域を設定することを許可しないことです。 Linuxでは、これは可能です。カーネル3.8での名前空間の改善は、まだ広く利用可能ではありません。