Candidate Control Admission Boundaries Source Limits

Candidate Control-Admission Boundaries: Source Limits

The Oracle 7.1 component documentation describes local clients of a particular VBoxSVC process as running under the same host account. This is an architectural description, not proof that other principals or all control paths are excluded. The deployed release, host identities, endpoints, and effective permissions have not been checked. The following are unselected candidates or shortcuts, not proven controls.

Candidate or shortcut	Documented building block	Limit and required proof
Cooperative UUID file lock	Linux flock(2) normally provides advisory locking; remote filesystems can have different semantics. Locks follow open file descriptions and can remain held by duplicated or inherited descriptors.	A process that does not take the lock can bypass that cooperation. Coordinator exit or lock release does not establish that an already accepted VM command stopped; descriptor inheritance and terminal recovery need separate proof.
Separate configuration or web service	Oracle documents VBOX_USER_HOME configuration selection; the 7.1.12 SDK describes both the web service and direct COM/XPCOM access.	Selecting a configuration directory is not a documented exclusive-control fence. Disabling or authenticating the web service alone does not prevent local Main API clients.
Linux identity, broker, and endpoint permissions	Linux pathname permissions and Unix sockets provide possible building blocks.	DAC alone does not distinguish processes with the same filesystem identity; CAP_DAC_OVERRIDE can bypass file permission checks, and abstract sockets do not use pathname permissions. The actual VirtualBox transports, other access paths, process identities, and effectiveness of any additional enforcement are unverified.
Windows COM access control	Microsoft documents COM registry access permissions and process-wide security configuration.	A registry ACL is not by itself proof of effective policy: an application can set process-wide security through CoInitializeSecurity. The installed VBoxSVC registration, effective policy, alternate routes, and same-identity clients are unverified.

Any proposed boundary must identify the verified VM, all relevant control and storage paths, and the participating identities, including whether same-identity clients and privileged host principals are in scope. It must demonstrate that in-scope bypasses are denied or coordinated throughout the protected interval, and independently reconcile operations accepted before the boundary took effect. Excluding future clients does not drain an old asynchronous command. Actor and host-compromise boundaries remain operator decisions; absent a proven applicable boundary, dependent mutation remains UNKNOWN. Investigating or changing actual host permissions, identities, or services requires separate authorization.