Debian + Nginx/Unicorn 権限

UnicornなどのWebサーバーをrootとして実行すると、セキュリティ上のリスクはありますか？

Thomasがsec.seチャットで言ったように、何もないルートには隠されたセキュリティリスクがあるからです。ルートについて理解する必要があるのは、カーネルが基本的に自分が行うすべてを信頼し、文句を言わないということです。

この問題は、nginxまたはunicornに脆弱性がある場合に発生します。このような場合可能悪用および乱用プロセスを実行する可能性があります。

しかし、悪用ベクトルが何であるかを理解するには、これらのサーバーの仕組みを理解することが重要です。理論的には、root権限を保持するには、構成の読み取りとbind()操作（サーバーポート< 1023と仮定）の2つの部分を実行する必要があります。

unicornは事前フォークされたモデルとして機能します（gunicornが似ていると仮定）。各クライアント要求は別々のプロセスで処理されます。ルートとして実行されるプロセスのタスクは、必要なポートにバインドし、接続をワーカープロセスに転送することです。ワーカーモデルはスレッドとプロセスを混合します。私が理解したように、nginxは非常に似た方法で動作しますが、非同期IOには大きな偏りがあります。epoll//私は信じていますkqueue。accept見たらc10k問題を解決するための戦略そのため、デザインはそのように動作します。

理論的には、ほとんどのワーカープロセスはroot権限を放棄でき、seteuid()放棄する必要があります。seteguid()これらのプロセスがすべてのトラフィックをルートとして処理しない場合、問題が発生します。ほとんどのプロセスはroot権限を放棄します。私も2つの明確な声明をする必要があります：

1. 1024未満のポートにバインドしない場合は、ルート以外のものとして実行するようにnginxデーモンを設定できます。
2. 私の場合は、ユニコーンを設定してソケットファイルを作成できます。つまり、rootとして実行する必要はありません。 nginxはWebリクエストをUnixソケットにプロキシできます。つまり、gunicornは決してTCP接続を公開しません。

コードの「脆弱な部分」しなければならないしたがって、これは設定ファイルを解析して接続を切り替えるのと同じです。理論的にしたがって、この方法が効果的で厳格なテストを受けたと仮定すると、ルートにかかるリスクは非常に少なくなります。

POSIX機能ルート機能の一部を他のプロセスに委任する別の方法です（CAP_NET_BIND_SERVICEたとえば、setuidビットを除く）。プロセスがルートでない場合でも、1024未満のポートにバインドできます。私は彼らが属性を拡張することによって動作すると信じています。 Fedoraは最近（f16？）すべてのパッケージが固定ビットの代わりに機能を使用することを保証し始めました。

注目すべきもう一つの点は肯定的な点です。ユニコーンは、私が正しく理解していたら、Rubyプロセスです（Gunniconは確かにPythonプロセスです）。解釈された言語を使用すると、文字列処理が確実に安全であり、ポインタを使用できないため、開発者がバグを導入するリスクが軽減されます。ただし、インタプリタのバグは、すべてのインタプリタにセキュリティリスクをもたらす可能性があります。

しかし、残念な現実は、破損したプロセスが依然としてwww-data問題になる可能性があるということです。攻撃者がデータベースをダンプし、ウェブサイトを破壊する可能性があります。ルートが安全であることを知っておくとよいでしょうが、ウェブサイトが顧客にとって主要な広告ポイントである場合、ルートが破損することはまだビジネスに脅威となる可能性があります。

一般化する

はい、ユニコーンをrootとして実行するのは危険です。しかし、ルートとして実行されるコードの面では、攻撃面は比較的小さい。また、rootとして実行されているジョブを最小限に抑えるオプションがあります。また、SELinuxのようなMACシステムも扱っていませんが、学ぶ準備ができていると仮定すると、実行可能なオプションと機能です。理解すべき重要な点は、リスクはバランスであるということです。サービスがどれほど敏感で重要であるかに応じて、それを保護するためにどれだけの努力を払うべきかが決まります。銀行のウェブサイトを運営している場合は、システムを強化する方法を真剣に検討することができます。 Lollcatイメージをホストしているサイトであれば（何を言っているのか分かります）、現在の設定が大丈夫だと思うかもしれません。