セキュリティーについて¶

Incusのインストールが安全であることを保証するために、以下の点を考慮してください。

OSを最新に保ち、利用可能なすべてのセキュリティパッチをインストールしてください。
サポートされているIncusのバージョンのみを使用してください。
IncusデーモンとリモートAPIへのアクセスを制限してください。
必要とされない限り、特権コンテナを使わないでください。特権的なコンテナを使う場合は、適切なセキュリティ対策をしてください。詳細はLXCセキュリティページを参照してください。
ネットワークインタフェースを安全に設定してください。

詳細な情報は以下のセクションを参照してください。

セキュリティー上の問題を発見した場合、その問題の報告方法については Incus のセキュリティーポリシー（原文: Incus security policy）を参照してください。

サポートされているバージョン¶

サポートされていないバージョンの Incus は実運用環境では絶対に使用しないでください。

Incus には 2 種類のリリースがあります:

機能リリース
LTS （長期サポート）リリース

機能リリースは、最新の 1 つのみがサポートされ、通常ポイントリリースは行いません。代わりにユーザーは次のリリースを待つことが期待されます。

長期リリースは、機能リリースからの積み重なったバグ修正を含む定期的なバグ修正リリースを行います。このバグ修正リリースは新機能は含みません。

Incus デーモンへのアクセス¶

Incus は Unix ソケットを介してローカルにアクセスできるデーモンで、設定されていればTLSソケットを介してリモートにアクセスすることもできます。ソケットにアクセスできる人は、ホストデバイスやファイルシステムをアタッチしたり、すべてのインスタンスのセキュリティー機能をいじったりするなど、Incus を完全に制御することができます。

したがって、デーモンへのアクセスを信頼できるユーザーに制限するようにしてください。

Incus デーモンへのローカルアクセス¶

Incus デーモンは root で動作し、ローカル通信用の Unix ソケットを提供します。 Incus のアクセス制御は、グループメンバーシップに基づいて行われます。 root ユーザーと incus-admin グループのすべてのメンバーがローカルデーモンと対話できます。

重要

UNIXソケットを介したIncusへのローカルアクセスは、常にIncusへのフルアクセスを許可します。これは、任意のインスタンス上のセキュリティ機能を変更できる能力に加えて、任意のインスタンスにファイルシステムパスやデバイスをアタッチする能力を含みます。

したがって、あなたのシステムへのルートアクセスを信頼できるユーザーにのみ、このようなアクセスを与えるべきです。

リモート API へのアクセス¶

デフォルトでは、デーモンへのアクセスはローカルでのみ可能です。 core.https_addressという設定オプションを設定することで、同じ API をTLSソケットでネットワーク上に公開することができます。手順は Incusをネットワークに公開するにはを参照してください。リモートクライアントは、Incus に接続して、公開用にマークされたイメージにアクセスできます。

リモートクライアントが API にアクセスできるように、信頼できるクライアントとして認証する方法がいくつかあります。詳細はリモートAPI認証を参照してください。

本番環境では、core.https_addressに、（ホスト上の任意のアドレスではなく）サーバーが利用可能な単一のアドレスを設定する必要があります。さらに、許可されたホスト/サブネットからのみ Incus ポートへのアクセスを許可するファイアウォールルールを設定する必要があります。

コンテナのセキュリティー¶

Incus コンテナはセキュリティーのために幅広い機能を使うことができます。

デフォルトでは、コンテナは 非特権（unprivileged）であり、ユーザーNamespace 内で動作することを意味し、コンテナ内のユーザーの能力を、コンテナが所有するデバイスに対する制限された権限を持つホスト上の通常のユーザーに制限します。

コンテナ間のデータ共有が必要ない場合は、security.idmap.isolatedを有効にすることで、各コンテナに対して重複しない UID/GID マップを使用し、他のコンテナに対する潜在的なDoS攻撃を防ぐことができます。

Incus はまた、特権（privileged）コンテナを実行することができます。しかし、これは（訳注:コンテナ内だけで）安全に root 権限を使えるわけではなく、そのようなコンテナの中でルートアクセスを持つユーザーは、閉じ込められた状態から逃れる方法を見つけるだけでなく、ホストを DoS することができてしまう点に注意してください。

コンテナのセキュリティーと私たちが使っているカーネルの機能についてのより詳細な情報は LXCセキュリティページにあります。

コンテナ名の漏洩¶

デフォルトの設定ではシステム上のすべての cgroup と、さらに転じて、すべての実行中のコンテナを一覧表示することが簡単にできてしまいます。

コンテナを開始する前に /sys/kernel/slab と /proc/sched_debug へのアクセスをブロックすることでコンテナ名の漏洩を防げます。このためには以下のコマンドを実行してください:

chmod 400 /proc/sched_debug
chmod 700 /sys/kernel/slab/

ネットワークセキュリティー¶

ネットワークインターフェースは必ず安全に設定してください。どのような点を考慮すべきかは、使用するネットワークモードによって異なります。

ブリッジ型NICのセキュリティー¶

Incus のデフォルトのネットワークモードは、各インスタンスが接続する「管理された」プライベートネットワークのブリッジを提供することです。このモードでは、ホスト上にincusbr0というインターフェースがあり、それがインスタンスのブリッジとして機能します。

ホストは、管理されたブリッジごとにdnsmasqのインスタンスを実行し、IP アドレスの割り当てと、権威 DNS および再帰 DNS サービスの提供を担当します。

DHCPv4 を使用しているインスタンスには、IPv4 アドレスが割り当てられ、インスタンス名の DNS レコードが作成されます。これにより、インスタンスが DHCP リクエストに偽のホスト名情報を提供して、DNS レコードを偽装することができなくなります。

dnsmasqサービスは、IPv6 のルータ広告機能も提供します。つまり、インスタンスは SLAAC を使って自分の IPv6 アドレスを自動設定するので、dnsmasqによる割り当ては行われません。しかし、DHCPv4 を使用しているインスタンスは、SLAAC IPv6 アドレスに相当する AAAA の DNS レコードも取得します。これは、インスタンスが IPv6 アドレスを生成する際に、IPv6 プライバシー拡張を使用していないことを前提としています。

このデフォルト構成では、DNS 名を偽装することはできませんが、インスタンスはイーサネットブリッジに接続されており、希望するレイヤー2 トラフィックを送信することができます。これは、信頼されていないインスタンスがブリッジ上で MAC または IP の偽装を効果的に行うことができることを意味します。

デフォルトの設定では、ブリッジに接続されたインスタンスがブリッジに（潜在的に悪意のある）IPv6 ルータ広告を送信することで、Incus ホストの IPv6 ルーティングテーブルを修正することも可能です。これは、incusbr0インターフェースが/proc/sys/net/ipv6/conf/incusbr0/accept_raを2に設定して作成されているためで、forwardingが有効であるにもかかわらず、Incus ホストがルーター広告を受け入れることを意味しています（詳細は/proc/sys/net/ipv4/* Variablesを参照してください）。

しかし、Incus はいくつかのブリッジ型NICセキュリティー機能を提供しており、インスタンスがネットワーク上に送信することを許可されるトラフィックの種類を制御するために使用することができます。これらの NIC 設定は、インスタンスが使用しているプロファイルに追加する必要がありますが、以下のように個々のインスタンスに追加することもできます。

ブリッジ型 NIC には、以下のようなセキュリティー機能があります:

キー	タイプ	デフォルト	必須	説明
`security.mac_filtering`	bool	`false`	no	インスタンスが他のインスタンスの MAC アドレスを詐称することを防ぐ。
`security.ipv4_filtering`	bool	`false`	no	インスタンスが他のインスタンスの IPv4 アドレスになりすますことを防ぎます(`mac_filtering` を有効にします)。
`security.ipv6_filtering`	bool	`false`	no	インスタンスが他のインスタンスの IPv6 アドレスになりすますことを防ぎます(`mac_filtering` を有効にします)。

プロファイルで設定されたデフォルトのブリッジ型 NIC の設定は、インスタンスごとに以下の方法で上書きすることができます:

incus config device override <instance> <NIC> security.mac_filtering=true

これらの機能を併用することで、ブリッジに接続されているインスタンスが MAC アドレスや IP アドレスを詐称することを防ぐことができます。これらのオプションはnftablesを使用して実装されます。

これらのオプションは、ネストされたコンテナが異なる MAC アドレスを持つ親ネットワークを使用すること（ブリッジされた NIC やmacvlan NIC を使用すること）を効果的に防止することができるのは注目に値します。

IP フィルタリング機能は、スプーフィングされた IP を含む ARP および NDP アドバタイジングをブロックし、スプーフィングされたソースアドレスを含むすべてのパケットをブロックします。

security.ipv4_filteringまたはsecurity.ipv6_filteringが有効で、（ipvX.address=noneまたはブリッジで DHCP サービスが有効になっていないため）インスタンスに IP アドレスが割り当てられない場合、そのプロトコルのすべての IP トラフィックがインスタンスからブロックされます。

security.ipv6_filtering が有効な場合、IPv6 のルータ広告がインスタンスからブロックされます。

security.ipv4_filteringまたはsecurity.ipv6_filteringが有効な場合、ARP、IPv4 または IPv6 ではないイーサネットフレームはすべてドロップされます。これにより、スタックされた VLAN Q-in-Q（802.1ad）フレームが IP フィルタリングをバイパスすることを防ぎます。

ルート化されたNICのセキュリティー¶

"routed" と呼ばれる別のネットワークモードがあります。このモードでは、コンテナとホストの間に仮想イーサネットデバイペアを提供します。このネットワークモードでは、Incus ホストがルータとして機能し、コンテナの IP 宛のトラフィックをコンテナのvethインターフェースに誘導するスタティックルートがホストに追加されます。

デフォルトでは、コンテナからのルータ広告が Incus ホスト上の IPv6 ルーティングテーブルを変更するのを防ぐために、ホスト上に作成されたvethインターフェースは、そのaccept_ra設定が無効になっています。それに加えて、コンテナが持っていることをホストが知らない IP に対するソースアドレスの偽装を防ぐために、ホスト上のrp_filterが1に設定されています。