systemdサービスをサンドボックス設定で堅牢化する｜段階的な適用と動作確認の手順

なぜ今、systemdサンドボックスが重要なのか

Linuxのサービスは、起動ユーザーの権限をそのまま引き継いで動くことが多く、設定ミスや脆弱性を突かれた場合に被害が広がりやすい構造を持っています。従来はAppArmorやSELinuxといった別ツールでアクセス制御を追加するのが主流でしたが、これらは導入コストが高く、既存環境への後付けが難しい側面がありました。

systemd v219（2015年）以降、サービスユニットファイル自体にサンドボックス指令を書けるようになり、2026年現在の主要ディストリビューション（RHEL 9系・Ubuntu 22.04/24.04・Debian 12）では、カーネルの名前空間機能やケイパビリティ制御との連携が十分に成熟しています。外部ツールを追加せずに、ユニットファイルの編集だけでサービスを最小権限で動かせる環境が整っています。

本記事では、既存のサービスを壊さずに段階的にサンドボックス設定を追加していく手順と、適用後の動作確認・切り戻し方法を一連の流れで説明します。

まず現状のスコアを把握する：systemd-analyze security

設定を変える前に、対象サービスの現在のセキュリティスコアを確認しておきます。systemd-analyze securityコマンドを使うと、各指令の適用状況と数値スコア（低いほど安全）を一覧で表示できます。

$ systemd-analyze security myapp.service

出力には、ProtectSystemやNoNewPrivilegesなど約50項目が並び、未設定のものには「UNSAFE」と表示されます。設定変更の前後でこのスコアを比べると、どの指令が効いているかを数値で把握できます。

スコアが9以上（満点に近い側は0）のサービスは、ほぼ無設定の状態です。一般的なWebアプリやデーモンであれば、本記事の手順を適用後に4〜6程度まで下げることを目安にします。

ユニットファイルを安全に編集する方法

システム管理者がパッケージ付属のユニットファイルを直接編集すると、パッケージ更新時に上書きされてしまいます。systemctl editコマンドを使うと、/etc/systemd/system/myapp.service.d/override.confという上書き専用ファイルが作成されるため、元ファイルには手を加えずに設定を追加できます。

$ sudo systemctl edit myapp.service

エディタが開いたら、[Service]セクションに指令を追記します。保存後は自動的にリロードされますが、実際にサービスへ反映させるには再起動が必要です。

$ sudo systemctl daemon-reload
$ sudo systemctl restart myapp.service
$ sudo systemctl status myapp.service

作成したオーバーライドファイルはsudo systemctl cat myapp.serviceで確認でき、元のユニット定義とのマージ後の全体像を確認できます。

段階的に適用する主要ディレクティブ

一度に全指令を追加すると、どれが動作を壊したか特定しにくくなります。副作用の少ないものから順に1〜2個ずつ追加し、その都度動作確認するのが現場での標準的なやり方です。以下の順序が推奨されます。

第1段階：最も影響が少ない指令から

NoNewPrivileges=yes は、プロセスがsetuidビットやexecve経由で新しい特権を取得するのを禁止します。多くのサービスでそのまま動作し、脆弱性悪用による権限昇格を防ぐ効果があります。副作用はほとんど起きません。

PrivateTmp=yes は、/tmpと/var/tmpをサービス専用の名前空間に隔離します。他サービスの一時ファイルが見えなくなるため、シンボリックリンク攻撃（TOCTOU）の緩和に直結します。/tmpを通じた他プロセスとの連携がない限り、影響は出ません。

第2段階：ファイルシステムの読み取り保護

ProtectSystem=strict は、/usr・/boot・/etcを読み取り専用にマウントします。full（/etcも保護）とstrict（ほぼ全体を読み取り専用）の2段階があり、設定ファイルの書き換えが必要なサービスではReadWritePathsで例外パスを指定します。

[Service]
ProtectSystem=strict
ReadWritePaths=/var/lib/myapp /run/myapp

ProtectHome=yes は、/home・/root・/run/userを空のディレクトリとして見せます。サービスがホームディレクトリを参照する理由はほとんどないため、多くの場合は安全に設定できます。

第3段階：ネットワークとシステムコールの制限

PrivateNetwork=yes は完全なネットワーク分離で、外部通信が不要なバックグラウンド処理専用のサービスに向きます。Webサーバーやデータベースには使えないため、対象を選ぶ必要があります。

SystemCallFilter= は、サービスが使用するシステムコールのホワイトリストを指定します。@system-serviceや@network-ioといったグループ指定が使えるため、個別の列挙より管理しやすくなっています。ただし、設定が厳しすぎるとSIGSYSでクラッシュするため、SystemCallErrorNumber=EPERMを組み合わせてエラーで止める方が動作確認しやすいです。

[Service]
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

動作確認と問題発生時の切り戻し手順

各段階でサービスを再起動したら、以下の3点を確認します。

• systemctl status myapp.service でActiveになっているか
• 実際の機能が動作しているか（ヘルスチェックエンドポイントへのアクセス、ログ出力の確認）
• journalctl -u myapp.service -n 50 でPermission deniedやOperation not permittedが出ていないか

問題が出た場合、まずオーバーライドファイルを開いて直前に追加した指令をコメントアウトし、再起動します。sudo systemctl edit myapp.serviceでファイルを開いて該当行の先頭に#を付けるだけです。完全に元に戻すには、オーバーライドディレクトリごと削除します。

# オーバーライドファイルを完全削除して元の状態へ戻す
$ sudo rm -rf /etc/systemd/system/myapp.service.d/
$ sudo systemctl daemon-reload
$ sudo systemctl restart myapp.service

サービスが起動直後にクラッシュしてsystemctl editが開けないほど状況が悪化した場合は、シングルユーザーモードに入るか、別ターミナルからSSHで接続してファイルを直接削除します。systemdのサンドボックス設定はサービスの起動前処理で適用されるため、OSのリカバリーに影響することはありません。

2026年現行環境での注意点と差分

RHEL 9・Ubuntu 24.04などで採用されているsystemd v252以降では、MemoryDenyWriteExecute=yesとRestrictRealtime=yesがより安定して動作するようになっています。以前はJITコンパイルを行うNode.jsやJavaランタイムとの相性問題が報告されていましたが、cgroup v2環境では多くのケースで解消されています。

ProtectClock=yes（システム時刻の変更を禁止）とProtectKernelLogs=yes（カーネルログリングバッファへのアクセス禁止）は、systemd v245以降で導入されたディレクティブです。RHEL 8系（systemd v239）では使えないため、複数バージョンをまたいで管理している環境では注意が必要です。systemd --versionでバージョンを確認してから適用する習慣が求められます。

Ubuntu 22.04/24.04ではcgroup v2がデフォルトになっており、MemoryMaxやCPUQuotaといったリソース制限指令も合わせて設定することで、サンドボックス＋リソース保護の二重の防御が構成できます。cgroup v1環境（一部のコンテナ基盤や古いRHEL 8）ではこれらの指令が無視されることがあるため、クラウドVMとオンプレミスが混在する環境では動作確認が欠かせません。

コンテナ環境（DockerやPodmanの上でsystemdを動かすケース）では、ホストのカーネル名前空間とコンテナ内の名前空間が競合し、PrivateNetwork=yesやPrivateUsers=yesが期待どおりに動作しないことがあります。コンテナ内でsystemdを使うアーキテクチャでは、ホスト側のsystemdスコープとコンテナ内のユニット設定を明確に分けて管理することが推奨されています。

段階的な適用と動作確認の繰り返しは手間に感じられますが、本番サービスに影響を与えずにセキュリティレベルを引き上げる現実的な方法です。systemd-analyze securityのスコアを指標にしながら、重要度の高いサービスから順に取り組むことで、追加ツールなしでシステム全体の堅牢化が着実に進みます。