macOS - Software - Install Oracle VirtualBox

What the Oracle VirtualBox deployer does

This Automox Worklet™ deploys Oracle VirtualBox to macOS endpoints by pulling the official DMG directly from download.virtualbox.org and running the bundled installer package. The Worklet first calls /usr/bin/arch to read the processor architecture, then chooses between the Intel (x86_64) stable build and the Apple Silicon (arm64) beta build. A single policy can therefore target a mixed Intel and Apple Silicon fleet without separate per-architecture worklets or per-host scripting.

Oracle VirtualBox is a no-cost, open-source Type 2 hypervisor used to run Windows, Linux, and BSD guests on macOS hosts. Common deployment cases include cross-platform application QA, malware analysis sandboxes, training environments, and developer setups that need a local Linux VM next to macOS. The Worklet leaves an installed copy of VirtualBox at /Applications/VirtualBox.app and a supporting tree under /Library/Application Support/VirtualBox, which is where the Oracle kernel extensions and helper binaries register with the system.

Because the Worklet is FixNow-compatible, you can run it on demand against a single endpoint when an engineer files a ticket for VirtualBox, or schedule it as a recurring policy against a workstation group so that newly imaged Macs receive the hypervisor on first check-in.

Why deploy Oracle VirtualBox from a managed runtime

Engineering, QA, and security teams often need a local hypervisor on macOS to reproduce a Windows-only bug, detonate a suspect binary in an isolated guest, or test a Linux build chain without a remote VM. When VirtualBox is installed by hand on each laptop, the fleet drifts quickly. One developer may be on 6.1, another on 7.0.8, and a third may never have installed the macOS kernel extension and cannot start a VM. Patch advisories from Oracle land against specific point releases, so an unknown VirtualBox version on the laptop produces an unknown scope of exposure.

Apply this Worklet to the macOS developer device group on a single policy schedule so VirtualBox.pkg lands a known build on every endpoint at the same time. The version your security team patches next week is the same version on every developer's Mac today.

How the VirtualBox DMG install works

1. Evaluation phase: The Worklet checks for the directory /Applications/VirtualBox.app. If the app bundle is present, evaluation exits 0 and the endpoint is reported compliant. If the bundle is missing, evaluation exits 1 and the Automox agent schedules the remediation script.

2. Remediation phase: The script calls /usr/bin/arch to read the host architecture. On arm64, it downloads VirtualBox-7.0.8_BETA4-156879-macOSArm64.dmg from download.virtualbox.org to /var/tmp/oracle_virtualbox.dmg using curl -L. On x86_64, it pulls VirtualBox-7.0.8-156879-OSX.dmg to the same path. Any other architecture exits 1 with a not-supported message. The script then runs hdiutil attach on the DMG, executes installer -pkg /Volumes/VirtualBox/VirtualBox.pkg -target /Volumes/Macintosh\ HD, runs hdiutil detach /Volumes/VirtualBox, removes the cached DMG, and re-checks /Applications/VirtualBox.app before exiting 0 on success or 1 on failure.

Oracle VirtualBox deployment requirements

• macOS 10.15 Catalina or later on Intel (x86_64) or Apple Silicon (arm64) hardware

• Root context for the Automox agent so the installer can write to /Applications and /Library/Application Support/VirtualBox (the default agent context already meets this)

• Outbound HTTPS reachability from the endpoint to download.virtualbox.org

• Write access to /var/tmp for the cached DMG (the script removes it after install)

• End user approval of the Oracle system extension in System Settings, Privacy and Security after first install, or an MDM kernel extension policy that pre-approves TeamID VB5E2TV963

• Boot volume named Macintosh HD: the remediation passes -target /Volumes/Macintosh\ HD to installer, so endpoints whose system volume has been renamed will fail at the installer step until the script is edited

• Version awareness: the shipped script pins both the Intel (7.0.8) and Apple Silicon (7.0.8 BETA4) downloads to specific URLs. Oracle has since released later 7.0.x and 7.1.x builds, including a GA macOSArm64 build, so fork the Worklet and update the curl URLs before deploying broadly if you need a current version.

Expected state after Oracle VirtualBox deployment

After a successful remediation, /Applications/VirtualBox.app is present and launchable. The supporting tree under /Library/Application Support/VirtualBox holds the helper binaries and the bundled kernel extensions. The cached installer at /var/tmp/oracle_virtualbox.dmg is removed by the script, so no DMG residue is left on the endpoint. Subsequent evaluation runs short-circuit on the directory check and return exit 0 without re-downloading.

Validate the deployment from a terminal on the endpoint or from a follow-up Automox policy. Run /usr/libexec/PlistBuddy -c 'Print CFBundleShortVersionString' /Applications/VirtualBox.app/Contents/Info.plist to confirm the build, or /Applications/VirtualBox.app/Contents/MacOS/VBoxManage --version, which prints the VirtualBox version and revision (for example, 7.0.8r156879). systemextensionsctl list reports the Oracle system extension state once a user has approved it. If VBoxManage --version returns the binary but startvm fails with a kernel driver error, the Oracle system extension has not yet been approved in System Settings, under Privacy and Security; approve it once per endpoint, or pre-approve via MDM.

For audit evidence, capture the VBoxManage --version output and the Automox activity log entry showing exit code 0 for the remediation run. Pair this Worklet with the Uninstall Oracle VirtualBox Worklet when you need to revoke the hypervisor from a workstation group, and with the Windows VirtualBox installer when you have a mixed-OS developer fleet that needs the same hypervisor available on both platforms.