この一連の記事では、systemdによって有効になる私のお気に入りのRedHatEnterprise Linux（RHEL）8機能のいくつかについて説明します。 。したがって、このシリーズは、systemdの基本概念に精通していることを前提としています。 。適切な紹介が必要な場合は、RedHatカスタマーポータルとプロジェクトサイトに豊富な製品ドキュメントがあります。または、YouTubeには、続行する前に追いつくためのプレゼンテーションが多数用意されています。
Systemdは、サービスとアプリケーションを相互に、および基盤となるオペレーティングシステムから分離するために使用できる多数のセキュリティ機能を提供します。多くの場合、systemd Linuxカーネルによって提供されるのと同じメカニズムに簡単にアクセスできます。これらのメカニズムは、Linuxコンテナーの分離を作成するためにも使用されます。従来のアプリケーションやサービスにコンテナ風の分離を提供する機能は強力です。これは、コンテナが必要とする運用上の影響なしに、ワークロードのセキュリティと分離を簡単に改善できるためです。コンテナの採用に触発された運用上および組織上の変更は、確かに健全で価値のあるものであることに注意してください。ただし、最もコンテナに精通した企業でも、セキュリティが最優先事項である従来のLinux展開が多数あります。これから説明するように、これらのシステムのワークロードは、対応するユニットファイルを少し調整するだけでメリットが得られます。
Red Hat EnterpriseLinux7および8に共通のセキュリティオプション
以下で説明するオプションの大部分は、バイナリのtrueを受け入れます。 またはfalse それらを簡単に有効にする構成。追加のオプションを含むものがいくつかあり、これらの中で最も重要なものも示されています。詳細については、完全なドキュメントとマニュアルページを参照してください。これらのオプションの要点を気にしない場合は、次のセクションに進んで、より一貫性のある例としてこれらのオプションをまとめます。
| オプション | 説明 |
|---|---|
PrivateTmp=yes | /tmp/systemd-private-*-[unit name]-*/tmpの下にファイルシステムの名前空間を作成します 共有の/tmpではなく または/var/tmp 。 Red Hat Enterprise Linuxに同梱されているユニットファイルの多くにはこの設定が含まれており、/tmpで使用されるファイルの予測と置換に関する脆弱性のクラス全体が削除されます。 。 |
PrivateNetwork= | ループバックインターフェイスのみを使用できるサービスのネットワーク名前空間を提供します。外部ネットワーク通信を必要としないアプリケーションに最適なオプションです。 |
SELinuxContext= | 特定のコンテキストでアプリケーションを実行します。このオプションは、RHELの外部に出荷されたアプリケーションでポリシーがいつ利用可能になるかを定義するための良いアイデアです。優れたSELinux入門書はこちらから入手できます。 |
NoNewPrivileges= | サービスと関連する子プロセスが特権を昇格させないようにします。 |
ProtectSystem=yes | /usrを作成します および/boot アプリケーションへの読み取り専用。このオプションをfullに設定する /etcも作成します 読み取り専用。 Red Hat Enterprise Linux 8には、strictと呼ばれる追加オプションがあります これにより、/devも作成されます 、/proc 、および/sys 読み取り専用。 |
ProtectHome=yes | /homeを作成します 、/root 、および/run/user 空に見えます。追加のオプションはread-onlyです 、それはまさにそれが言うことをします。 RHEL8の新機能tmpfs これらのポイントで、書き込み可能な一時的なファイルシステムをオーバーレイします。これらのディレクトリはSSHキーやその他の機密情報を保存するために使用されるため、アプリケーションによるアクセスを禁止することをお勧めします。 |
ProtectDevices=yes | プライベート/devを作成します /dev/nullのような疑似デバイスのみを含む名前空間 および/dev/random 、実際のハードウェアへのアクセスを提供しません。また、CAP_MKNODを無効にします 新しいデバイスノードを作成できないようにします。 |
CapabilityBoundingSet= | ユニットの特権機能のホワイトリストとブラックリストを受け入れます。 Linuxの機能は、システムへのrootユーザーのアクセスを分解するため、特権アクセスをより正確に特定できます。典型的な例は、NTPまたはchronyの場合です。 システムクロックを設定できるが、他の特権アクションを実行できないようにするため。詳細については、機能（7）のマニュアルページを参照してください。 |
|
| ProtectSystemと同様に動作します 、ただし、これら3つのオプションはすべて、ファイルシステムアクセスをきめ細かく制御できます。 |
Red Hat EnterpriseLinux8の新しいセキュリティオプション
Red Hat EnterpriseLinux8で利用可能な新しいsystemdセキュリティオプションは次のとおりです。
| オプション | 説明 |
|---|---|
ProtectKernelTunables=yes | /procの変更を無効にします および/sys 。 |
ProtectKernelModules=yes | モジュールとマスクのロードまたはアンロードを禁止します/usr/lib/modules アプリケーションから。 |
ProtectControlGroups=yes | /sys/fs/cgroup/への書き込みアクセスを無効にします 。 |
RestrictNamespaces= | 名前空間のすべてまたはサブセットをサービスに制限します。 cgroupを受け入れます 、ipc 、net 、mnt 、pid 、user 、およびuts 。 |
AssertSecurity= | サービスを開始するためにシステムが満たす必要のあるいくつかの要件を取ります。リストされた機能が利用できない場合、サービスは実行に失敗し、イベントがログに記録されます。 selinuxなどのオプション およびuefi-secureboot 多くの環境で役立ちます。 |
MemoryDenyWriteExecute= | 書き込みと実行を同時に実行できるメモリマッピングを無効にします。 |
RestrictRealtime=yes | リアルタイムのスケジューリングを禁止します。 |
PrivateMounts=yes | サービスをプライベートマウント名前空間で実行します。 |
DynamicUser=yes | アプリケーションの一時的なユーザーを効果的に作成します。このオプションは、おそらく独自の投稿で探索する必要がありますが、簡単に言うと、systemd nssをプラグインすることで動的に（名前が示すように）UIDとGIDを作成するため、実装は優れています。 その場でユーザーを「作成」するモジュール。これらのユーザーは、サービスが実行されていないときは存在しません。この機能はステートレスアプリケーションに最も役立ちますが、ディレクトリをマッピングして書き込みを行うことができます。 |
SystemCallFilter= | 個々のシステムコールをホワイトリストに登録してブラックリストに登録したり、systemdのユーザーフレンドリーなコールグループを使用したりできます 提供します。 seccompに精通している場合 コンテナでフィルタリングする場合、このオプションはまったく同じことを提供します。一般的な意味で、ほとんどのユーザーは@system-serviceを見つけるでしょう。 貴重なフィルター。これにより、ほとんどのサービスで必要とされる関連するシステムコールが可能になります。ユーザーは、systemd-analyze syscall-filterを実行することで、グループと利用可能なシステムコールのリストを表示できます。 。 |
[Red Hat Enterprise Linuxを試してみませんか？今すぐ無料でダウンロードしてください。]
ここまで進んだら、「OK、これは本当に強力に思えますが、これは覚えておくべきことがたくさんあります」と思うかもしれません。幸い、Red Hat Enterprise Linux 8.1の時点で、これらのオプションの参照とステータスの確認をはるかに簡単にするコマンドが追加されました。
systemd-analyze security [unit]
このコマンドは、システムがsystemdをどのように活用しているかのクイックスナップショットを生成します のサンドボックス化。ユニットごとの個々の設定を表示することもできます。この設計により、利用可能なオプションを簡単に識別し、それらの使用法を詳細なレベルで表示できます。
これがデフォルトのhttpd.serviceの出力です 単位：
systemd-analyze securityからのこの出力 は、名前、便利な説明、および露出評価を示しています。これは、サービスごとに利用可能なセキュリティ設定の消費を示し、サービスがどれだけ孤立しているかから加重露出スコアを生成します。このツールは、システムで実行されているコードまたはアプリケーションのセキュリティに関する全体的な見解や意見を提供することを目的としたものではないことに注意してください。 httpd.serviceという理由だけで UNSAFEとして戻ってきます デフォルトのインストールでは、サービスが安全でないことを意味するわけではありません。
ユニットにクエリを実行し、使用されているコントロールを確認する方法がわかったので、これらを単純なWebサーバーに適用する方法を見てみましょう。この汎用的な例は、他のサービスやアプリケーションの簡単な出発点として役立ちます。
まず、systemdドロップインを作成して、セキュリティオプションを追加します。 Red Hat Enterprise Linux 8の場合、以下を実行します：
# systemctl edit httpd
または、必要に応じて、手動で/etc/systemd/system/httpd.service.d/security.confを作成します。 。
ファイルへのアクセス方法に関係なく、次を追加します。
[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
NoNewPrivileges=yes
PrivateTmp=yes
Red Hat Enterprise Linux 7の場合、同様のテンプレートを使用できます：
[Service]
ProtectSystem=full
ProtectHome=yes
PrivateDevices=yes
NoNewPrivileges=yes
PrivateTmp=yes
ファイルを保存してサービスを再起動したら、httpd サービスは、他のオペレーティングシステムから大幅に分離されます。サービスが危険にさらされた場合、ブレイクアウトとそれに続く損害の可能性は大幅に減少します。
上記の例は、システムで実行されているサービス、アプリケーション、およびユニットをロックダウンするための優れた出発点です。もちろん、これらをテストして、フリート全体に展開する前に、ユースケースに適していることを確認する必要があります。たとえば、ユーザーのホームディレクトリからコンテンツを提供する場合、ProtectHome=yesは含めません。 、ただし、代わりにProtectHome=read-onlyを使用してください 。また、RHEL 7で実行されるユニットファイルにRHEL8で追加された新しいオプションを含めても、害はありません。通知メッセージが発行され、オプションは無視されます。
systemd-analyze httpdを実行して、使用中のオプションを表示できるようになりました ：
現在、多くのオプションがWebサーバーに適用されていることがわかります。レーティングもUNSAFEから変更されました MEDIUMへ 。より多くのオプションを有効にしてサービスをさらにロックダウンすることは完全に可能ですが、現実の世界の多くのサービスやアプリケーションにうまく適用できる実用的な例を提供するという目標からは外れています。従来のサービスの基盤となるOSへのアクセスを制限することがこれほど簡単だったことはかつてありませんでした。
独自のソフトウェアの保護に関心のある開発者の場合、関連するセキュリティオプションを、アプリケーションに含まれているユニットファイルに簡単に追加できます。 Red Hatは、開発者がデフォルトで可能な限り多くのセキュリティを「組み込む」ことを強く推奨しています。これは、その目標を達成するための最も簡単な方法の1つです。
ここに示されているセキュリティ機能がSELinuxと冗長であるかどうか疑問に思っている人のために、機能には重複がありますが、それらはほとんど独立しています。これらの設定は、SELinuxが使用されているかどうかに関係なく適用されます。この機能は、特定のシステムのポリシーまたはアプリケーション要件のためにSELinuxが実行可能なオプションではない場合に大きな価値があります。理想的な世界では、これらはwithで使用されます セキュリティへの階層型アプローチの一部としてのSELinux。
systemdを使用してRedHatEnterpriseLinux8にインストールされたワークロードを分離してサンドボックス化することがいかに簡単であるかを楽しんでいただけたと思います。 。次に、先に進み、必要に応じて、この知識を環境全体に適用します。このシリーズの次の記事では、Linuxコントロールグループ（別名cgroups）の使用について説明します。 、systemd経由 貴重なシステムリソースを保護し、「騒々しい隣人」の問題を解決するため。