【後編】Sandbox による ESXi の保護: Daemon Sandboxing in ESXi 8.0

Dec 8, 2022 vSphere ESXi Security

本記事は vExperts Advent Calendar 2022 の８日目の担当です。

はじめに

前編では VM Sandboxing を見ていきました。後編では ESXi 8.0 の Daemon Sandboxing を見ていきます。

Daemon Sandboxing

vSphere 8 では仮想マシンだけでなく ESXi 上の各種プロセスも Sandbox ドメイン内で実行させるようになっており、最小限の権限のみをプロセスに付与することでセキュリティを高めています。

Sandboxed Daemons: ESXi 8.0 daemons and processes run in their own sandboxed domain where only the minimum required permissions are available to the process.

以前のバージョンでは hostd や vpxd などのプロセスは特権レベルのドメイン(superDom)が割り当てられていましたが、vSphere 8 ではこれらのプロセスにも独立したドメインが割り当てられています。

個々のプロセスのドメインを見てみる

前編と同様、まずは ps コマンドで ESXi 8.0 におけるプロセスのドメインを見てみます。

1# ps -TcjstvZ
2WID       CID       WorldName                                               GID      Type    State   Wait    CPU   Time          SecurityDomain  Command
31050481   1050481  hostd                                                   1050481  User    WAIT    UFUTEX  0-11     77.974625  49※            hostd
41050498   1050481  hostd-worker                                            1050481  User,Clone    WAIT    UFUTEX  0-11      3.76023   49※            hostd
5
61050860   1050860  vpxa                                                    1050860  User    WAIT    UFUTEX  0-11      0.493178  103※           /usr/lib/vmware/vpxa/bin/vpxa -D /etc/vmware/vpxa
71050919   1050860  vpxa-worker                                             1050860  User,Clone    WAIT    UFUTEX  0-11      0.220     103※           /usr/lib/vmware/vpxa/bin/vpxa -D /etc/vmware/vpxa

以前のバージョンではこれらのプロセスのドメイン ID は 0 (superDom) でした。しかし、ESXi 8.0 ではプロセスごとに異なるドメイン ID が割り当てられていることが確認できます。

secpolicytools コマンドでドメインの一覧を見てみると、各プロセスごとにドメインが用意されていることが確認できます。ドメインの数も非常に増えています。

 1# secpolicytools -d | grep Domain
 2Domain Name: superDom Domain ID :0 Enforcement Level: enforcing
 3  ...
 4Domain Name: hostdDom Domain ID :49 Enforcement Level: enforcing
 5  ...
 6Domain Name: vpxaDom Domain ID :103 Enforcement Level: enforcing
 7  ...
 8
 9# secpolicytools -d | grep Domain | wc -l
10116

ESXi 6.5 - 7.0 では仮想マシンのプロセスのみ独立したドメインが割り当てられていましたが、ESXi 8.0 では独立したドメインの割り当てがシステムのプロセスまで拡張されていることが分かります。

どのように役立つのか？

VM Sandboxing では VMX 等の仮想マシンプロセスが可能な操作を個々の Sandbox ドメインをもとに制限することで、悪意のあるユーザーが脆弱性を突いて仮想マシンプロセスを乗っ取った場合の影響範囲を絞っていました。

Daemon Sandboxing も同様に、個々の Sandbox のドメインをもとにして hostd や vpxa が可能な操作が制御されるため、仮に脆弱性への攻撃によりこれらのプロセスが乗っ取られた場合でも影響範囲を絞れます。

もちろん VMSA-2022-0004 のように、将来的に Sandbox をバイパスする脆弱性が見つからないとは言い切れませんが、それでも Sandbox が無いよりは遥かにセキュアになっていると思います。

ESXi Shell と SSH はデフォルトでは対象外

ESXi 8.0 でも、ESXi Shell と SSH はデフォルトで特権レベルのドメイン(superDom)で実行されます。これは従来と同様です。

ただし、ホストの詳細設定 /UserVars/ShellSandboxEnabled を有効にすることで、ESXi Shell と SSH に関しても個別のドメインで実行させることが可能となります。

SSH Daemon Sandboxing VOB in vSphere 8.0 release (87386)

SSH and ESXi Shell today run in superDom by default. With vSphere 8.0 release, this will stay the same, but there is an option to enable shell sandbox using the following steps:

esxcfg-advcfg -s 1 /UserVars/ShellSandboxEnabled

/etc/init.d/SSH restart (for restarting SSH)

/etc/init.d/ESXShell restart (for restarting ESXShell)

上述の手順でシェルの Sandbox を有効にした場合、esxtop や vm-support などを除きシェル上でのほとんどの操作が禁止されます。

When enabled, any subsequent shell spawned through SSH (and local ESXi shell) will have reduced privileges. Most operations on shell will stop working. The only recommended use-case of sandboxed shell is to run the following commands:

esxtop <args>

support-util vm-support <args>

Any other command is not advisable to run.

なお、この状態でも supershell -c “<cmd>” で任意のコマンドが実行可能ですが、vobd.log 上にイベント(esx.audit.supershell.access)が記録されます。

Symptoms
The following vSphere warning is observed on an ESXi host when a user logs in to it via SSH/ESXShell and runs supershell command in a sandboxed shell:

# esx.audit.supershell.access
“Supershell session has been started by a user.”

なお、前提として ESXi Shell や SSH はトラブルシューティングを目的とした機能のため、通常運用時は無効にしておくことが強く推奨されます。また、仮にシェルの Sandbox を有効にした場合でも supershell コマンドはみだりに使うべきではありません。

Do not enable SSH on the hosts unless there is a troubleshooting use-case. While accessing hosts via SSH or ESXi Shell where shell sandbox is enabled, supershell should not be used unless absolutely necessary.

ESXi Shell や SSH でのトラブルシューティング中に不正アクセスの発生が懸念される場合はユースケースの一つとして考えられます。ただし、あくまでも Sandbox はホストの侵害後に影響範囲を狭めるための最後の砦です。シェルの Sandbox を有効にする前に、まずはホストやネットワークのセキュリティが適切に維持されているか、運用上の問題がないかを十分に確認しましょう。

ドメインの Enforcement Level

ドメインには enforcing, warning, disabled の3つの Enforcement Level があり、デフォルトは enforcing となっています。

Domain enforcement change warnings observed on ESXi Host (87510)

With vSphere 8.0 release, most daemons running on ESXi will have their custom security domain with required access privileges defined. Domains on ESXi have 3 kinds of enforcement levels:

“enforcing”: Any resource not defined in the domain definition will be denied.

“warning”: A resource not defined in the domain definition will be granted, but the event will be logged in vmkernel log.

“disabled”: A resource not defined in the domain definition will be granted, and the event will not be logged in vmkernel log.

It is recommended to keep the enforcement level of all domains as “enforcing”. Changing the enforcement level of a domain puts the host at a security risk.

warning や disabled に変更するとドメインに定義されていないリソースへのアクセスも許可される(warning だと vmkernel.log に記録される)ようになります。しかし、セキュリティリスクとなるため Enforcement Level は enforcing のまま維持することが強く推奨されます¹。

It is highly recommended to keep the enforcement level of all the domains to “enforcing”, except for a scenario where a domain is missing some privilege required by a daemon.

おわりに

今回は前編と後編に記事を分けて、ESXi 6.5 の VM Sandboxing と ESXi 8.0 の Daemon Sandboxing の概要、Sandbox により ESXi がどのように保護されるかを見ていきました。

色々と調べた結果として、通常の vSphere の運用で Sandbox の動作までを意識することはほぼゼロに近いと言っても過言ではないと思います。ただし、KB1037405 や KB2129825 のようなコーナーケースではトラブルシューティング Sandbox が関わってくる可能性があるため、もしかしたら頭の片隅に置いておくといつか役に立つこともあるかもしれません。

また、将来 VMSA-2022-0004 のように Sandbox をバイパスする脆弱性が発見される可能性もあります。この場合は一般の脆弱性と同様に、修正パッチがリリースされたら早急に適用しましょう。

変更手順に関するVMware社の公開情報も見当たりませんでした。 ↩︎