Praise for Crouton, and a few questions regarding possible security improvements

[engineergoff]

If I am posting this in the wrong place, I apologize. This really isn't an issue, but I was unsure where else to post it. First, I want to thank the folks who are developing this technology. It's pretty fantastic. More to the point, it got me out of a pretty tight jam the other day; for which I am grateful. By way of thanks, I'd like to make a suggestion, which I hope is helpful.

To explain, I had been on the fence about installing Crouton on my Chromebook, since I heard of the project about a month ago. I read the "read me" notes on the project page, and was a little wary of the possible security risks, but decided to take the plunge when my primary home machine, which ran Mint Linux, decided to lose its video card. Since I only ever used the thing for work, lets just say this put me in a bit of a bind.

So, I installed the XFCE target, then Ubuntu's Software Center, and away I went. Frankly, I've been stunned by how well the "Guest OS" functions. After a few days of using it, I have to say, I haven't really had any major issues.

Here is the thing though, I'm still a little concerned about security. I installed to my SD card, for the sake of additional storage, and if I loose that card, anyone who happens upon it would have total access to my files. I realize I could have encrypted the Chroot, but the tutorial I was using didn't really explain how, and besides the encryption is really only as good as the password.

Anyway I was thinking this over, when I had a few ideas I thought might enhance the security of your system. If I am way off base here, I apologize.

The way I see it, the security issues for Crouton amount to three basic problems. First, the root file system on Chrome OS is exposed to attacks from the Guest OS side. Second, the Guest OS can be corrupted, from either the Chrome OS, or Guest OS side, because the total guest file system is exposed, even if the Chroot is encrypted. Third, if the device, or in the case of those who install to a SD, the memory card are stolen, then my data is much less secure than it would have been. I like to suggest ways of addressing these issues; if I might, but since you folks know a heck of a lot more than me about this stuff, I'll phrase my suggestion in the form of a question.

1. Could Crouton be made to encrypt the entire Guest OS file system, in such a way that these files would be "unpacked" and loaded when the guest OS was started, and further Guest OS was installed?

I realize that right now Crouton is not an "app" which runs every time the Guest OS is called; but I think it might be beneficial if it did. I'm more asking is such a thing is possible. I feel this would resolve the issues related to data security.

1. If this is possible, could these files be saved to a protected partition of my hard drive, or an SD card, in such a way that they could not be deleted or accessed; except via a call to run by the revised Crouton "app", which would logically speaking have to handle the Guest OS start up? I feel this would eliminate the issues with physical security of the device, unless it was stolen while I was logged in, in which case all my files are exposed anyway.
2. Lastly, could a target Guest OS be rewritten to ignore the Host OS root file system entirely? By this I mean, could it be locked down in such a fashion that the Chrome OS file system would be usable by the Guest OS in as much as such a thing is necessary, but not accessible by any programs running on it, and not visible at all to the end user from the guest OS side? I feel this would eliminate the threat of attacks on the Chrome OS files system, being directed from the Guest OS side.
3. Could this modified version of Crouton be set up in such a way as to make installation of any target Guest OS without the modifications suggested above impossible? Or maybe just throw some really scary warning at folks...whatever makes you smile.

Anyway, I drug this on way longer than I wanted to. Sorry about that. I really love Crouton, it's made me like my Chromebook a lot more. Best of luck in your future development.

Yours,
Bruce Goff

[dnschneid]

You found the right place! I'd like to start out by saying I'm no security expert either, which generally means I know just enough to accidentally convince people something is far more secure than it actually is. So take everything I say with a grain of salt. That having been said...

You are correct that with encryption disabled, there is absolutely nothing protecting your data. By default, Chromium OS has no root password in developer mode, so someone can just switch to VT2, log in as root, and dump the contents of your chroot AND Chromium OS profile to a memory stick.

I've tried hard to make sure crouton with encryption enabled is reasonably secure, however, and believe it ends up somewhere between Chromium OS in normal mode and an arbitrary Ubuntu install in terms of security (that's right, I'd consider it more secure than most Ubuntu installs). For starters, despite being in dev mode, Chromium OS with a root password set is still above average as a secure linux distribution, thanks to careful selection of kernel parameters, the relative sparsity of features baked in, and the very defensive default settings (such as not allowing incoming connections, at all). You can get a bit extra safety by enabling boot verification in dev mode by running sudo crossystem dev_boot_usb=0 dev_boot_signed_only=1 (I'm considering having crouton run this
for you when you create an encrypted chroot). crouton benefits from all of this, and tries to avoid making things too much worse by avoiding changing the execute permissions outside the chroot, not requiring rootfs verification to be disabled, and not running any net-enabled daemons.

So how does encrypting your chroot close the security gap?

• It forces you to have a root password set before mounting the chroot, and then mounts the decrypted version on the chroot filesystem in a directory only accessible by root. To be clear, the decrypted contents of your chroot only ever exist in memory; they are never written to disk. Very few things in Chromium OS run with root privileges, so the chroot is pretty much inaccessible to Chromium OS, with the exception of a couple explicitly shared directories. Furthermore, a user with reasonable physical access (e.g. without taking the device apart) will need your root password to access the chroot from VT2 if your Chromium OS and chroot sessions are locked. This is the same as with any standard Linux machine. If the attacker reboots your system, the chroot will be unmounted, and only the encrypted data will be accessible.
• The chroot is mounted such that unencrypted files in the encrypted folder are not readable in the decrypted version. This means you can't "poison" the chroot by dropping random unencrypted files into it.
• The chroot is actually encrypted using a randomly-generated 512-bit key (actually, two 512-bit keys, one is just for file names due to the excessive amounts of known plaintext), which is then wrapped with your passphrase. The process of unwrapping a key is expensive by design, making it hard to brute-force. This is the exact same method that both Ubuntu and Chromium OS use to encrypt your home directory. Assuming you picked a strong passphrase, it would take an extremely dedicated attacker to devote enough resources to decrypting your chroot, at which point you have very nasty enemies and an entirely different class of problem.
• If you're worried about your passphrase not being strong enough, you can take it one step further and store the decryption keys on a separate medium. Use the -k parameter to specify a location on a small flash drive on your keychain to save the keys, then be sure to insert that USB key whenever you need to mount the chroot for the first time (afterwards you can remove it). This is excellent two-factor security, but make sure you don't lose the USB key or included key files. The only thing harder than brute-forcing an ASCII passphrase is brute-forcing a 512-bit key.

With that background, we can address your conserns directly: Chromium OS still has a read-only root filesystem (unless you've disabled that), and you can enable verification for a bit extra peace of mind. The chroot doesn't actually expose the Chromium OS root filesystem anywhere; you would have to have root inside the chroot to mount the drive. Root exploits are a danger to any system, and the minialistic nature of Chromium OS and crouton, and Chromium OS's auto-updates help reduce the chance of having an unpatched flaw compared to most Linux distributions. The chroot's filesystem is safe if encryption is enabled for the reasons listed above, and it's only a danger to itself as much as (again, arguably less than) any Linux distribution is. The last possibility (your chroot's physical media being stolen), is also addressed above.

Your suggestion is pretty much what already happens, as is point two and three in the resulting list (in terms of forcing a root password). I could add a strong warning that people should encrypt their chroots when they go to make one, but nobody really reads the stuff that gets spit out on the console anyway.

As for point one, hiding a partition only gets you so far, and if someone knows about crouton (why else would they look for your chroot), they'll just as easily be able to find the hidden partition, at which point you're down to the security of the encryption, which crouton already depends on.

So then why the scary wording in the README? Simply put, Chromium OS is ridiculously secure in normal mode; completely beyond what a generic Linux distribution can do, and far more layered and provable than most appreciate. When in dev mode, however, you sever the chain of trust in execution and increase the attack surface by several orders of magnitude. A lot of the absolutes that make Chromium OS secure are removed, essentially dropping it down to the level of a normal Linux distribution. If you've purchased a Chromebook for the extremely strong security it presents, crouton is not for you; it simply can't compare to Chromium OS in normal mode. If you're okay with security at least as good as a standard Ubuntu install, however, encrypting your chroot should achieve that nicely.

[engineergoff]

First, thanks for responding; I really appreciate it. I think I may need to drastically increase my level of technical understanding of Chrome OS in general and it's security in particular, to make sure I understood everything that you said, but hey...researching a technical subject is one of the few pleasures out there engineers of all disciplines get to enjoy! Out of curiosity, you said putting Chrome OS in developer mode takes down some of the security walls that are built in to the system. I guess I understood this. My question though, and writing this I am starting to think it is kind of a stupid one, is what does Crouton do which requires the lowering of these walls. Meaning, what functions are necessarily for it to operate, which can not be performed in Chrome OS's normal operating mode. Please don't feel compelled to reply, at this point I am satisfied the system is reasonably safe. I'm only about a year into using Linux. There's a ton of stuff I just don't understand, and at this point I guess I'm just curious.

[rminnich]

The main wall that dev mode tears down is that you can run arbitrary
programs. That's a big wall, but tearing it down is what allows crouton to
work.

ron

[engineergoff]

Thanks...I thought this might be the case. I think I may have an idea for how to run Crouton w/o putting the Chrome OS device in developer mode, but I am not sure. I need to do a ton more research! I will get back with you folks if I feel I am on to something. But thanks again for the software...its amazing.

[DennisLfromGA]

Sounds promising, hope to hear from you.

[tedm]

That sounds exciting. Please keep us updated. You might find this deck interesting on the Samsung tpm/bios parts: https://docs.google.com/presentation/d/1Cyz2gyyxg7hZBeCp_LSDGbEhsqy6OqsJTBLprXSzOKQ/pub#slide=id.gcc92f345_04

My biggest hurdle is that I haven't been able to get the crouton chroot (all precise based so far) to act as an sshd or samba server, but web server is fine. I have been able to get the samsung to function as a mini stand-alone server, but only when booting from arch linux arm, on an sd-card, but I"m still working on the remaining server functions as a crouton chroot as I think others may have gotten sshd and samba working in the chroot?

[dnschneid]

If you can get crouton running in normal mode, please report how you did so using http://www.chromium.org/Home/chromium-security/reporting-security-bugs

[engineergoff]

First off sir, you have my word, if I find some way of running or installing any native program, not just crouton, outside of developer mode I will report the security bug. Having said that...and I can't stress this enough...I'm a mechanical engineer who only got serious about educating myself on Linux about a year ago. The odds of me finding such a loophole in Chrome OS's security are roughly equivalent to my being struck by lighting twice in one day.

I have something else in mind.

It seems to me that what a Chroot does, at it's most basic, is enable an alternate x server to be run beside an existing x server, but from a single kernel. If I understand correctly, the x server is really just a program that runs off of the kernel; that is, it has certain kernel outputs (dependencies) that it requires to run. The kernel creates these, but with the exception of the software that ships with the OS, this is forbidden by default on a Chrome device, and this is what makes running a Chroot in normal mode impossible.

I think there might be a way of simulating the functions of a Chroot, without actually using a Chroot. I am thinking of a Native Client Module, which securely passes the alternate x server's kernel dependencies up into the native client sandbox, creating a sort of kernel-like environment, inside of which the alternate x server could be run.

I think this might be possible to achieve without suffering the performance hit of emulating hardware, and running a separate kernel. If it fails it would be because the x server could not be compiled in language that the native client technology currently supports (C or C++) . I know that Wayland, an x server alternative, is written in C. I am not sure about x server.

If it works, this would also allow the alternate x server to be view-able inside a window on the existing Chrome OS x server. This would be my preferred method for running an alternate desktop.

Lastly if this is all nonsensical gibberish, I'm REALLY sorry. Honestly my goal here was to do a lot more research, and then hand the idea off to someone once I was sure setting up such a system was even possible.

[rminnich]

I don't want to be rude, but unfortunately what you said was in fact mostly
nonsensical :-). I think you need to spend some time learning what a chroot
is, what an X server is, and why just getting an X server to run in native
client would not help you much.

I admire your enthusiasm, I just think you need to spend a bit more time
learning how this stuff works.

[engineergoff]

First off, rmminch, no worries. I definitely didn't have the level of conceptual understanding of the system that I would normally have before opening my big mouth. My fear was that a previous comment in this string was misinterpreted, primarily due to my own lack of clarity, and so I felt that it was necessary to clarify my intent. I sort of had the feeling that I would elicit something akin to your response. So please, understand, I appreciate you not just basically telling me off. Having said that, I am attempting to increase my level of understanding of these systems. It is my intention to master whatever technical skills are required, as quickly as possible. I would appreciate any guidance you might offer regarding a practical course of independent study, should you feel inclined to offer such advice. If not, sir you have may appreciation, both for your time and the candor of your response.

[rminnich]

Would you like to talk to me directly instead of via a bug list?

I'd be glad to talk to you about a possible path for your ideas.

ron

[engineergoff]

That would be great. Feel free to drop me a line via gmail. engineergoff@gmail.com. I would love to hear from you.

[tedm]

I'm curious if engineergoff or anyone made progress on the above, or even booting into the chroot without ctrl D ?

Also, to update my 2 month old ssh issue, I haven't setup Samba in a chroot, but ssh / sshd is working fine with iptables -P INPUT ACCEPT which I put in /etc/rc.local

Not sure if this is a security issue, as it shouldn't surprise anyone, but from the chroot, it is possible as root to run top or other process modifying commands which stop the chrome* apps and basically still use the hardware from the chroot, but the hot-keys and chromeos windows have come down, though the local terminal is not crashed, it us very durable and new windows can be opened.

[engineergoff]

Honestly, I've made no progress on this other than to determine that I have quite a bit to learn. The idea of running the x-server inside a sandbox without emulating the kernel just won't work. At least I don't think so. I am looking at other open source emulators that run inside Googles native client, and researching how to build an new emulator from the ground up.

[tedm]

Thanks for the update.

[dcki]

I don't suppose crouton's installation and chroots management and launching could be performed by a regular chrome os app, without putting the machine in developer mode? Would that require more permissions than are allowed for chrome os apps in normal mode?

[peterwilli]

@engineergoff I'm not sure if you're still working on this, but this has been on my mind as well. What I've tried besides Crouton (which I'm using at the moment) is the new Android-subsystem in ChromeOS, that allowed me to run this GnuRoot Debian (https://play.google.com/store/apps/details?id=com.gnuroot.debian).

It's a graphical Linux distro without emulation (so pretty fast) inside an Android app. It has a 'fake root' that gives you full access and allows you to run several applications.

Unfortunately I had to stop using it. The reason why is because the Android-subsystem on ChromeOS runs in a 32-bit architecture, even though my ChromeBook has a 64bit-processor. This prevented me to use developer-tools that require 64-bit only.

Right now, I am still using Crouton with an encrypted chroot, but found out about a startup called Droplet computing (https://dropletcom.com/). They are currently in the process of private-testing a chrome app that allows you to run Windows applications at full speed. I think it's some kind of performance improvement of BoxedWine (http://boxedwine.sourceforge.net/b4/games.html). In the videos from DropletComputing, it performed very fast.

I signed up for their private beta but I doubt I get an invite, since they are going to release end-2017.