Shell Access With Verified Boot And Auto Updates

If you wish to explore Chrome OS under the covers or have other uses for a local shell, but don't want to disable verified boot nor disable auto updates to the OS or firmware, you can have all of this in just a few steps (please be sure to read also the caveats at the end of this document):

1. Enable developer mode (this is not the same as developer channel- you can be running the stable, beta, or dev channel):  
Toggle the developer mode physical switch on your device, or in the case of new ARM based Chrome OS devices and devices which forgo a physical switch in favor of a virtual switch, follow the procedure to activate developer mode.

2. Go to a shell.  Do this by entering:


A terminal opens.  Enter the following command at the prompt in the terminal:


Alternatively you can enter Control-Alt--> (i.e. F2) and follow the instructions there, then skip step 3 below and proceed instead to step 4.

3. Become root and set a password for your device by entering:

sudo su -    

You will be in a root shell (indicated by the # prompt).   Now enter:


Follow the prompts.

4.  Here is the important command.  Enable verified boot from the root shell by entering:

crossystem dev_boot_usb=0 dev_boot_signed_only=1

The firmware will then boot only Google signed-images (full verified boot), and only from the SSD.

For example, on a Chromebox ("Stumpy"), when you reboot, there will be a 30 second pause that includes two audible beeps (this alerts you that you are in developer mode- i.e. that you toggled the developer mode switch physically), during which time you will see this screen:
You will no longer see this screen.

Again, the screen is an indication that you are in developer mode, but it also says that verification is turned off.  Since you enabled verification in step #4 above, this message does not seem to accurately describe the boot mode.  And in fact, by hitting the TAB key while the above screen is displaying, you can confirm that the boot in progress is a fully verified boot.   You should see something like this after hitting the TAB key:
Verified boot setting showing in BIOS after pressing TAB

In this example, you can see that dev_boot_signed_only is set to 1, confirming from the firmware that the boot in progress is a fully verified boot.  

A feature request has been filed so that future hardware will display messages to more accurately reflect that you are in a verified boot + root shell mode.  For now, you must hit TAB to confirm this at boot time.  If you wish, you can star the feature request to give it a higher priority.  The request is here.  There is security value in a more accurate default dev mode screen and/or in checking your verified boot settings by hitting TAB from the boot screens.  To understand the value, suppose a remote attacker escalates to root on your machine.  At this point all bets are off: an attacker could have changed your settings- disabling verified boot- and installed a root kit that then displays false information about the verified boot settings once you are past the firmware and are running what you think is normal Chrome OS on your machine.  You might never know this unless you can confirm a verified boot is in progress before you enter the Chrome OS operating system.  The firmware lets you confirm this.  Ordinarily, Chrome devices do not boot in dev mode, which guarantees a verified boot.  But since you are in dev mode, you need another way of guaranteeing a verified boot is happening.

As long you check the value of dev_boot_signed_only from the firmware at boot, you have a fully verified boot.  Both conditions must apply:  you must check, and you must do that from the firmware (not after boot).

Please note:  Some Chrome devices will not show verified boot information when you press TAB.  The BIOS will only accept input from the first keyboard it finds.  Other USB devices can interfere with keyboard input so if TAB is not working try unplugging everything but your keyboard.  Reportedly, the BIOS can also be non-responsive to keyboards that otherwise work fine in Chrome OS.  For more information about Chrome OS device firmware, see this page at  

Please also note: If you enter recovery mode in dev mode and thereby re-image your entire machine with a recovery image, the recovery mode screen you see will tell you that your machine is unverified even though this is not true since dev_boot_signed is set to 1 (assuming of course that you set it to 1).  This is similar to the normal boot screens not accurately describing the boot mode.

The delay experienced during dev mode booting can be bypassed by entering Ctrl-D at any time, which causes the boot to proceed immediately from that point.

Once you have finished booting and the full Chrome OS operating system is running,  you can view your current settings as reported by the (verified) kernel.  In the browser, go to chrome://system/ and expand the bios_info button.  Or, from the shell, run crossystem without arguments as root.  You can also run crossystem kernkey_vfy.  If sig is returned, the kernel is a Google signed kernel.  Any other kernel partition returns hash, so you shouldn't see that value immediately following a verfied boot.

OS updates continue to work whether you are running Dev, Beta, or Stable channel.  You can run any of those channels, and change channels as often as you like.  Firmware updates also continue to work automatically on most Chrome OS devices, though some older devices will prompt you to manually install firmware updates (which are rare).

You will find various goodies in the minimal stock shell userland, including vim, top, sed, awk, openssl, wget, and a recent version of curl compiled to support these protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp.  You can run shell scripts in your home directory by entering sh (you will need to call the shell first with sh because your home directory is mounted noexec).  As root, you can explore the read-only Google partitions to your heart's content and providing you do not make further modifications, you will always have full verified boot and receive all Google updates as normally.

If the minimal stock userland does not meet your needs and you want more, but you want to preserve stock Chrome OS with the verified boots and auto updates that attend stock Chrome OS, note that pre-compiled binaries of other command line utilities exist.  For starters, there are some additional binaries maintained and used by Chrome OS developers which can be installed using a command which is already at your disposal since it is installed on stock Chrome OS and is available from the shell.  Simply run:


dev_install installs available binary packages into /usr/local.  When run for the first time, dev_install gives you python, rsync, less, pax-utils and some others.  After running dev_install for the first time, you can add additional available packages using the emerge command that dev_install prepared for you, for example:

emerge tmux
emerge qemacs
emerge socat
emerge tcpdump
emerge iperf
emerge diffutils

To see other binaries you can emerge, take a look at /usr/local/etc/portage/make.profile/package.installable.  Again, these binaries come from Google, and the Chrome OS developers at Google have said they will be making a C compiler and libraries available via dev_install in the future (no date set at this time).  Additional information about dev_install can be found on the Chromium OS developers web site.  Note that dev_install writes everything into a pre-existing, empty, read write filesystem (/usr/local).  This is probably what you want because it means that use of dev_install and the tools you can add with it will not break verified boot and you can easily wipe your system back to it's previous state should you choose.

Apart from python installed via dev_install, another programming language that you can easily add to your system without giving up verified boot and automatic updates is the go language developed at Google by some of the founders of UNIX (and others).  The pre-compiled go binaries for linux available from golang web site will run without dependencies and enable you to compile go programs on your Chrome OS device.

If you want to go all out and give yourself a full *NIX development environment, various efforts to do this already exist.  Some of these efforts preserve verified boot and auto-updates.  See for example the chroot based crouton effort, which gives you an Ubuntu user land environment accessible from within Chrome OS- i.e. a Ubuntu user land environment that you do not boot into.  (Dual booting is a different configuration; this page is about accessing Chrome OS and maintaining its security of verified boots and auto updates, while also having a local Linux shell.)

Finally, once you have a shell, you may want a shell in an separate window (sans browser omnibar, etc.) in the way that ssh is available in a separate window on Chrome OS (see Caveats below).  To get a separate shell window, you must install crosh window, a web app available in the Chrome web store that gives you the separate window.  (The crosh window app requires that you have installed the ssh app because it requires hterm.)  Note that you can always avail yourself of the second virtual terminal as well (Ctl-Alt-F2), but that is not the usual windowed environment.

Crouton uses the dev_boot_signed_only flag, setting it for you if you did not:

sudo sh -e ~/Downloads/crouton -t xfce WARNING: Signed boot verification is disabled; enabling it for security You can disable it again using: sudo crossystem dev_boot_signed_only=0 Please note: Remember that it can be important to undo things if you (or crouton) have changed dev_boot_signed_only. If dev_boot_signed_only=1 per the instructions on this page,and you later want to install and run Chrubuntu or your own kernels (say), boot will not go as expected unless you set dev_boot_signed back to zero. So don't forget! This page is about making it so that you can still verify that you are booting Google signed bits. But if you stay in dev mode and change your mind and want to boot bits not signed by Google (say you decide to try Chrubuntu), the corollary to the instructions here is that dev_boot_signed_only must be set back to 0 if you (or crouton) set it to 1. You do not need to set dev_boot_signed_only back to zero if you leave dev mode, see caveats below.

  • There are downsides to running in dev mode, even with verified boot enabled.  For example, Netflix will not work in dev mode.
  • This document assumes you know, but in case you do not, it should be stated that if you just want a shell but it does not need to be a local shell, Chrome OS comes with ssh built in, and there is no need to go into dev mode to get it, simply enter Ctrl-Alt-T and type ssh.  Of course, ssh allows you to login to any remote UNIX host.   If this is your use case, take the extra step of installing the ssh app.  (You have ssh without the ssh app, but install the ssh app.)  Among other things the ssh app gives you an app icon, which you can right click on to set ssh to open in a window, so that your ssh "terminal" will be in separate window sans browser omnibar etc..  For additional information about the ssh app see the ssh and hterm FAQ, the hterm and ssh additional information, and the hterm and Secure Shell Developer Guide.
  • When you put your Chrome OS device in dev mode, you disable verified boot.  This document shows you how to re-enable it.  However, re-enabling verified boot does not completely restore your device to the security it had prior to entering dev mode.  Dev mode makes other changes to the running configuration of the machine.  Obviously, this includes providing access to a local shell, which increases the local attack surface of the machine.  But there are other changes as well that increase the remote attack surface.  For example, /usr/local is mounted writable and executable.  The differences and security implications of being in dev mode are beyond the scope of this document.  For what it is worth, it should be true that:  if you check your dev_boot_signed_only value at boot from the firmware, then at the time of that boot, you know that you are executing a Google kernel and a Google root file system.  Those bits are verified at the time of boot.  There is at least this known initial state.
  • The dev_boot_signed_only=1 setting which you enabled in step #4 above persists for as long as your device is in dev mode. You can reboot, power down, and even completely wipe your machine by putting it into recovery mode and re-imaging it (see the "Please also note" above). The dev_boot_signed_only=1 setting will persist. However, it does NOT persist if you leave dev mode by toggling the dev mode switch, then come back into dev mode later. Each time you enable dev mode, if you want verified boot, you must re-enable that setting by following step #4 above. Each time you go back to your machine's normal state (i.e. when NOT in dev mode), verified boots are of course guaranteed, you do not need to do anything. In other words, you never need to manually re-enable verified boot before leaving dev mode. But must re-enable it when returning to dev mode. Note: The Google developers wanted to make dev mode default to verified boots enabled. Then, if you wanted to disable verified boot, you would relax security further by entering a command once in dev mode. That was not possible though without breaking some things since the original Chrome OS firmware didn't have the verified boot flag option in dev mode (originally, verified boot was always off in dev mode). But this should give you some confidence that you are in a "legitimate" running mode when you enter the command shown in step #4 above. Do not let this statement mislead you however; dev mode in general is not subject to the same level of testing as the factory state and the normal, mass market use of Chrome OS devices. Hopefully the name itself ("dev mode") makes this self evident. Also worth noting is that the firmware is undergoing continual change and redesign with each new Chrome OS device that comes to market. See for example this discussion.

Related Links (updated 12/18/2013):

Contributed by Trever Nightingale, with thanks to the Chrome/Chromium OS developers, especially for their patient responses on mailing lists
Last upated 11/02/2013