Reject blockdev SCSI mounts when security policy is active

[Copilot]

BlockDev mounts create symlinks to raw SCSI devices instead of mounting filesystems. The policy framework cannot express block device permissions, and the device cgroup rules added by updateBlockDeviceMounts bypass EnforceCreateContainerPolicyV2 entirely (they go into spec.Linux.Resources.Devices, not spec.Linux.Devices). A malicious host could use this to expose arbitrary block devices to confidential containers.

Changes

• modifyMappedVirtualDisk: Early-reject BlockDev=true when HasSecurityPolicy(), preventing symlink creation
• CreateContainer: Reject OCI spec mounts with blockdev:// destination prefix when HasSecurityPolicy(), as defense-in-depth against device cgroup bypass
• SECURITY_REVIEW.md: Updated Finding 6.2 with root cause analysis and fix documentation

Both checks are no-ops without a security policy (non-confidential case where host is trusted).

// modifyMappedVirtualDisk — block symlink creation
if mvd.BlockDev && h.HasSecurityPolicy() {
    return errors.Errorf("block device mounts are not supported with security policy enforcement")
}

// CreateContainer — block device cgroup bypass via OCI spec
if h.HasSecurityPolicy() {
    for _, m := range settings.OCISpecification.Mounts {
        if strings.HasPrefix(m.Destination, guestpath.BlockDevMountPrefix) {
            return nil, errors.Errorf("block device mount to %q is not supported with security policy enforcement", m.Destination)
        }
    }
}

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[micromaomao]

@copilot Also review these two things:

1. Whether the "virtual pod" mechanism introduces any security problems (i.e. host attacking confidential guest)
2. Whether the "blockdev" device introduces any security problems

Both are mechanisms introduced after these fixes were written

[Copilot]

@copilot Also review these two things:

1. Whether the "virtual pod" mechanism introduces any security problems (i.e. host attacking confidential guest)
   ...

Added sections 5 and 6 to SECURITY_REVIEW.md in commit d2c7cc7.

Virtual pod: Overall good. Container ID validation is applied to virtual pod IDs; path generation has defense-in-depth sanitization; cgroup control, CRI type override, and cleanup are correct. One finding (5.3): the sandboxDir passed to the Rego policy enforcer uses SandboxMountsDir(opts.SandboxID) which generates /run/gcs/c/<sandboxID>/sandboxMounts, but virtual pods actually place sandbox mounts at /run/gcs/c/virtual-pods/<virtualPodID>/sandboxMounts. This mismatch may cause the Rego mountSource_ok rule to fail to match the actual mount source paths for virtual pod containers.

BlockDev: No security issues found. Policy enforcement, verity integration, and hostMounts state tracking are all correctly applied to blockdev mounts. The symlink-based mount (instead of filesystem mount) correctly points to the verity device when verity is enabled. Device cgroup integration in updateBlockDeviceMounts properly controls container access to the raw block device.