Overview
Executive summary
An enterprise organization deploying Chromebooks under ChromeOS Enterprise Upgrade needed to enable the Linux development environment (Crostini) for technical teams and students. Despite enabling the standard virtualization setting (CrostiniAllowed), end-users were still blocked from opening the Terminal app. Through policy analysis, Core5 identified a root-cause conflict — an explicit internal system-URL block rule was overriding virtualization policies and silently killing the Terminal — then diagnosed, fixed and deployed Linux containers across the managed fleet.
The challenge
What they were up against
- Users in target Organizational Units (OUs) needed command-line access for software development, but launching the Terminal app hit an enterprise policy block screen.
- The Linux setup process failed to initialize properly.
- chrome://policy confirmed virtualization was enabled, yet the interface required to launch the container was blocked.
- Root cause: although CrostiniAllowed was true, chrome-untrusted://terminal was present in the URLBlocklist — and in ChromeOS, explicit blocklist entries override broad allowlists, silently killing the Terminal.
Our solution
How Core5 approached it
- In the Google Admin Console (Devices ➔ Chrome ➔ Settings ➔ Users & browsers) for the target LDAP-synced OU, removed chrome-untrusted://terminal from the URL blocklist.
- Added explicit URL allowlist entries: chrome://terminal, chrome://terminal/*, chrome-untrusted://terminal and chrome-untrusted://terminal/*.
- On the managed Chromebooks, reloaded policies at chrome://policy and verified the terminal scheme was no longer blocked.
- Enabled the Linux development environment (Settings ➔ Developers ➔ Turn on) and validated the container by updating packages (sudo apt update && sudo apt upgrade -y).
- Scoped every change to specific LDAP-mapped OUs so security restrictions for regular enterprise users stayed intact.
Technologies
Technologies used
Results

