AlmaLinux 9とAlmaLinux 10、httpdのsystemd-analyze securityスコアを比較したら3.2ポイントも違った話

Linux
Linux
スポンサーリンク

Apache httpd のセキュリティハードニングを検討する過程で、AlmaLinux9とAlmaLinux10にそれぞれインストールしたhttpdでsystemd-analyze securityのスコアを比較してみました。結果はアイキャッチの画像の通りです。(スコアが低いほど、リスク判定が低くセキュリティ的に優れていることを意味します)インストール直後、何も手を加えていない状態で3.2ポイントもの差がついていました。設定を変えたわけではないのに、なぜここまで差が出るのか気になったので、その原因を調べてみました。

【結論】httpdのユニットファイル自体が変わっていた

答えはシンプルで、AlmaLinux10(RHEL10系)のhttpdパッケージが提供するsystemdユニットファイルに、あらかじめセキュリティ強化のディレクティブが組み込まれるようになったことが原因でした。

Red Hatの公式ドキュメントにも、この変更が明記されています。RHEL10ではhttpd.serviceのユニットファイルがデフォルトで複数のセキュリティ強化設定を適用するようになっており、代表例としてProtectHome=read-onlyが挙げられています。これはhttpdサービスから見た/home配下を読み取り専用でマウントする設定です。

参考資料:Chapter 14. Infrastructure services | Considerations in adopting RHEL 10

つまり、AlmaLinux9のhttpdは「素のユニットファイル」(systemdのサンドボックス機能をほぼ使っていない状態)だったのに対し、AlmaLinux10ではRHEL側でパッケージメンテナが最初からある程度ハードニングを施したユニットファイルを配布するようになった、ということです。

実機で差分を確認する

実際にどのディレクティブが増えたのか、両サーバーのユニットファイルを見比べてみます。

AlmaLinux9

$ cat /usr/lib/systemd/system/httpd.service
(略)
[Unit]
Description=The Apache HTTP Server
Wants=httpd-init.service
After=network.target remote-fs.target nss-lookup.target httpd-init.service
Documentation=man:httpd.service(8)

[Service]
Type=notify
Environment=LANG=C

ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
PrivateTmp=true
OOMPolicy=continue

[Install]
WantedBy=multi-user.target

AlmaLinux10

$ cat /usr/lib/systemd/system/httpd.service
(略)
[Unit]
Description=The Apache HTTP Server
Wants=httpd-init.service
After=network.target remote-fs.target nss-lookup.target httpd-init.service
Documentation=man:httpd.service(8)

[Service]
Type=notify
Environment=LANG=C

ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
# Send SIGWINCH for graceful stop
KillSignal=SIGWINCH
KillMode=mixed
DevicePolicy=closed
KeyringMode=private
LockPersonality=yes
MemoryDenyWriteExecute=yes
OOMPolicy=continue
PrivateDevices=yes
PrivateTmp=true
ProtectClock=yes
ProtectControlGroups=yes
ProtectHome=read-only
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=yes
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native

[Install]
WantedBy=multi-user.target

AlmaLinux10側のユニットファイルには、ProtectHome=read-only だけでなく、ProtectSystemProtectKernelTunablesProtectControlGroups といったサンドボックス化機能が標準で組み込まれていました。(※パッケージのマイナーバージョン等によって細かな構成は異なる場合があるため、運用環境では実際のファイルをご確認ください)

各ディレクティブの詳細は、Systemdの公式ドキュメントで確認してください。
systemd.exec — Execution environment configuration

項目単位でどの設定が効いているかを見たい場合は、サマリーを除いた詳細レポートを両サーバーで取得してdiffを取ると分かりやすいです。

systemd-analyze security --no-pager httpd.service > /tmp/httpd_security.txt

このファイルを両サーバーから持ち寄って比較すると、✗だった項目が✓に変わっている箇所が一目で分かり、スコアが3.2ポイント改善した内訳を項目単位で特定できます。

【注意点】ProtectHomeの副作用

ProtectHome=read-onlyは、/home配下にWebコンテンツやアップロードファイルを置く構成(共有ホスティングなど)だと、書き込みができずアプリケーションがエラーになることがあります。

WordPressなどのアップロード機能を持つCMSを運用している場合、ドキュメントルートが/var/www配下であれば通常は影響を受けませんが、/home/ユーザー名/public_htmlのような構成にしている場合は要注意です。RHEL10へ移行する際にhttpdが急に画像アップロードでエラーを吐くようになった、というトラブルは今後増えてくるかもしれません。

おわりに

今回のように、アプリケーションの設定を変更しなくても、OSやパッケージの更新によってセキュリティハードニングが進むケースは今後ますます増えていくと考えられます。そのため、アップデート時には機能面だけでなく、systemdユニットファイルの変更点にも目を向けることが重要です。

この記事をシェアする
あぱーブログをフォローする
スポンサーリンク
スポンサーリンク

コメント

タイトルとURLをコピーしました