(ほとんどの場合) 人々は意図的に脆弱性を挿入するのではなく、偶然に発生します。コードの量が増えると、欠陥の数が増えます。ただし、サイズだけではありません。複雑さに応じてバグの数が増えます コードの、それは線形よりも速く増加します。したがって、コードの増加はセキュリティにとって悪いニュースです。
systemd の攻撃面は initd よりもはるかに大きく、デフォルト構成には複数のインターフェースがあります。
私にとって大きな悩みは、デザイン哲学です。その意図は、systemd が、ディストリビューターがサービスを統合するためのより統一された方法を提供することです。しかし、これは、システム管理者からシステムに対する制御を取り除くことを意味します (複雑ではあるが十分に理解されているエコシステムを置き換えることの影響以上に)。 initd で実行できることを意図的に困難または不可能にしています (initd で実行されるサービス マネージャーには多くのオプションがあることに注意してください - djb daemontools、upstart、initng、rund、procd、openrc....そのほとんどは解決しますsysv rc init システムを制限する並列化/依存関係の問題)。
UNIX システムの起動ロジックの多くは、シェル スクリプトで実装されています。これにより、オペレーションをリバース エンジニアリングするだけでなく、インストルメント化し、機能を拡張することも容易になります。 Systemd は、より多くのロジックをバイナリに移動し、複雑なドキュメント化が不十分なより多くのロジックに依存しています 構成。
システム管理者による制御レベルを意図的に低下させ、システム管理者のタスクをサポートしないことが組み合わさると、システムのセキュリティを保証することを含む、システム管理者の仕事をより困難にします。
PID 1 におけるこのすべての複雑さのさらなる結果は、システムをより頻繁に再起動する必要があることを意味します。可用性への影響に加えて、これはシステムを一連の暫定的な状態に移行させることも意味します。これにより、恒常的なシステムでは検出が困難な脆弱性が一時的に露呈する可能性があります。これを回避するために daemon-reexec を使用すると、新たな一連の問題が発生します。
慈悲深い終身独裁者モデルは、Linux カーネルではうまく機能しているように見えますが、それは他のオープン ソース業界のやり方ではありません。実際、誰も担当していないにもかかわらずではなく、誰も担当していないからオープンソースが機能するというルールを証明するのはおそらく例外です。 Systemd が lot の制御を引き受けます Linux システムの機能の一部ですが、比較的小規模なコミュニティとして運営されています。そして、pwnie 賞によると、それはやや内向的であるように見えます:コードには多くの目玉がありません:コードについて懸念が提起されても、誰も耳を傾けません.
Systemd は実際にはいくつかのパーツの集まりであり、比較を意味のあるものにするためには、実際に互いに対応するパーツを比較する必要があります。
最初に SysV init を見てみましょう:これはブート後の最初のプロセスとして実行される非常に小さなプログラムで、非常に基本的なセットアップを行い、構成ファイル (/etc/inittab ) で構成された 1 つまたは複数のプログラムを開始し、オプションで終了時にそれらを再起動します。また、いくつかの通信チャネルも開きます (/dev/initctl 、シグナル ハンドラー) により、現在のランレベルを変更できます。変更すると、/etc/inittab で構成されているように、他のプログラムが実行されます。 .
以上です。明らかに、これには大きな攻撃対象領域がありません。単純にほとんど何もしないからです。反対に、一般的なシステムを実際に管理するために必要な他のすべてのことは、外部プログラムに委譲されます:特定のサービス (Web サーバー、データベース、ネットワークなど) を開始および停止する方法、サービス間の依存関係 (つまり、最初にデータベースを開始する) 、その後は Web サーバーのみ)、より複雑な監視 (ウォッチドッグ機能)、権限の削除とサンドボックス化、オンデマンド サービスのアクティブ化 (inetd など)、ファイルシステムのマウント、... Systemd はこの機能の多くを統合するため、より複雑になります。
現在、これらのものを中央の場所に統合することで、全体的な複雑さと脆弱性を軽減し、それによってシステムをより安全にする大きな可能性を秘めています.特権の削除、特定のディレクトリへのアクセスの制限、プライベート一時ディレクトリ、個別の名前空間の設定、ネットワークの分離など、さまざまな「サンドボックス」機能を利用してください... systemd の場合、これらはサービス環境のセットアップの一部として非常に簡単に実装できます。 - サービス マネージャーとして - とにかくしなければなりません。対照的に、SysV init では、別のプログラムを使用する必要があります。実際には、これは一連のシェル スクリプトになるか、個々のサービスに統合されて、「危険な」コードがより多くの場所に拡散されます。
さらに、systemd はシステム管理者にこれらの機能を簡単にセットアップする手段 (構成ファイルの数行) を提供し、それらを自分で実装する必要がないようにします (場合によっては、サービスの変更や再コンパイルが必要になることもあります!)。もちろん、実際には、これはまったく使用されないことを意味します。セキュリティの観点から、ini スタイルの構成形式は、SysV init で使用されるチューリング完全なシェル スクリプトよりも優れています。
systemd の背後にある開発モデルについては、開発 (および広範なテスト!) が行われる中心的な場所が 1 つあるため、これは別の方法に比べて利点があると考えています。 SysV init コア自体でさえディストリビューション間で異なっていました。そのアップストリームは死んでいると見なすことができるからです。他の人が言うこととは反対に、systemd アップストリームは実際には非常に反応がよく、妥当な変更要求に対してオープンです。
とはいえ、異なる状況が 1 つあります。それは、systemd によって提供される機能が必要ない場合です。たとえば、必要なサービスのセットが事前にわかっているルーターや単純なネットワーク ゲートウェイを構築する場合などです。変わることはありません。そこでも、使いやすいサンドボックス機能を利用したい場合がありますが、これは大部分のシステムには当てはまらない特殊なケースです.