systemd はシステム管理デーモンのセットです
最近、 systemd開発者が議論しました テーブルの上に置かれた状態 libsystemd ライブラリの依存関係を減らす問題 (サービスの実装と systemd との対話を担当するライブラリ)。これは、現在特定の状況があるためです。 プロジェクトによって制御されない libsystemd 内のサードパーティへの依存関係が増加することへの懸念 これにより、攻撃対象領域が増加します。ディスカッションスターターは、libsystemd が liblzma や glibc に加えて、libzstd、liblz4、libgcrypt などのいくつかの重要なライブラリをロードすることに注意しています。これにより、特にこれらのサードパーティ ライブラリが侵害された場合、重大なセキュリティ問題が発生します。
たとえば、Fedora では 150 以上のパッケージが libsystemd に依存しており、複雑さとそれに伴うリスクが増大しています。 提案 これに対処するには、次のことが必要です libsystemd をいくつかの個別のライブラリに分割し、それぞれが特定の API を担当します。 これにより、サードパーティの依存関係を必要な場合にのみロードできるようになり、systemd 開発者によって直接制御されていないライブラリの潜在的な脆弱性への露出が軽減されます。
しかし、 開発者 systemdによる 彼らは、この分離には問題があると主張している libsystemd に存在するドライバーの相互接続が原因です。彼らは、分割は労働集約的であり、効率の低下やコードの重複の必要性を招く可能性があり、意図したセキュリティ上の利点が損なわれる可能性があると考えています。
完全な別離ではなく、 libsystemd は、動的にロードすることで、より動的なアプローチを採用しました。 必要に応じて、dlopen() 呼び出しを使用して liblzma、libzstd、および liblz4 ライブラリを使用します。セキュリティ上の懸念とコードの効率性および保守性のニーズの両方に対処するために、将来のリリースの libgcrypt にも同様の変更が実装される予定です。
これらの依存関係のほとんどは、上記のようなコア libsystemd 機能を実装するのに必要ではないと思います。
この問題は、libsystemd を、異なる API を実装する複数のライブラリに分割することを意味する可能性があります。そのうちの 1 つ (たとえば、libsystemd-core) は libc にのみ依存し、他のより特殊なライブラリは他の依存関係を追加することになります。また、依存関係の一部が特定の systemd サービスにのみ必要な場合は、依存関係をそれらのサービスに移動します。
この最終的な効果は、攻撃対象領域を減らし、システムのセキュリティを向上させることです。
議論中 ほとんどの開発者が批判していた点が 1 つありました、そして彼らは次のように述べています。 サードパーティライブラリを暗黙的にロードする決定 libsystemd で dlopen() を使用する 追加の作業が発生する 診断がさらに複雑になり、リンクが可視化されないため、コード内では明らかではないため、外部ライブラリ関数に接続する libsystemd API 呼び出しの識別が複雑になるとも述べています。この新しいロード方法は、基礎となるアーキテクチャを変更するものではありませんが、外部コンポーネントをメンテナやユーザーから隠します。
レナート・ポタリングは反対を表明 複雑になるため、libsystemd を複数のライブラリに分割するというアイデアにより、コード共有がもたらされ、API と名前空間の安定性が維持されます。 libsystemd を分割するには、すべての内部ドライバーを公開するか、各ライブラリーで個別に静的にコンパイルする必要があります。これにより、コードの重複によりサイズが増加したり、システムの安定性と一貫性の管理が困難になったりする可能性があります。
分けるのではなく、 必要な場合にのみ外部ライブラリをロードする戦略が最適であると考えられます。 さらに、診断の複雑さの増加に対処するために、ロードされた動的依存関係に関する情報を含むフィールドを ELF ファイルに追加し、デバッガーがこの情報を処理して、readelf などのツールの出力に表示できるようにすることが提案されています。これにより、libsystemd で使用される動的依存関係の透明性と可視性が向上し、動的にロードされる外部ライブラリに関連する問題の診断とデバッグが容易になります。
Lenart が開発者に推奨 アプリケーションの、 libsystemd に直接リンクする代わりに 特定の機能用、プロトコル ハンドラーはアプリケーション レベルで実装されます。.
アプリケーション レベルでプロトコル ドライバーを実装するこの戦略 いくつかの利点がありますs:
- libsystemd への依存性を減らし、不要な外部ライブラリのロードを回避します。
- アプリケーションに必要な特定の機能に対する柔軟性と制御が向上します。
- 特定の機能の実装をより直接的に制御できるため、診断とデバッグが簡素化されます。
- 一般に、このアプローチはアプリケーションのモジュール性と独立性を促進し、ソフトウェア開発とメンテナンスの柔軟性と効率を向上させます。
もしあなたが それについてもっと知りたい、詳細を確認できます 次のリンクで。