Important
Countdown to KV5 starts... now!
Tip
Like this repo? Star and share it with another chromeOS admin! 😄
Hola! Welcome to ChromeSEC. We know that system administrators constantly work within their organization on numerous projects and often do not have the time to hunt for forum posts, decipher Google documentation, or pay for support.
Because of this, we have created an always-changing, comprehensive guide to enable administrators to properly set up and secure their Chromebooks quickly.
We are an open-source project, so if you would like to make a change or add something feel free to open a pull request! You can also check out our acknowledgements page.
Kiosk apps are often used for testing, payment consoles, and helpdesk systems. This makes it extremely important to protect and configure them to prevent tampering or the ability to misuse them as filtering and monitoring extensions are usually inactive. Here is how you can properly setup your Kiosk programs to run in a safe and secure manner.
Enabling a domain whitelist inside a Kiosk application can prevent users from accessing unfiltered pages within the program. Using the Google Admin panel at Devices > Chrome > Settings > Device Settings > Kiosk Settings > URL Blocking you can either add blocked URLs to disable certain websites or set up a whitelist to only allow certain pages.
Tools like ChromeVOX and other accessibility features have the potential to bypass device policies by overlaying kiosk programs and enabling users to launch web pages. Because of this, administrators should consider managing or disabling certain accessibility features in kiosk programs.
In Devices > Chrome > Settings > Device Settings > Kiosk Settings, there is a section called Kiosk Accessibility Shortcuts. Admins should choose to disable these shortcuts. In the same section, there should be another option for the Kiosk floating accessibility menu. This should also be disabled.
To bypass Chrome and kiosk policy, users can disable wifi and put the system into a “limbo” state with the application and the Chrome browser. This also allows them to re-enable blocked accessibility features before using the kiosk program. Because of this, it is recommended to implement an organization policy to prevent changes in user network settings and the ability to disconnect from networks.
First, you should disable users' ability to access wifi settings in Devices > Chrome > Settings > Users & browsers > User Experience > and Disabled system features. Then just select OS Settings, or Wifi Settings to disable access. Now in Wifi Settings > Platform Access, choose Do not allow for both Chrome users and Chrome devices to use other networks. Then enable Automatically Connect to force devices to only connect to your network when they are in range.
ChromeOS was originally developed to allow user modification of the system. However, this could be damaging to enterprise environments, and it is often used to bypass policies and remove device enrollment. This makes it important to secure and manage access to these processes.
Chrome terminal and Crosh allow users to customise and change ChromeOS, but admins may want to limit access through the admin console for security purposes and to prevent damage to the device.
Admins should use GAC to enter Devices > Chrome > Settings > User & browser settings. You should then see a section called User Experience and then Disabled System Features. Add Crosh to disable access. Admins should also add /html/crosh.html into the URL blacklist to fully prevent access.
Chrome Flags, is a feature built-in on ChromeOS that gives users the option to enable experimental features on their chrome device. While this can be helpful in a nonenterprise environment, it’s important to properly manage flags to prevent end users from making the system unstable, and tampering with the device.
In Google Admin, you can go to Menu > Devices > Chrome > Settings and just add chrome://flags to the disabled features list. Users will then be unable to access the application.
Although developer mode will not be disabled by default on enterprise devices, the recovery screen can still be accessed using keyboard shortcuts. Due to an oversight, attempting to enable developer mode on enterprise machines would result in an automatic powerwash, even if this is prohibited by device policy. This mistake could lead to serious problems and may even result in the device being removed from enterprise enrollment due to a glitch on the signin menu.
While it is not possible to directly disable the recovery menu, admins can enable an option called Forced Re-enrollment, making it impossible to unenroll with the device after a powerwash. You can enable this by going to Devices > Chrome > Settings > Device Settings > Enrollment and Access. Then navigate down to Forced re-enrollment and check Force device to automatically re-enroll after wiping.
To provide extra protection against developer mode and firmware-level modification, admins can enable Verified Boot Mode. This blocks developer mode and prevents system startup unless recovered with a signed ChromeOS image.
Admins can go to Devices > Chrome > Settings > Device in the admin console and select the option for requiring verified mode boot for Verified Access.
Chrome extensions allow for new functionality on Chromebooks such as drive integrations, testing tools, and web filtering. However, unauthorized extensions in the webstore and from 3rd party sources can also pose security risks, privacy concerns, and can cause issues in device policy. Because of this, administrators should create restrictions on extension access and usage.
Allowing extensions from the Chrome Web Store could pose a security threat and allow for malicious programs to be installed. This poises a bigger threat on Chromebooks as most offices and schools do not have antivirus for Chrome devices. Because of this, it is generally best to lock extension access to a pre-approved list.
Admins should go to Devices > Chrome > Apps & extensions and in the ExtensionSettings policy set the mode to blocked to prevent users from installing their own extensions.
Many organizations want to have filtering and SSO extensions already installed on their computers. This can be done by configuring the admin console to automatically install these extensions and apps during device enrollment.
This option is available in Devices > Chrome > Apps & extensions or (depending on your GAC tier) in Chrome > Browser > Apps & Extensions. Next, choose the Users & browsers for who you want to install the extensions and input the application ID. Then just add the force install option for your chosen application.
Admins have the option to create an optional list of extensions users can install from the webstore. This could be used for programs that are only needed on some systems or for certain users. An allow list can be added by going to Devices > Chrome > Apps & Extensions and then selecting the Block all apps, admin manages allowlist option. Then go to the From the Chrome Web Store dropdown, and type in the IDs of the extensions you want to allow.
An existing exploit on ChromeOS nicknamed LTMEAT can be leveraged by users on any device to disable and bypass managed extensions. Fortunately, admins can take steps to prevent the exploit and its variations by implementing the following steps.
For the LTMEAT exploit to be leveraged, users need access to the chrome extensions menu, or an internal file within the extension package. To prevent this, admins can just go to Devices > Chrome > Settings > URL Blocking and add the following addresses to the blacklist:
chrome-extension://*
chrome://extensions
Users can access developer features through the Chrome extensions menu, which could affect security and web filtering. Because of this, administrators may want to disable these features from Google Admin.
If your devices run v127 or below, you need to disable DeveloperToolsAvailability by going to Devices > Chrome > Settings > User experience > Developer tools and clicking the disable dropdown. Admins with devices running v128 or above should navigate to the same menu section as shown in v127 but should instead choose to disable ExtensionDeveloperModeSettings.
As of May 31st, 2024, Google has launched extension manifest v3, unfortunately some extensions and developers still have not updated to adapt to this change. This may affect extensions giving 2fa and filtering services on all chromeOS devices. Because of this, admins should enable the manifest v2 compatibility as a precaution until developers finish updates.
To do this, admins need to navigate to Devices > Chrome > Settings > Users & browser settings and select Manifest V2 extension availability and enable it.
Keeping an organization’s data safe is very important. Google Admin provides a range of security features that help organizations protect their information and set up strong controls for users. All of these controls can be found under Devices > Chrome > Settings > Devices. Therefore, only a short description of each change and its effects will be added in the following sections.
Oftentimes when an enterprise device is lost or stolen, admins can set up instructions on the login screen to have the device returned. However, this can allow users to bypass locked mode and enter the signin menu. By disabling return instructions, admins can effectively brick a device until its either returned or recovered.
Admins should choose to disable without login screen to completely prevent device access until manually unlocked by an authorized user. Along with correct networking controls, it would be impossible to unenroll or resell the device.
The guest account on Chrome devices lets users access a passwordless, policy-immune account with limited functionality. This could lead to unauthorized use of the device and could be used to bypass filtering and security protections.
To remove access to the guest account, just set the Guest mode option to disabled.
To prevent unauthorized access to your Chromebooks, it is important to limit sign-in access to specific users or domains for each device. This not only improves security but also gives administrators the ability to better control user permissions for different groups.
This functionality can be found in the User & Browser Settings where admins can add different domains to different device groups (e.g., example.com). Admins can also allow normal accounts for limited personal use but group policy will still apply.
Some organizations may have several users log in to the same device every day, or companies may want to hide the personal information of users if the Chromebooks are meant to be taken outside of the building. Either way, admins may want to consider removing profile pictures and information of users on the general chromeOS login screen.
To set this up, all admins have to do is go to the device settings in the unit you want to change and go to the sign-in screen section. There, just set the value of Never show user names and photos to true.
To make sure that all Chrome policies are always enforced for every user, admins may want to block several sign-ins for enterprise users. However, personal accounts can still be added to the devices if wanted, with the same controls in effect.
Admins can navigate to Devices > Chrome > Settings > Users & browsers and scroll down to Multiple Sign-In Access. There should be an option to Block Multiple Sign-in Access to Users in this Organization that should then be enabled.
ChromeOS gives users several features made to improve the general experience. However, these features also create gaps in terms of user security and device policies. Because of this, administrators may wish to disable certain features in order to enhance pre-existing controls.
Administrators have the option to prevent user access to the certificate management page to make it harder to leak private keys or incorrectly modify certs. This can improve overall device security and can also help in limiting user configuration.
This change is available in Devices > Chrome > Settings > Users & browsers. Then, under User management of installed CA certificates, select Disallow users from managing certificates and save it.
To ensure the integrity of device extensions and system stability, admins may want to disable the Chrome task manager or set limits on what extensions/applications can be stopped.
The option to disable the Chrome task manager is one of the first under Devices > Chrome > Settings > Users & browsers. Admins can then choose the option to block local users from using the task manager.
Google Chrome has several internal addresses that allow access to developer settings and system changes which can compromise device security and get around policies. Because of this, admins may want to disable these pages in Devices > Chrome > Settings > Users & browsers > URL Blocking:
chrome://net-export
chrome://sync-internals
chrome://network
chrome://hang
chrome://restart
chrome://kill
javascript://*
data://*
chrome://system
chrome://net-internals
chrome://serviceworker-internals
devtools://*
chrome://settings/performance
chrome://network#state
chrome://inspect#devices
chrome://indexeddb-internals/
chrome://crostini-installer
chrome://shimless-rma/
chrome://chrome-signin
html/crosh.html
chrome-untrusted://*
chrome://policy
To ensure that extensions consistently run in the browser, it is recommended that admins disable access to incognito mode.
Navigate to Devices > Chrome > Settings and select User and Browser. In this section, you can find an option to disable incognito mode. Change the value to true and click save to apply the changes.
Many policies on google admin exist to expand device compatibility, however some of these services are for outdated systems and are no longer secure. These policies could have been set by different administrators, or just never removed. This can widen your organizations attack surface and causes unnecessary risk. Admins should be sure to check and remove any GPOs shown below that are enabled in chrome://policy:
EnableDeprecatedWebPlatformFeatures
RunAllFlashInAllowMode
SuppressUnsupportedOSWarning
EnableOnlineRevocationChecks
OverrideSecurityRestrictionsOnInsecureOrigin
CertificateTransparencyEnforcementDisabledForCas
CertificateTransparencyEnforcementDisabledForLegacyCas
LegacySameSiteCookieBehaviorEnabled
LegacySameSiteCookieBehaviorEnabledForDomainList
ChromeVariations
DnsOverHttpsMode
LookalikeWarningAllowlistDomains
SafeBrowsingAllowlistDomains
RemoteAccessHostAllowRemoteAccessConnections
The option to powerwash devices can negatively affect users and admins through data loss, policy changes, and enrollment issues. Because of this, most organizations choose to disable the option for users to powerwash their devices.
This setting is available in Devices > Chrome Devices. Under the Powerwash section, choose Do not allow powerwash to be triggered. This will prevent users from wiping the device except during a TPM firmware update.
Sh1mmer is an exploit that takes advantage of how factory shims are verified for the device. By only checking the kernel signature, it was possible to modify the normal shim image to allow users to manipulate the device.
In order to fix Sh1mmer on Ti50 devices, Google would have to roll all shim keys on the board, however this has still not happened as of Kv4. On older Cr50 systems, it is currently impossible to patch Sh1mmer. Admins can still track Sh1mmer usage in their workspace by checking for old device policy sync dates in the admin console and removing enrollment permissions for general users.
The Shimless RMA menu is a tool embedded into ChromeOS that allows technicians to make limited changes to the device after repairs. However, it can be accessed without authentication and used to fully reset and unenroll the device.
As the Shimless RMA menu is part of the device's firmware, it is not possible to patch it at this time. Admins should blacklist access to https://chromeos.google.com/partner/console/ and use the same methods shown with Sh1mmer to detect this exploit in the workspace.