vim available in Chrome OS developer mode, what else?

[Trever]

I'm running Chrome OS Beta (currently at 23.x) on a chromebox, which I recently switched to dev mode (physically moved the dev switch).

I've read that qemacs was available.  It wasn't.  I ran vi, and boom:  there is vim, apparently in all it's glory.  Yay! 

When did this happen?  How would I answer this question myself by looking through _____ (what)?

I'm wondering what else is going on in text editor land.  One of the big beefs I have is the poor plain text support in google docs and thus chrome OS, and I'd love something that can work both locally or with Gdrive- something like vi.  Really looking for something that works in non-dev mode (i.e. secure boot enabled).

Apologies if I should know better on these things, but thought I'd see what people have to say...

Trever

[Mike Frysinger]

in secure (non-dev) mode, your only option will be extensions
available via the webstore (and obviously any external sites like
Google Docs)
-mike

> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

[Richard Barnette]

On Oct 24, 2012, at 2:53 PM, Trever wrote:

> I'm running Chrome OS Beta (currently at 23.x) on a chromebox, which I recently switched to dev mode (physically moved the dev switch).
>
> I've read that qemacs was available. It wasn't. I ran vi, and boom: there is vim, apparently in all it's glory. Yay!
>
> When did this happen? How would I answer this question myself by looking through _____ (what)?
>

It happened with this CL:
http://codereview.chromium.org/6851017

Prior to that, I believe there was no editor included in base
images. It's not clear to me that forcing 'vim' into base images
was one of the intended effects of this change, although
generally, I think it seems useful.

> I'm wondering what else is going on in text editor land. One of the big beefs I have is the poor plain text support in google docs and thus chrome OS, and I'd love something that can work both locally or with Gdrive- something like vi. Really looking for something that works in non-dev mode (i.e. secure boot enabled).
>
> Apologies if I should know better on these things, but thought I'd see what people have to say...
>
> Trever
>

> --
> Chromium OS discuss mailing list: chromium-...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

-- jrb

[Steve Pirk]

I definitely prefer vi, so thank you build team ;-]

If you are willing to leave a machine in dev mode, some enthusiastic developers out there have added a bunch of pre-built packages that enhance the usability of Chromium/Chrome OS. Todd Vierling started the trend and Taylor LeMasurier-Wren picked things up where Todd left off. He publishes versions of the packages as a shared Google Drive folder.

https://docs.google.com/folder/d/0Byyp8R1NxgJlb1FBeFpnSGV4TVU/edit

Here is the Google Groups thread discussing Taylor's work. I decided my Cr-48 would be the always dev mode machine, and having some handy tools and programs available is nice.

https://groups.google.com/d/topic/chromebook-central/UGD2ISPogAY/discussion

As mentioned in another thread, these do not touch the verified Google build, but are simple pre-compiled packages you add via tar. 

-- steve

[Chris Masone]

Hm.  We'd chosen qemacs because it was smaller than vim, back when we still acted like we cared about rootfs size :-)

Since care about rootfs size again, perhaps it's time to go back, remove vim, and install the smallest usable editor we can by default; people who build dev images and use developer mode can always install whatever they want, right?

[Steve Pirk]

nano is included in the add-on package list, so I have no issue with the switch. I learned vi way back when, so I guess it is time I learned qemacs. :)

-- steve

[Mike Frysinger]

we build vim with USE=minimal, so the resulting binary is less than a
meg (~500 for 32bit systems and ~700 for 64bit systems)

qemacs is about half the size. pretty sure we have much larger things
to improve before we get to this point ...
-mike

[Chris Masone]

I have't seen anyone making much progress on finding large things to strip out :-/

I think that we might be at the point where we start looking to make small gains everywhere because there aren't any large, spurious packages.

[Mike Frysinger]

the wallpapers were fairly large & suspicious :)
-mike

[Trever]

Hey thanks for all this great information!

[Broc Seib]

A-ha!

I was thrilled to find vim on my chromebox too, but couldn't believe there was not a pager, i.e. 'less' or 'more'. And thanks to this post and Taylor's packages, I will have one soon. :-)

Broc

[Ottavio Caruso]

On 14 November 2012 14:58, Broc Seib <broc...@gmail.com> wrote:
> I was thrilled to find vim on my chromebox too, but couldn't believe there
> was not a pager, i.e. 'less' or 'more'. And thanks to this post and Taylor's
> packages, I will have one soon. :-)

I wish there were packages for the ARM port too!

[Trever]

What?  Are you sure?  All of my machine have /bin/more (there is not less, but who cares?).

What machine are you running and which channel/version?

The information here might also interest you, depending on your use case:

https://sites.google.com/site/chromeoswikisite/home/what-s-new-in-dev-and-beta/shell-acess-with-verified-boot

Personally, I also use the following tool (ascii2gdocs) from the Chrome OS shell to migrate years of command line doc (ASCII) to Google's cloud:

http://code.google.com/p/ascii2gdocs/downloads/detail?name=ascii2gdocs&can=2&q=

I don't know if that helps anyone else.  For me, keeping state (ie. data) off any given machine is the holy grail given all the devices I use, and it's one of the many reasons I really like Chrome OS (vs., say, Android).

[Broc Seib]

You're right....   Sure enough, there sits /bin/more on my Chromebox, now that I look right at it. I swear I ran a find command looking for both less and more. :-|  Curiously, when I do echo $PAGER (as user chronos), it says '/usr/bin/less', which doesn't exist.

Thanks for the shell-access-with-verified-boot link. I didn't know you could do that, nor did I know about TAB key on the scary screen. I'm actually investigating getting my chromebox to cold boot from a larger mSATA drive, but that topic will be a separate post after I do some initial homework.

[Mike Frysinger]

pager info is set via the default shell scripts which do not do
validation on the variables. the assumption is that if the defaults
are changed (such as not installing less), the variables would be
updated. we didn't do that ;).

i think we were looking at shipping less since more sucks. hopefully
we'll get that back in ToT.
-mike

[Trever]

Okay, so one person (at least) cares about more vs. less.  :-)

What is the roadmap for the minimal UNIX user land in stock Chrome OS?

I thought you were on a campaign to slash and burn, eg. ax'ing bash....     

[Mike Frysinger]

there isn't really a road map. it's a case-by-case basis. the only
overarching goal is to cull useless chaff.

i was in favor of killing bash (still semi-am), but more people
preferred to keep it due to the alternative (dash) being horrible when
it comes to interactive behavior, and bash has generic usefulness.
similarly, more is pretty bad, so less would be a nice alternative.

i'd also point out that "minimal UNIX user land" is a pretty broad
term. busybox provides that (and more), and imo what we have in CrOS
supersedes that by quite a lot.
-mike

[Trever]

Busybox... shudder, a bit.  Maybe unjustifiably but nonetheless.  (Coming from a more BSD land where the stock userland is small... and embedded means same userland as server versus this busy stuff!)

It's not busybox now is it!?  I have looked, pretty sure I was seeing that the userland is not busy box.  Can't believe I don't know this...

[Mike Frysinger]

no, we do not use busybox. it's an idea that's been thrown around a
bit, but no one has found time to make it stick to see what happens.

BSD userland is pretty terrible. can't handle options after
non-option arguments ? what is this, the 80s ?
-mike

[Trever]

So busybox is not on the roadmap (such as it is), it sounds like.  More like something that might be tried.  Whew.

Re BSD userland, flame bait!  :-)   Not taking it.  :-)

Except to say that it's 2012, where's BTRFS?  We've had ZFS for several years now...  of course that's kernel space.  Where capsicum was developed...  :-)

[Mike Frysinger]

ZFS doesn't make any sense to CrOS. then again, if you really wanted
to see that in Linux land w/out going through FUSE, you should
complain to Oracle to make it happen :P.

i don't have any opinion on BTRFS. there aren't any indications that
it'd be a win for CrOS (we don't care about write performance since
our rootfs is read-only), so better to let other people (e.g. Fedora)
shake all the bugs out first. we know EXT4 is rock stable.
-mike

[Trever]

Of course, I agree with all of that.  I was just speaking on behalf of BSD generally in response to your dig... :-)

I have been surprised you use EXT4.  I *thought* there were better filesystems in Linux for solid state devices, but I'm a bit lagging on my knowledge there presently.  (The new Acer is the exception in terms of drives, and I don't imagine that changing- the cloud being the whole point.)

[Mike Frysinger]

since all the SSDs we use have a FTL (flash translation layer) between
us and the actual flash, it isn't like we need to do bad block
management or wear leveling ourselves which would preclude using ext4
directly.

plus, since we run the rootfs partition read-only, we don't need to
worry about the fs optimizing writes for us.

the stateful partitions don't write directly to the device as they're
encrypted, so running a flash friendly file system on top of a crypto
block doesn't make much sense.

if we had a device that sat directly on top of NAND or a NOR flash
(like SPI), then you could make an argument for something like ubi.
but that isn't what's going on today.
-mike

[Trever]

Makes sense to me.  Thanks.

Getting back to this thread.... is there or has there ever been any thought to make a USB image that one can plug into (say) a Chrome box and it contains a Chrome OS build environment?

I'm not even sure why I think that kind of self hosting distro would be cool, but apparently I do think that.  Just in general though... with the ability to run in dev-mode with verified boot on, having a "distro" of sorts that just provides extra binaries on a USB drive would (to me) make a lot of sense and would be a good community kind of thing to maintain (like Hex builds, in other words).  You could have a linux userland "alongside" Chrome OS, a best of both worlds for those who want it.

I guess part of what I'm thinking is "boot strapping".  If there were a thumb drive image you could plug in, run under stock Chrome OS, and build whatever binaries you want to add, etc...   would be cool, I think.

Just seeing if anyone knows what's out there now or what the talk has been about such things?  This is very different than a Hex build or the CRwhatever it is called that installs Ubuntu on a Chrome OS device.  I'm talking about something that keeps stock Chrome OS untouched (you'd just need to be in dev-mode, but can keep verified boot on).  Again, to me, this would be best of both worlds.  Personally, I *use* stock Chrome OS.  It's a good thing that it takes care of itself and I don't want to mess that up.  (Nor is it reasonable to build out the stock Chrome OS user land because it obviously needs to be kept small.)  But if you can get to the stock Chrome OS shell and execute binaries from a plugged in thumb drive, do builds, etc..  seems like a useful way to be.

[Mike Frysinger]

we only support x86_64 (currently) to build ChromeOS, so that would
already disqualify some ChromeOS devices

i'm not sure if people have though seriously about making the devices
"self-hosted" considering the power on these systems is underwhelming
when compared to the desktops we develop on (think many many cores
each clocked at 2.5ghz or higher)

you would have to reset to an external disk since most devices ship
with hard drives that wouldn't be able to hold all of the ChromiumOS
source trees and the build outputs

i'd point out that ChromeOS already has a "linux userland", but i
guess you mean more like "development related packages". there is
`dev_install` ... but that installs developer related packages and
does not include a compiler (since we don't currently support
cross-compiling native compilers).
-mike

[Trever]

Seems I may have found yet-another-project for my copious spare time then.  I'd just like to have binaries and be able to build them, even if not Chrome OS itself (which your developer doc and other things I've seen indicates does want a huge amount of resources).

Looks like Chrome OS team has switched to Precise (http://www.chromium.org/chromium-os/quick-start-guide).  Last I checked it was Lucid.  

Actually, wouldn't have to build anything if I can grab Precise binaries and make them work off of a flash drive... not sure that's possible though... hmmm.... what would the issues be.... there must be issues, else I don't think Todd Vierling and Taylor LeMasurier-Wren would have needed to do what they did.

[Chris Masone]

On Wed, Nov 14, 2012 at 9:07 AM, Trever <trr...@gmail.com> wrote:

What?  Are you sure?  All of my machine have /bin/more (there is not less, but who cares?).

What machine are you running and which channel/version?

The information here might also interest you, depending on your use case:

https://sites.google.com/site/chromeoswikisite/home/what-s-new-in-dev-and-beta/shell-acess-with-verified-boot

This document seems to oversell the security guarantees provided by this mode of operation.  From an internel thread that recently cropped up on this theme:

[In dev mode with dev_boot_signed_only] You give up a major exploit mitigation -- writeable mounts are not executable (one that seems to have thwarted a pwnium attacker only [recently] :) --  and [can] start running arbitrary code on the system that is likely uncontained from a security perspective.  Essentially, running in dev mode is the same as running your own Linux distro -- dev_boot_signed_only doesn't do much for you since a root-level attacker can turn it back off. 

 

Even if you don't add your own code, you're still far more vulnerable to attack -- and persistent attack -- then a user in verified mode.  I'd appreciate it if you could update your document to bring it more in line with what's actually going on in dev mode + dev_boot_signed_only :-)

[T N]

I'd be happy to address your concern (and not oversell) if I can understand the concern. Right now I don't.

The problem I'm having is that you seem to be describing (a) an attacker that is physically at the machine and (b) a situation in which the attacker has turned off the verified boot (which the document is at great pains to point out that the user MUST check the verified boot value (1) from the firmware and (2) at each boot).  If these precautions aren't clear enough I can make them more clear, but to be clear here: the document presumes that the mode of operation described gives you protection from remotely installed persistent malware where the threat model assumes the attacker never is in physical contact with the machine.  And I would add that this protection is obviously very different than a typical Linux box provides.

I am not sure I'm understanding the attack you describe though, and to my knowledge the pwnium attempts this year have not been made public yet.

In fact at least one writeable mount (/use/local) is executable when you boot in dev mode with verified boot, no change to that necessary. That may be the only executable writeable mount.  I would have to check again but I think the /usr/local bind mount does not get mounted (i.e. created) normally (outside of dev mode).  So if something were remotely installable and then executed from /usr/local, it would (I believe) constitute persistent malware that the verified boot in dev mode would not complain about. 

You could mitigate against this because (eg.) you could boot with no network connectivity, trust ls (which is verified), and so check /usr/local prior to any malware being executed (I think- though that may be dubious).  The document doesn't say all of this, and at that point the user has to jump through a lot of hoops that I'm not sure I'd want to keep advertising that mode of operation as a bonus. Maybe- you do get a verified in core kernel that you are executing, though not sure how far that would get you.

It seems strange to assume there could be no benefit to having verified boot, even with a root shell (dev mode enabled).  On the other hand, it feels a bit nonchalant as well to suppose one can know one has full protection from persistent remote attacks, eg. for the reasons just described, so I have worried about this (see below).

But what is the threat model being invoked here- a physically local attacker?  And/or, can /usr/local be remotely exploited?  I think those are the questions...though maybe there are other questions as well.

Again, I appreciate discussion of the security implications of dev mode with verified boot and did try to get that discussion going prior to posting the doc quite awhile ago- when the mode of operation came to light, when I was asking about if such a mode were possible- which started out as a question about root kit/malware detection post boot.  So if these discussions can come out from internal and be pursued here, all the better.

Trever

[Chris Masone]

On Wed, Mar 13, 2013 at 8:42 AM, T N <trr...@gmail.com> wrote:

I'd be happy to address your concern (and not oversell) if I can understand the concern. Right now I don't.

The problem I'm having is that you seem to be describing (a) an attacker that is physically at the machine and (b) a situation in which the attacker has turned off the verified boot (which the document is at great pains to point out that the user MUST check the verified boot value (1) from the firmware and (2) at each boot).  If these precautions aren't clear enough I can make them more clear, but to be clear here: the document presumes that the mode of operation described gives you protection from remotely installed persistent malware where the threat model assumes the attacker never is in physical contact with the machine.  And I would add that this protection is obviously very different than a typical Linux box provides.

 I'm assuming that the user has turned off verified boot, but enabled dev_boot_verified_only, as you describe.  The thing is that an attacker who gets root (remotely) can switch dev_boot_verified_only off again without the user knowing.  Frankly, it's implausible to assume that someone's going to manually go and read the spew that tells you BIOS settings at reboot. Your document indicates that an attacker must be local to change this setting, which is absolutely not true.

I am not sure I'm understanding the attack you describe though, and to my knowledge the pwnium attempts this year have not been made public yet.

In fact at least one writeable mount (/use/local) is executable when you boot in dev mode with verified boot, no change to that necessary.  That may be the only executable writeable mount.  I would have to check again but I think the /usr/local bind mount does not get mounted (i.e. created) normally (outside of dev mode).  So if something were remotely installable and then executed from /usr/local, it would (I believe) constitute persistent malware that the verified boot in dev mode would not complain about. 

Yes, and this is why dev_mode + dev_boot_verified_only does not provide 'shell access with verified boot' as the title of the doc promises :-/  It provides significantly less protection than verified mode.  

You could mitigate against this because (eg.) you could boot with no network connectivity, trust ls (which is verified), and so check /usr/local prior to any malware being executed (I think- though that may be dubious).  The document doesn't say all of this, and at that point the user has to jump through a lot of hoops that I'm not sure I'd want to keep advertising that mode of operation as a bonus. Maybe- you do get a verified in core kernel that you are executing, though not sure how far that would get you.

I think this is what I'm really saying :-)  This mode of operation really isn't a bonus from a security standpoint -- It's not realistically any safer than dev mode.

It seems strange to assume there could be no benefit to having verified boot, even with a root shell (dev mode enabled).

It's not the root shell that's the problem.  It's the other security guarantees that are no longer, well...guarantees :-) 

  On the other hand, it feels a bit nonchalant as well to suppose one can know one has full protection from persistent remote attacks, eg. for the reasons just described, so I have worried about this (see below).

But what is the threat model being invoked here- a physically local attacker?  And/or, can /usr/local be remotely exploited?  I think those are the questions...though maybe there are other questions as well.

Remote attacker, not physically local.  Someone who can get out of the sandbox and then leverage the fact that /usr/local is both writable and executable to do nefarious things and eventually get root.  Then he can turn dev_boot_verified_only off and completely pwn you, likely while you still think you're safe :-/ 

Again, I appreciate discussion of the security implications of dev mode with verified boot and did try to get that discussion going prior to posting the doc quite awhile ago- when the mode of operation came to light, when I was asking about if such a mode were possible- which started out as a question about root kit/malware detection post boot.  So if these discussions can come out from internal and be pursued here, all the better.

There really is no such thing as dev mode with verified boot.  There's "dev mode with some level of kernel verification and a OS-level security significantly weakened, oh and by the way an attacker who gets root can change your firmware flags to his heart's content without you knowing."  :-)

[Trever]

On Wednesday, March 13, 2013 8:55:37 AM UTC-7, Chris Masone wrote:

 I'm assuming that the user has turned off verified boot, but enabled dev_boot_verified_only, as you describe.  The thing is that an attacker who gets root (remotely) can switch dev_boot_verified_only off again without the user knowing.  Frankly, it's implausible to assume that someone's going to manually go and read the spew that tells you BIOS settings at reboot.

There's no spew, you have to reach to ctrl-d anyways, it is easy to hit tab first.  I check every time I boot.  I'm sure I'm not unusual (at least not when it comes to this).  Remember: this document is not for an average user- it's for a person who wants a *NIX shell and is willing to flip on dev mode (wiping their machine in the process, etc.).  My document is not for every "someone" who walks up to a Best Buy kiosk, and it isn't "sold" that way.

Furthermore the boot screen issues ("spew") are something to be fixed.  See the bug report to disambiguate the modes at boot more clearly (Will Drewry's term, and I think a reasonable one).  My document provides a link to it.

As it stands the main problem is that the firmware boot screen lies.  It says verification is turned off.  It isn't, and I can prove that with a key press and quick glance.  I find this *much* easier than you suggest.

It is open to interpretation what "verfication" being off means, perhaps (see below, semantics), but remember: the model is broken at this point anyways.  We're not talking about a device that does for you what most people (including competent people) fail to do.  So if you're bothered because we're waay outside of the Chrome OS device "vision" and we're still talking about it being well secure.... well yes we are way outside of that vision but yes, we might still be secure about what is executing (kernel, etc.).

 

Your document indicates that an attacker must be local to change this setting, which is absolutely not true.

It doesn't say that, it simply uses local as an example.  I will change that to be remote, though I'd like to know more about this situation that you envision.

Yes, and this is why dev_mode + dev_boot_verified_only does not provide 'shell access with verified boot' as the title of the doc promises :-/  It provides significantly less protection than verified mode.

I'm not convinced yet.  Instead there seems to be some issue of semantic ambiguity surrounding "verified boot".  Verified boot is just that:  it promises you that when you boot, the kernel and the root filesystem are Google bits.  You know this, but I'm saying it, because I need to point out that just as verified boot doesn't promise you more than that and my document was not intended to suggest otherwise.  For that matter, my document doesn't say that re-enabling verified boot protects you from non-persistent malware or any number of other attacks (man-in-the-middle, etc.).  It doesn't say that if you add additional userland binaries, those are known to be safe.  I tried to be quite careful in the documentation.

 

Remote attacker, not physically local.  Someone who can get out of the sandbox and then leverage the fact that /usr/local is both writable and executable to do nefarious things and eventually get root.  Then he can turn dev_boot_verified_only off and completely pwn you, likely while you still think you're safe :-/ 

Was /usr/local your concern all the way along here?  If that's the problem- if there's a writeable and executeable filesystem whereas outside of dev mode there are none-  such that this allows remote attacker to gain root, then clearly that is very important, and it was something I did *not* quite appreciate, as I recall.  However, please tell me what's involved here.  The root filesystem isn't writeable, etc..  Is there really an escalation path here (I wouldn't be surprised either way)?  How does this go?

Those are the key questions I have here, based on your emails about this now.

However, saying that doesn't cause me to agree with you about the value of booting dev mode with verified boot.  I'd still "sell" it, so far.... What you seem to be saying is that I pull the entire document or significantly change the tenor of it, and also stop poking my head up now and then and tell people about this mode (I have done that).  You're saying this mode just isn't useful at all in the ways that I think it is.

Equally though, this particular attack path (how nasty it is TBD) is an argument to have dev mode relax the security requirements more gradually, as was the original hope of some (such as Bill Richardson, who has said that when the dev_boot_verified_only flag was added, it defaulted to 1- i.e. verified, but broke factor installs so had to be changed to the original default of being off in dev mode).  In other words, it's an argument that dev mode does not bind mount /usr/local by default.  The user can make that mount easily (probably this screws up some manufacturing or testing situations for Chrome OS devices though?  Is /usr/local there by default for a good reason?).  

 

There really is no such thing as dev mode with verified boot.  There's "dev mode with some level of kernel verification and a OS-level security significantly weakened, oh and by the way an attacker who gets root can change your firmware flags to his heart's content without you knowing."  :-)

There really is such a thing as dev mode with verified boot, and an attacker who changes my flags will be discovered very soon by me, and anyone else who follows the advice given on that document.  I had to pull teeth (it felt like) to discover all of this, and I wrote up what I found accordingly, because I knew I could not be the only one looking for a mode of operation which didn't throw away part of the reason I bought the hardware.  I have also hoped that other people would take the information I found and run with it- figure out other cool things that I haven't, and so everyone would gain that way.  That's why I do go around and poke my head up and advertise the possibility of running in dev mode with verified boot- trying to see if others will take it and go on to do bigger and better things, as it were.  I don't want to be unfair but hopefully you can understand that I ask:  Is this really what concerns you?  That a monster is being promulgated here?  Does this dev mode plus verified boot "feature" bother some people there on the team(s) at Google in all kinds of ways?  Was it originally just for testing (pace evidence to the contrary)?  The modes seem to have semantic ambiguities, dev mode itself falls on the other side of "bright line" testing I'm told, and in general getting a local shell ventures well off into unintended uses of the devices Google and it's partners are trying to sell and support for the general public, etc..  Then there's the whole scepter of dev_install and maybe people there want to nip all of this in the bud?  It seems clear that others don't- they want to enable hackers.

Or is this straight up just a real security concern here (perhaps in part brought home by pwnium)?

When you start to say "spew" and that someone checking it is implausible, I can't agree with you.  Consistent with that, when I first made inquiries, there were people internally who simply did not understand the possibilities.  I got wrong answers on the list.  Then I had to figure out that the boot screen staring at me was lying, and finally got someone to say:  "Hey, you can press Tab and see your boot values."  I had to make sense of all of that.  

I frankly want to make sure that what you're saying now makes sense.  That filesystem thing does concern me.

But for sure, I still don't see how operating a Chrome OS device in this way is the same as running any other Linux distribution.  I can start to see your discomfort- "over selling"- maybe.  But I'm really going back and forth here in my mind.

What's the persistent exploit path here?  Does it require reboots?  How is it worse or different than any number of other non-persistent attacks?  I need to see that a competent user is really vulnerable here as you seem to be saying, but other times you're just assuming things (it would seem).

Does this make sense?

Again, if there is a real concern here (and there may be) I appreciate you dredging up this email thread and letting me know so it can be corrected.  No documentation is better than incorrect or misleading documentation.  (That's precisely how all of this got started... I was looking for information I couldn't find, got incorrect answers, etc..)

Trever

 

[Trever]

Chris,

I changed the document.  I don't know if it will satisfy the concerns?

To be clear:  I do not yet know all the changes to the running configuration of a Chrome OS device in developer mode versus normal.  If there is more that I should know because I'm being too naive (versus difference of opinion), I greatly appreciate knowing that, so feel free to continue to advise, I hope you (and anyone else) will.  The fact that I do not know all of the diffferences is obviously important.  I have hoped I know the relevant things, though.  Eg. that I can boot initially to a known state of the kernel and rootfs (and wow, I still like that!  Very different than definitely having to wipe an entire machine.  I'm sold, sorry if you aren't, what am I missing here?).

Re /usr/local, a remote attacker uploading and executing any chosen code as user chronos is obviously an alarm bell.  Yikes.

But I'm also not clear:  

1.  Can attacker do that normally (out of dev mode)?  Does normal mode have a writeable and executable filesystem?

2.  Suppose attacker is out of sandbox and trying to escalate remotely per your scenario.  Isn't that kind of game over already?  I.e., not the fault of dev mode?  On the other hand, is it not game over already and attacker can not escalate to root even in dev mode, and furthermore any success will be mitigated at next boot (assuming as I do that the user is habitually checking)?

Trever

On Wednesday, March 13, 2013 8:55:37 AM UTC-7, Chris Masone wrote:

[Victor Khimenko]

On Thu, Nov 15, 2012 at 1:11 AM, Mike Frysinger <vap...@chromium.org> wrote:

ZFS doesn't make any sense to CrOS.  then again, if you really wanted
to see that in Linux land w/out going through FUSE, you should
complain to Oracle to make it happen :P.

i don't have any opinion on BTRFS.  there aren't any indications that
it'd be a win for CrOS (we don't care about write performance since
our rootfs is read-only),

Huh? Really? BTRFS may immediately reduce space requirements for rootfs since you don't need to have two partitions for upgrades (create a snapshot, replace/upgrade components there, boot with said snapshot, if it does not work - you can easily go back to the first one).

Another possible use: cloud storage. You can easily introduce API where application says "Ok, locals torage right now is in consistent shape, you can sync it to Google drive" and, again, you can take a snapshot of the whole thing and slowly (if network connection is slow) upload it to Google drive (while application continues to change these local filesystem, too).

And another: shared applications between users (a-la Android 4.2). Again: two users can start from the same copies of files files and then change any of them safely.

I'm quite surprised BTRFS is not used by ChromeOS because it looks like a natural fit: cheap snapshots make so many things which ChromeOS needs to do trivial it's not even funny. I just assumed it's because BTRFS was not robust enough.