Linuxの名前空間（Namespace）セキュリティ入門｜PID・Network・Mount・User Namespaceで攻撃の影響範囲を封じ込める実践ガイド

「サーバーが侵害されたとき、被害がどこまで広がるのか——そこが一番怖い」と感じているエンジニアは多いはずです。ファイアウォールやfail2banで入口を塞いでも、いったん内部に侵入を許すと横展開されてしまう。対策はあるのでしょうか。

Linuxにはそのリスクを大幅に下げる仕組みが標準搭載されています。それが名前空間（Namespace）です。Dockerをはじめとするコンテナ技術の土台として知られていますが、コンテナなしでも、サーバー単体のセキュリティ強化に直接使えます。

この記事では、Linux Namespaceを「防御のために知る」という視点で解説します。PID・Network・Mount・User Namespaceの仕組みと、unshare・ip netns・systemdを使った実践設定まで、現場で使えるレベルで体系的に紹介します。

Linuxの名前空間（Namespace）とは？

名前空間とは、Linuxカーネルが提供する「プロセスが見える世界を切り分ける」機能です。通常、すべてのプロセスはシステム全体のリソース（プロセスリスト・ネットワーク・ファイルシステムなど）を共有しています。名前空間を使うと、あるプロセスグループだけが見えるリソースの範囲を限定できます。

現在Linuxが提供する名前空間には以下の種類があります。

・PID Namespace: プロセスIDを分離。名前空間内ではPID 1から始まる独自の番号体系を持つ
・Network Namespace: ネットワークインターフェース・ルーティングテーブル・iptablesルールを分離
・Mount Namespace: ファイルシステムのマウントポイントを分離
・User Namespace: UID/GIDマッピングを分離。非rootユーザーが名前空間内だけでroot相当の権限を持てる
・UTS Namespace: ホスト名・ドメイン名を分離
・IPC Namespace: System V IPCやPOSIXメッセージキューを分離
・Cgroup Namespace: cgroupのルートビューを分離

これらを組み合わせることで、プロセスを「見えるリソースが限定された隔離環境」に置けます。DockerやPodmanがコンテナを実装する際にまさにこの仕組みを使っており、コンテナなしでも同じ技術をサーバーに直接適用できます。

名前空間がないと何が起きるか（攻撃者の視点）

名前空間による分離がない環境での侵害シナリオを、防御目的で理解しておきましょう。

Webサーバープロセス（nginx/Apacheなど）が脆弱性経由で侵害されたとします。分離がない場合、攻撃者はそのプロセスから以下の情報にアクセスできる可能性があります。

・全プロセスリスト: /proc以下を参照してSSHデーモンやデータベースのプロセス情報が丸見えになる
・ネットワーク情報: 内部ネットワーク構成・接続先データベースのアドレスが把握できる
・ファイルシステム: 権限が許す範囲のファイル（設定ファイル・秘密鍵など）にアクセス可能

名前空間で分離すると、侵害されたプロセスは「自分の名前空間内」しか見えなくなります。たとえばPID Namespaceで分離されたプロセスは、ホスト側のプロセスをまったく認識できません。攻撃者が情報収集できる範囲が大幅に狭まるため、権限昇格やラテラルムーブメントへの踏み台として使われにくくなります。

各Namespaceの仕組みと実践設定

1. PID Namespaceの活用

PID Namespaceを使うと、そのプロセスから見えるプロセスツリーを完全に切り離せます。unshareコマンドで試せます。

# PID Namespaceを新規作成してbashを起動
# --pid: 新しいPID Namespaceを作成
# --fork: 子プロセスをforkして実行
# --mount-proc: /procを新しい名前空間にマウント（psが機能するために必要）
$ sudo unshare --pid --fork --mount-proc bash

# 新しい名前空間内で確認
# psで見えるのはこのbashとpsのみ（ホスト全体のプロセスは見えない）
$ ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  26772  5444 pts/0    S    10:00   0:00 bash
root        12  0.0  0.0  48132  3504 pts/0    R+   10:00   0:00 ps aux

名前空間内ではPID 1がbashになっており、ホストの全プロセスが見えなくなっています。現在の名前空間IDはls -la /proc/self/ns/pidで確認できます。

2. Network Namespaceの活用

Network Namespaceは、ネットワークを完全に分離するために使います。ip netnsコマンドで管理します。

# 新しいNetwork Namespaceを作成
$ sudo ip netns add secure-ns

# 名前空間内でコマンドを実行
$ sudo ip netns exec secure-ns ip link show
1: lo:  mtu 65536 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
# loopbackしか見えない（ホストのeth0等は見えない）

# 名前空間内でプロセスを起動（ネットワーク分離されたまま実行）
$ sudo ip netns exec secure-ns /usr/bin/myapp

# 作成した名前空間の一覧確認
$ ip netns list
secure-ns

# 名前空間の削除
$ sudo ip netns del secure-ns

分離されたNetwork Namespace内のプロセスは、ホストのネットワークインターフェースにアクセスできません。内部ネットワークスキャンやデータ持ち出しを困難にします。外部ネットワークへのアクセスが必要な場合は、veth（仮想Ethernetペア）を使って必要な通信だけを許可する設計にします。

3. Mount Namespaceの活用

Mount Namespaceを使うと、プロセスから見えるファイルシステムを制限できます。chrootジェイルと似ていますが、chrootより安全性が高く、/procなどシステムディレクトリも独立して制御できます。

# Mount Namespaceを新規作成して実行
# --mount: 新しいMount Namespaceを作成
# --propagation=private: マウント伝播を無効化（ホストに影響させない）
$ sudo unshare --mount --propagation=private bash

# 名前空間内でマウントを追加してもホストには影響しない
$ mount -t tmpfs tmpfs /tmp/test_mount
$ findmnt | grep test_mount
└─/tmp/test_mount  tmpfs  tmpfs  rw,relatime

# ホスト側（別ターミナル）では確認できない
# $ findmnt | grep test_mount  → 何も表示されない

この仕組みを応用すると、プロセスに「読み取り専用の/etc」「書き込み禁止のシステムディレクトリ」を見せることができ、設定ファイルの改ざんを防げます。

4. User Namespaceの活用

User Namespaceは最も強力かつ慎重に扱う必要があるNamespaceです。名前空間内でUID 0（root）にマッピングできますが、ホスト側では一般ユーザーのまま動作します。これにより、rootなしでコンテナを起動する「rootlessコンテナ」が実現されています。

# rootなし（一般ユーザー）でUser Namespaceを作成
$ unshare --user --map-root-user bash

# 名前空間内ではrootに見える
$ id
uid=0(root) gid=0(root) groups=0(root),65534(nogroup)

# しかしホスト側では元のUID（例: 1000）のまま
# ホストのrootファイルは読み書きできない
$ cat /etc/shadow
cat: /etc/shadow: Permission denied

User Namespaceは強力ですが、カーネルの権限制御バイパスに悪用された事例もあります。本番環境ではcapabilities（ケーパビリティ）と組み合わせて、使用できる範囲を必要最小限に制限することが推奨されます。

systemdサービスへのNamespace適用（最も実用的な方法）

個別のプロセスに名前空間を適用する最も実用的な方法は、systemdのサンドボックス設定を利用することです。ユニットファイルに数行追加するだけで適用できます。

# /etc/systemd/system/myapp.service（抜粋）
[Service]
ExecStart=/usr/bin/myapp

# 専用の/tmpを割り当て（他プロセスの/tmpが見えない）
PrivateTmp=yes

# /home・/rootを読み取り不可にする
ProtectHome=yes

# /usr・/boot・/etcを読み取り専用にする（strictは書き込み禁止）
ProtectSystem=strict

# ネットワーク完全分離（ネットワーク不要なサービス向け）
PrivateNetwork=yes

# 自分のUID/GIDしか見えなくする（User Namespace相当）
PrivateUsers=yes

# 利用できるNamespaceの種類を制限する（~は「以外を許可」の意味）
# pid net mnt user は作成を制限
RestrictNamespaces=~pid net mnt user

設定変更後はデーモンを再読み込みしてサービスを再起動します。

$ sudo systemctl daemon-reload
$ sudo systemctl restart myapp

# サービスのセキュリティスコアを確認（高いほど安全）
$ sudo systemd-analyze security myapp

systemd-analyze securityを実行すると、現在の設定でのセキュリティスコアと改善が必要な項目が一覧表示されます。まずスコアを確認してから、低評価の項目を一つずつ対応していくアプローチが現実的です。

Namespaceと他のLinuxセキュリティ機能との組み合わせ

名前空間は単独でも有効ですが、他のLinuxセキュリティ機能と組み合わせることで防御が大幅に強化されます。

cgroups + Namespace + seccomp + capabilitiesは、Dockerをはじめとするコンテナランタイムが組み合わせて使用している技術セットそのものです。Dockerコンテナのセキュリティ強化と合わせて理解しておくと、コンテナ環境でも自信を持って設計・運用できます。

中小企業でも今日からできること

名前空間を本格的に活用するには学習コストが必要ですが、取り組みやすいステップから始めることができます。

・systemd設定から始める: PrivateTmp=yes・ProtectSystem=strictをWebサーバー（nginx/Apache）のユニットファイルに追加するだけで、/tmpの分離とシステムディレクトリの書き込み禁止が実現できます
・systemd-analyze securityでスコアを把握する: 既存サービスのセキュリティスコアを確認してから改善箇所を特定しましょう。スコアの数値が低いほど安全性が高い表示になっています
・外部公開サービスから優先して適用: Webサーバー・メールサーバーなど外部からアクセスされるサービスを優先して隔離します
・テスト環境で検証してから本番適用: ProtectHome=yesなどは設定次第でサービスが起動しなくなる場合があります。必ず検証環境で試してから本番に適用しましょう

Linuxコマンドや設定ファイルの書き方についての基礎知識は、姉妹サイトLinuxMaster.JPのLinux基礎解説記事もあわせてご活用ください。

よくある誤解と注意点

【誤解】名前空間だけで完全にセキュリティを確保できる

名前空間はあくまで「見えるものを制限する」技術です。コンテナエスケープの例にあるように、カーネル脆弱性やmisconfigurationがあれば名前空間を越えて侵害が広がる可能性があります。seccomp・capabilities・適切なcgroupsと組み合わせることで初めて実効性のある多層防御になります。

【注意】User Namespaceの開放は慎重に

一般ユーザーへのUser Namespace作成を許可する設定（kernel.unprivileged_userns_clone=1）は、非rootユーザーがroot相当の操作をできる範囲を広げます。不要であれば制限を検討してください。

# User Namespaceの一般ユーザーへの開放を制限する（Ubuntu/Debian系）
$ sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=1

# 永続化: /etc/sysctl.d/99-namespace-security.conf に追記
kernel.apparmor_restrict_unprivileged_userns=1

# RHEL/AlmaLinux/Rocky Linux系はデフォルトで制限済み
# 確認コマンド
$ sysctl user.max_user_namespaces

【注意】RestrictNamespacesの設定ミスによるサービス停止

systemdのRestrictNamespaces=で過剰に制限すると、サービスが使用する名前空間機能（Dockerはほぼ全種類使う）が動作しなくなります。変更前にログを監視しながら段階的に適用しましょう。journalctl -fu myappでエラーをリアルタイム確認しながら設定を進めると安全です。

【注意】名前空間はカーネルパッチで維持する

名前空間の実装はLinuxカーネルに依存しています。カーネル脆弱性（特に特権昇格系）は名前空間の分離を突破する経路になりえます。名前空間を活用するサーバーでも、カーネルの定期的なアップデートは欠かさず行うことが前提条件です。

本記事のまとめ

Linuxの名前空間（Namespace）は、プロセスが見えるリソースの範囲を切り分けることで、侵害された際の被害範囲を最小化する強力な仕組みです。

まずはsystemdのPrivateTmp=yesやProtectSystem=strictから導入を始め、systemd-analyze securityでスコアを確認しながら段階的に適用範囲を広げていくことが実践的なアプローチです。名前空間単体ではなく、cgroups・seccomp・capabilitiesと組み合わせることで、真の意味での多層防御が実現します。