Security

crouton is not and cannot be as secure as Chromium OS in verified mode. Here's why:

Chromium OS's security out of the box is extremely good. All code that is natively run is either explicitly vetted by the chain of trust that starts from the embedded controller (the OS and Chrome itself) or permuted such that it cannot escape a narrowly-defined sandbox (NaCl, Pepper plugins, etc). If you have a Chromebook and you're running ChromeOS, it's even better, as the chain of trust starts from the TPM. (This might be a little off on the details, but secure boot is way better documented elsewhere.) Since arbitrary code can't run, you don't get keyloggers, screen readers, session/password hijackers running natively on the machine. Your user profile is encrypted with your password, and if you lock the screen or reboot, there's no way to access the unencrypted contents.

Of course, without arbitrary code execution, crouton can't work. So you enable dev mode.

Dev mode out of the box does several things that compromise security, including disabling verified boot, enabling VT2, and activating passwordless root shell access. This means even without crouton, if you're in dev mode, someone can switch to VT2, log in as root and add a keylogger that runs at startup, then switch back without you knowing. If you're logged in, they can also access the unencrypted contents of your Chrome profile and copy it elsewhere. If an exploit to Chrome is found, verified boot will no longer protect you from persistent compromises. Essentially, dev mode by default is less physically secure than a standard laptop running Linux*.

crouton adds a huge attack vector to the system by running a lot of unvetted code (i.e., all of Debian/Ubuntu/whatever). While it tries pretty hard to keep things restricted for non-root and installing and running as few things as possible, fundamentally there's nothing about a chroot that prevents a process with root access from escaping the chroot and compromising Chromium OS itself. So any remote root exploit anywhere in your Linux distro of choice now could be used to compromise Chromium OS.

crouton gives you the option to encrypt your chroot, which attempts to regain a lot of the security guarantees of stock Chromium OS. For starters, it refuses to let you mount an encrypted chroot without first setting a root password. So the VT2 attack is password-protected, which helps physical security (assuming you don't leave your chroot's graphical session unlocked). It re-enables verified boot when it can, although this is a bit of a false sense of security, as anything with the ability to escape the chroot and edit the rootfs also has the permissions necessary to disable verified boot again as well. But it does enable you to check at bootup whether verification is enabled if you're paranoid (press TAB at the Scary Warning Screen), so if you reboot and you see verification is enabled at the boot screen, you can be reasonably sure you haven't been persistently compromised inside Chromium OS. Once you enter the chroot after booting, though, that guarantee is of course gone. Finally, crouton encrypts the entire chroot and prevents non-root users from accessing the unencrypted mount. This is to protect your chroot from Chromium OS; if you reboot or Chromium has a non-root exploit, nothing can touch your chroot (or if it does, at least the chroot will break so it's obvious).

Despite that, an encrypted chroot absolutely does not have the same strong security guarantees that fully-verified ChromeOS has. At best, it's a tad better than a stock Linux distribution.

Be aware though, that at the moment, crouton does not implement verification of the initial bootstrap. This means that until this fixed, the bootstrap step (or tarball) should be downloaded on a trustworthy link to the internet (which may be impossible depending on your level of justified paranoia), or should be verified manually by other means.

---

* Justification: with a standard laptop running Linux, you can physically compromise the security of a system by rebooting into single-user mode to gain root, but that would lock you out of any encrypted disks. With dev mode, you can just switch to VT2 and have root, and your profile is available for the reading, plain as day.