verifying kernel/root/etc. post boot ("verified dev-mode")

[Trever]

On a Google chrome device, has anyone tried to manually verify chrome os kernels and filesystems AFTER booting, from the command line?  (Wondering what commands one would run to do that...)

If the box is rooted obviously such checks can't be trusted, but still...  the root kit would have to make sure to cover those tracks and I'm wondering if that might not be so easy?  Maybe one could even have some few scripts/binaries on a USB thumb drive to run that one can trust, in combination with the read only firmware that one can check against, post boot in dev-mode?

The gist: run stock Chrome OS on a chrome device in dev-mode (getting command line access), and still do some kernel/root fs verification yourself (since it's not done during the boot sequence).  Best of both worlds ("verified dev-mode").

I ask because (1) I'm curious to explore more what is happening during verified boot and what might be possible on non-Google hardware, but also (2) as a use case.

[Olof Johansson]

Hi,

2012/10/24 Trever <trr...@gmail.com>

On a Google chrome device, has anyone tried to manually verify chrome os kernels and filesystems AFTER booting, from the command line?  (Wondering what commands one would run to do that...)

If the box is rooted obviously such checks can't be trusted, but still...  the root kit would have to make sure to cover those tracks and I'm wondering if that might not be so easy?  Maybe one could even have some few scripts/binaries on a USB thumb drive to run that one can trust, in combination with the read only firmware that one can check against, post boot in dev-mode?

The gist: run stock Chrome OS on a chrome device in dev-mode (getting command line access), and still do some kernel/root fs verification yourself (since it's not done during the boot sequence).  Best of both worlds ("verified dev-mode").

Actually, by default when you enable developer mode, you still get a read-only rootfs with verification. You can turn that off by using make_dev_ssd, but it requires an extra step.

 

I ask because (1) I'm curious to explore more what is happening during verified boot and what might be possible on non-Google hardware, but also (2) as a use case.

-Olof 

[Mike Frysinger]

On Wed, Oct 24, 2012 at 7:00 PM, Olof Johansson <ol...@chromium.org> wrote:

2012/10/24 Trever <trr...@gmail.com>

On a Google chrome device, has anyone tried to manually verify chrome os kernels and filesystems AFTER booting, from the command line?  (Wondering what commands one would run to do that...)

If the box is rooted obviously such checks can't be trusted, but still...  the root kit would have to make sure to cover those tracks and I'm wondering if that might not be so easy?  Maybe one could even have some few scripts/binaries on a USB thumb drive to run that one can trust, in combination with the read only firmware that one can check against, post boot in dev-mode?

The gist: run stock Chrome OS on a chrome device in dev-mode (getting command line access), and still do some kernel/root fs verification yourself (since it's not done during the boot sequence).  Best of both worlds ("verified dev-mode").

Actually, by default when you enable developer mode, you still get a read-only rootfs with verification. You can turn that off by using make_dev_ssd, but it requires an extra step.

and to the point of malicious software, you need to reboot the system after running `make_dev_ssd` before the kernel will allow you to mount the rootfs in write mode.  once verity mode kicks in, you can't go back.

of course, this doesn't stop code from modifying the partition directly via /dev/.  the kernel will probably crash or throw errors when encountering out of sync behavior, and at next boot (if verity is still on), the modification will be detected.

as for verifiying the kernels on the fly at runtime, the dev.chromium.org site has documents of the headers of the kernel images (and some of the utils provided by vboot to parse/check those), and the public keys can probably be extracted from u-boot itself.  although i'm not sure that is something we make readily available anywhere.

-mike

[Olof Johansson]

2012/10/24 Mike Frysinger <vap...@chromium.org>

On Wed, Oct 24, 2012 at 7:00 PM, Olof Johansson <ol...@chromium.org> wrote:

2012/10/24 Trever <trr...@gmail.com>

On a Google chrome device, has anyone tried to manually verify chrome os kernels and filesystems AFTER booting, from the command line?  (Wondering what commands one would run to do that...)

If the box is rooted obviously such checks can't be trusted, but still...  the root kit would have to make sure to cover those tracks and I'm wondering if that might not be so easy?  Maybe one could even have some few scripts/binaries on a USB thumb drive to run that one can trust, in combination with the read only firmware that one can check against, post boot in dev-mode?

The gist: run stock Chrome OS on a chrome device in dev-mode (getting command line access), and still do some kernel/root fs verification yourself (since it's not done during the boot sequence).  Best of both worlds ("verified dev-mode").

Actually, by default when you enable developer mode, you still get a read-only rootfs with verification. You can turn that off by using make_dev_ssd, but it requires an extra step.

and to the point of malicious software, you need to reboot the system after running `make_dev_ssd` before the kernel will allow you to mount the rootfs in write mode.  once verity mode kicks in, you can't go back.

of course, this doesn't stop code from modifying the partition directly via /dev/.  the kernel will probably crash or throw errors when encountering out of sync behavior, and at next boot (if verity is still on), the modification will be detected.

Minor comment/addition:

The change won't be detected until the block is brought in from disk, which is done on demand whenever files from that block are read from disk, not necessarily at boot time. So if a block contains a file that is never or rarely read, it might go undetected for some time.

The exception to this is read-ahead, which means that some blocks will be read in even if they're not accessed.

-Olof

[Mike Frysinger]

err, yeah.  for some reason i was thinking we read & verify the entire rootfs before executing it, but obviously that is not the case.  we verify entire disk blocks rather than other solutions which do verification on individual files.

-mike

[Trever]

I'm a bit puzzled.

Chrome device documentation states: "The developer switch enables the command line shell and deactivates part of the verified boot process."

Which part of the verified boot process is deactivated?

It almost sounds like you guys are saying that throwing the physical switch makes only one change:  it just gives you a shell, and from there you can change/enter developer mode BIOS, but until you do that, you're getting stock Chrome OS with ALL of the verification.  No?

Is there any change to updates with the switch on?  I've read something about BIOS updates won't happen....

[Randall Spangler]

On Mon, Oct 29, 2012 at 8:29 AM, Trever <trr...@gmail.com> wrote:

I'm a bit puzzled.

Chrome device documentation states: "The developer switch enables the command line shell and deactivates part of the verified boot process."

Which part of the verified boot process is deactivated?

Every Chromium OS kernel partition starts with a preamble which contains a SHA of the rest of the partition.

When the dev switch is off, the firmware checks a signature of that preamble, using a Google-supplied key stored in the firmware.  So only Google-signed Chrome OS kernels will work.

When the dev switch is on, the firmware will boot any valid Chromium OS formatted kernel partition, even if the signature doesn't pass.  It doesn't even care whether the data that follows is a Linux kernel, a chained copy of U-boot, etc.  It does still do the signature check, but it ignores errors.  If you're running stock Chrome OS, the OS checks the dev switch position via the crossystem utility to decide whether to enable the root shell.

If you've flipped your dev switch and want to check whether the booted kernel is stock Chrome OS, use 'crossystem kernkey_vfy'.  This will be "sig" if you have unmodified Chrome OS, or "hash" if you're running a kernel signed by someone other than Google (dev-signed, Hexxeh, etc.) or if you've disable rootfs verification with /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification.

- Randall

--
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

[T N]

crossystem kernkey_vfy

That's what I was looking for. Thanks!



Any comments on BIOS updates? Do they happen with the dev switch on?
I know the OS updates. Just wondering if any BIOS updates happen.

[T N]

Yep- knew about the two (read only being the bedrock of the verified
boot). But there's a lot floating around that says when Dev mode is
on, the read-write BIOS updates won't happen (including some official
Google documentation). You're saying they will happen.

Thank you.



On Mon, Oct 29, 2012 at 10:22 AM, Mike Frysinger <vap...@google.com> wrote:
> the system has two firmwares. the readonly one never updates automatically.
> the read/write one can still be updated as part of the system update.
> -mike

[Steve Pirk]

My Cr-48 is in dev mode, and I just got the latest version of Chrome OS from Google last night. Updates work like a champ.

My Acer Chromebook got it a day earlier, but it usually gets updates at least a few hours before the old Cr-48's do.

-- steve

[T N]

OS updates work for me too, but was wondering about the read-write
BIOS updates which apparently sometimes happen. I believe these are
much rarer than the OS updates? I don't think an OS update is always
accompanied by a BIOS update.

[Richard Barnette]

On Oct 29, 2012, at 11:22 AM, T N wrote:

> OS updates work for me too, but was wondering about the read-write
> BIOS updates which apparently sometimes happen. I believe these are
> much rarer than the OS updates? I don't think an OS update is always
> accompanied by a BIOS update.
>

Yes, RW firmware updates are quite rare. Also, I think in general for
units with the dev switch enabled, firmware updates aren't applied
automatically; you have to apply them manually.

I'm not familiar with all the technical details; I'm hoping someone who
knows more can chime in. However, in practice, the updates are rare
enough that some hardware may never see one, and even if your
hardware does get an update, you can expect that generally, your
unit will still work without applying it.

-- jrb

[T N]

I thought Mike was saying that the firmware updates ARE applied
automatically even with the dev switch enabled.

If that's not true then clarification would be good.

[Hung-Te Lin]

Due to developer firmware design changes, the updater's behavior is different per device.

On Acer AC700 and Samsung Series 5, developer mode will turn off firmware updating.

On all other Chromebooks, firmware updating may be triggered in developer mode.

[T N]

Okay, thank you. So stumpy will update.

Is there anyway for us ("John Q. Public") to know this other than
documentation and/or this list or similar? I think the firmware
source involved is closed source? Mostly I ask because design changes
obviously suggests it could change again, depending on device and
(perhaps?) within the life of a particular device?

[Hung-Te Lin]

When I mention the "firmware design", I mean the verified boot firmware design. That part is open source and you can find in src/platform/vboot_reference folder.

To be more specific, it's the "signing firmware with DEV-boot-only" feature, which you can find the "dev-only" keyblocks.

Regarding the logic of firmware updating, check src/platform/firmware/pack_dist/update*.sh, which is branched and matched to different firmware designs in vboot_reference.

[T N]

Okay, great! Thank you.

[Trever]

Well I'm still confused.

What is the difference between a chrome device that only has the developer mode switch activated, and one which has the developer mode switch activated AND has the developer mode bios enabled?

As I understand the documentation at chromium.org, it *could* be that the developer mode switch only activates the shell/root access.  Once you have that, then if you choose (and perhaps if an attacker chooses and somehow figures out a way to do it), you can run the commands from the shell that install a different ("developer mode") mode BIOS to boot kernels that are not stock (i.e. not signed by Google with the private Google key).  But with ONLY the developer mode switch activated and no other changes (no developer mode BIOS), only stock Google kernels will boot.  In other words, as far as verified boot goes, there arguably isn't much security difference between stock and stock-with-dev-mode-switch-activated-but-NO-dev-mode-BIOS.  This is consistent with some of the original replies to this thread, it seems, and for my use case, it's useful to have a "verified dev-mode", but whatever.  

And BTW, thank you for your patience... I am looking at the code, but that's an ongoing effort of "dis-assembly"...

Trever

[Trever]

Perhaps this will help clarify my confusion:  what is the point of the developer mode BIOS, if it's not to allow bogus and/or non-google signatures?

Based on reading the documentation, as I understand it, the verified boot sequence is:  read only bios verifies read-write bios, read-write bios verifies kernel, kernel (dm-verity) verifies filesystem (as it uses it).  

It seems like there are two read-write bios'es accordingly:  

(1) stock read-write BIOS, which only boots kernels that only Google can distribute

(2) dev-mode read-write BIOS which doesn't care what signed the "kernel"

And as I understand, BIOS #2 is installed not by enabling the dev mode switch (physical, or virtual on the ARM chrome OS devices), but rather by issuing a command AFTER enabling the dev-mode switch, and only by running the command (well, omitting other hardware reprogramming possibilities- but usually by running the command from the shell in chrome os).

If that's not true I'm not sure what the point of the different BIOS's is and I'm not clear enough in my understanding of the basics of verified boot.

[Mike Frysinger]

there isn't a dedicated BIOS.  the firmware checks the state of the dev mode switch and changes behavior as appropriate.

-mike

[T N]

So....

http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-chromebook

Is invalid? This isn't true?: "run the command to install the
developer-mode BIOS"

[Mike Frysinger]

i'm pretty sure that just toggles a setting in the nvram.  it doesn't flash a brand new bios from scratch.  so the wording in the documentation is just a bit misleading as to what it is actually doing.

-mike

[Hung-Te Lin]

A little correction here.

Mike's correct for newer models - USB booting is controlled by a flag in NVRAM.

However, for older models like Samsung Series 5, which is exactly the given link, we do re-flash a "developer firmware".

So back to the original question:

> what is the point of the developer mode BIOS, if it's not to allow bogus and/or non-google signatures?

  It allows booting non-Google signed kernel from USB/SD (aka, Ctrl-U) -- and may add more developer-friendly features in future.

  The standard firmware only allows booting non-Google signed kernel from SSD in developer mode, not USB.

  The developer mode firmware is merged to standard BIOS in newer models, so now you only need to change a NVRAM setting to get Ctrl-U.

[Trever]

Okay, so the standard firmware does allow booting non-Google signed kernel.

Wasn't the answer I was hoping for but no matter...

Thanks!

[Trever]

With the kernel/fs signatures and the read only key burned in the firmware, it would be cool to see if you could still (post boot) detect root kits and such with the same level of assurance as stock verified boot gives you.  (Whatever assurance that is.)  The Chrome device "infrastructure" seems like it would make possible a USB drive with tools that a root kit couldn't fool, etc..  Where I started with this thread.

I personally like turning off the verified boot so that I have the stock Chrome OS but also with the shell.  Because stock Chrome OS has pretty much what I need (find, ls, mv, cp, sed, awk, curl, vim, etc..).   I don't need to hobby up my own distro (UGH!), just need the stock shell (and Chrome OS browser land).  Allows me eg. to move eon's of ASCII documentation to my chromebox and use my converter (ascii2gocs) over time to put everything in the Google cloud at my leisure, while still being on the chrome device and having the relative security of that.  Whatever.  But it's a bit of a whince to lose the verified boot.  

Going to a conference this weekend where things like the verified boot are important ("bad network neighborhood")!

Oh well...  thank you!!!

Trever

[Mike Frysinger]

with newer systems, you can take apart the case and toggle the RO firmware to RW.  then build your own firmware with your own key and then sign your images with your own key.  then you get verified boot from start to finish.

i'm not sure if this is possible with the older ones w/closed source firmware.  maybe it'd be possible to just extract them and then overwrite just the key in the image itself ...

no one has generally asked for this so we haven't spent too much time on documenting things ...

-mike

[Trever]

That's an ideal do-it-yourself setup, was wondering about that.  Thanks.  More documentation there would be great because I think putting your own key in the firmware is what most hackers will wonder about first.  Again, it's the natural approach.  Self signed end-to-end essentially.

I may try that, but for me, I have too many hobbies already.  The point I was quite the opposite.  I really LIKE the stock Chrome OS, and the hardware is just fine.  Point is, I can buy something that just works (for me).  

That's the whole point.  I love the product.

But what I would love is to have the stock command line environment without having to give up verified boot, and without having to go to the extreme of rolling my own (as you suggest) end-to-end...

[Mike Frysinger]

unfortunately, i don't think that will happen.  if you can access the command line, then so can people with malicious intent.  verified mode is meant to be as secure as possible w/out impacting the web based experience.  local command line is not part of the web based experience, thus it gets chucked.

-mike

[Trever]

Yes, I understand that.  And in general, even the slimmed down linux command line departs entirely from the use cases the chrome device is targeted for, to say the least.  It's just nice that it's there and there are use cases (for some of us) for it, of course.  And having that within the off-the-shelf-verified boot environment would be extra special.

What I really want it to be able to work with plain text better from the chrome browser land.  Wouldn't so much need the command line then.  I saw mini-code-edit web app being used at I/O, but that doesn't seem to be fully cooked yet.  Maybe that's another thread...

[Randall Spangler]

On Wed, Oct 31, 2012 at 11:49 PM, Trever <trr...@gmail.com> wrote:

With the kernel/fs signatures and the read only key burned in the firmware, it would be cool to see if you could still (post boot) detect root kits and such with the same level of assurance as stock verified boot gives you.  (Whatever assurance that is.)  The Chrome device "infrastructure" seems like it would make possible a USB drive with tools that a root kit couldn't fool, etc..  Where I started with this thread.

Once you've booted, you can't tell if a root kit was used to boot the system (or has subsequently been installed by someone at your root shell when you weren't looking).  Crossystem gets its information through kernel calls, so a rootkit kernel can simply lie.

 

I personally like turning off the verified boot so that I have the stock Chrome OS but also with the shell.  Because stock Chrome OS has pretty much what I need (find, ls, mv, cp, sed, awk, curl, vim, etc..).   I don't need to hobby up my own distro (UGH!), just need the stock shell (and Chrome OS browser land).  Allows me eg. to move eon's of ASCII documentation to my chromebox and use my converter (ascii2gocs) over time to put everything in the Google cloud at my leisure, while still being on the chrome device and having the relative security of that.  Whatever.  But it's a bit of a whince to lose the verified boot.  

If that's all you need, you can do the following:

1) Turn the dev switch on

2) Set a root password

3) From a root shell, run:

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, but you'll still have your root shell.

- Randall

[Randall Spangler]

On Thu, Nov 1, 2012 at 10:41 AM, Randall Spangler <rspa...@chromium.org> wrote:

On Wed, Oct 31, 2012 at 11:49 PM, Trever <trr...@gmail.com> wrote:

With the kernel/fs signatures and the read only key burned in the firmware, it would be cool to see if you could still (post boot) detect root kits and such with the same level of assurance as stock verified boot gives you.  (Whatever assurance that is.)  The Chrome device "infrastructure" seems like it would make possible a USB drive with tools that a root kit couldn't fool, etc..  Where I started with this thread.

Once you've booted, you can't tell if a root kit was used to boot the system (or has subsequently been installed by someone at your root shell when you weren't looking).  Crossystem gets its information through kernel calls, so a rootkit kernel can simply lie.

 

I personally like turning off the verified boot so that I have the stock Chrome OS but also with the shell.  Because stock Chrome OS has pretty much what I need (find, ls, mv, cp, sed, awk, curl, vim, etc..).   I don't need to hobby up my own distro (UGH!), just need the stock shell (and Chrome OS browser land).  Allows me eg. to move eon's of ASCII documentation to my chromebox and use my converter (ascii2gocs) over time to put everything in the Google cloud at my leisure, while still being on the chrome device and having the relative security of that.  Whatever.  But it's a bit of a whince to lose the verified boot.  

If that's all you need, you can do the following:

1) Turn the dev switch on

2) Set a root password

3) From a root shell, run:

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, but you'll still have your root shell.

Caveat: those flags only work on newer Chromebooks.  I don't remember off the top of my head if Samsung Series 5 supported dev_boot_signed_only.  We added the feature a year ago in these commits.

- Randall

[Trever]

THERE!  Thank you!!!  Awesome.

(Re root kits... there are tools on other OS's that reputable security people do trust to do a pretty good job of detecting if your box is rooted... but I hear what you're saying.  In theory, once you're root kitted, all bets are off.  But in practice?....)

I am still curious what a shell does to Chrome OS security when running like you just specified ("verified dev-mode", I'll call it).  Assuming no one gets physical access to my device(s)... 

But I imagine that's a bit unknown.  Who knows what a hacker can do?

I will put some of the information from this thread on the Chrome OS twiki and give the link.  If people could check that for technical accuracy when it's done, would be appreciated.  Then you can just point people to the doc.  

I wish Google would hire the Chrome OS team some tech writers....

[Richard Barnette]

On Nov 1, 2012, at 10:53 AM, Trever wrote:

> THERE! Thank you!!! Awesome.
>

> (Re root kits... there are tools on other OS's that reputable security people do trust to do a pretty good job of detecting if your box is rooted... but I hear what you're saying. In theory, once you're root kitted, all bets are off. But in practice?….)
>
In practice, it's at least as hard to break into a Chrome OS system as
any stock Linux system, and the tools for detecting a root kit ought to be
portable to Chromium OS. However, if you don't want/need to install
custom software bits, you're probably more secure booting a verified,
Google-signed Chrome OS image.


> I am still curious what a shell does to Chrome OS security when running like you just specified ("verified dev-mode", I'll call it). Assuming no one gets physical access to my device(s)…
>
The shell doesn't actually do anything: It's there in the system with
or without dev mode. What dev mode does relative to the shell
is 1) enables switching to VT2, and 2) enables access to bash from
an in-browser terminal.

Changing to dev mode doesn't open up any network ports, so turning
on dev mode doesn't add to the attack surface unless the bad guy
gets physical access.

Security-wise, turning on dev mode costs you these things (that I know
of):
1) Attackers that get physical access may have ways to break into
your system that weren't there before, and
2) If an attacker can get sufficient access (with or without physical
access), he can install a root kit, or some equivalent, and your
system could still boot.

If you keep your Chromebook physically secure, you don't have to
worry about 1), and 2) is really hard to do even with physical access
(and harder without it).

-- jrb

[Hung-Te Lin]

It sounds like "is there any way to get command line prompts for tools in verified mode"?

Since all you need is "command line" instead of "the real OS that is running", I wonder if that can be replaced by a sandboxed virtual Linux,

ex: http://bellard.org/jslinux/

[Trever]

On Thursday, November 1, 2012 11:22:01 AM UTC-7, Richard Barnette wrote:

On Nov 1, 2012, at 10:53 AM, Trever wrote:

> THERE!  Thank you!!!  Awesome.
>
> (Re root kits... there are tools on other OS's that reputable security people do trust to do a pretty good job of detecting if your box is rooted... but I hear what you're saying.  In theory, once you're root kitted, all bets are off.  But in practice?….)
>
In practice, it's at least as hard to break into a Chrome OS system as
any stock Linux system, and the tools for detecting a root kit ought to be
portable to Chromium OS.  However, if you don't want/need to install
custom software bits, you're probably more secure booting a verified,
Google-signed Chrome OS image.

Only because I don't know the code and such, I can't speak to the implementation.  But the design of the verified boot seems much more trustworthy than running tools on a root kitted system, so from the security standpoint would rather have the verified boot. Yes- it's what I want.  There has to be a rationalization for buying the Chrome device hardware.  :-)

I have some chromeboxes (got for dirt cheap) that I will hack, probably starting with the USB boot.  Eventually (in theory) the possibility of burning my own keys into the firmware is intriguing... 

 

 2) If an attacker can get sufficient access (with or without physical
    access), he can install a root kit, or some equivalent, and your
    system could still boot.

Well wait a minute.  As I understand the ability to have a command line with verified boot (crossystem dev_boot_usb=0 dev_boot_signed_only=1 has been run and the dev-switch is on), the system won't boot (or it does something to alert user) if it's not a stock Google kernel.  No?  What's the point of the "dev_boot_signed_only=1" argument if there's no effect when the firmware detects that the kernel isn't a Google signed kernel?

Because the dev-switch is on, I realize the system is already alerting the user at boot (the frowny face etc.).  But is there something that happens as well to alert that the kernel is not Google's?

[Trever]

I have seen that crazy/amazing jslinux thing before!  I don't know where people get the time...  :-)

No that won't do it.  

If in the Chrome OS stock terminal, I go into vi, and write the file I'm editing, and it is saved into Google Docs, I'd be happy.  (Saving to Google Drive doesn't work this way.) Preferably when I do :w!, it is even saved as a Google Document (not just a file), but whatever.  By analogy, the way that ssh works (as a web app) kind of deal, if that makes any sense at all.  If there were a vi web app that saves out to Google Drive, just as ssh is a web app that actually is working pretty darn well and feels like command line ssh, I'd be on cloud 9 in Google's cloud.  Throw in a source control tool or two... da bomb.

I bet these things will come, but waiting and waiting and waiting... painful.  I'm trying to find time myself to help create the things, but finding time is of course tough, especially when it's not paid time.

As it stands I had to hack together this thing:

http://code.google.com/p/ascii2gdocs/

Given ascii2gdocs and the command line access the developer switch allows, and finding in stock Chrome OS what I have found, I can get there.  And I can get there from any sufficiently equipped UNIX server.  It's not elegant though...

(I guess I should say, there are still other reasons why I want the Chrome OS command line, including just taking leisure time to study the thing and see what's what under the covers.)

[Richard Barnette]

On Nov 1, 2012, at 4:16 PM, Trever wrote:
[ … ]

> 2) If an attacker can get sufficient access (with or without physical
> access), he can install a root kit, or some equivalent, and your
> system could still boot.
>
>
> Well wait a minute. As I understand the ability to have a command line with verified boot (crossystem dev_boot_usb=0 dev_boot_signed_only=1 has been run and the dev-switch is on), the system won't boot (or it does something to alert user) if it's not a stock Google kernel. No? What's the point of the "dev_boot_signed_only=1" argument if there's no effect when the firmware detects that the kernel isn't a Google signed kernel?
>
> Because the dev-switch is on, I realize the system is already alerting the user at boot (the frowny face etc.). But is there something that happens as well to alert that the kernel is not Google's?
>

Guess I could have been clearer when I said "sufficient access":
If an attacker can break into your system and get root access
while dev mode is enabled, he can execute his own 'crossystem'
command to undo the settings, and install his rootkit. If verified
boot were on, the crossystem command wouldn't work, and
you'd be protected.

Note that breaking in and getting root access is still hard. And
again, turning on dev mode by itself doesn't make getting root
access any easier as long as you guard your Chromebook, and
don't open up any network ports.

[T N]

Pretty sure I understand what you're saying.

What you said made me wonder though, regardless of what threat model
we're assuming, I simply would like to know what happens if, in the
following order, assuming we start with a clean unhacked Chrome
device:
1. User enables dev-mode (physical switch or virtual on ARM units)
2. User successfully runs crossystem dev_boot_usb=0 dev_boot_signed_only=1
3. Something installs a non-signed Google kernel (perhaps it is a
rootkitted kernel) to the default kernel partition
4. User reboots (no other events have happened- in other words, dev
switch is still on and the dev_boot_signed_only=1 is still set)

What then? I can't test that easily without installing my own
non-Google signed kernel.

Since at step 4 the dev switch is still enabled and since verified
boot is on (dev_boot_signed_only=1) and since a bad kernel is queued
for boot, what happens?

We know we get the frowny face (I guess, need to try the crossystem
command here...). When the bad kernel is encountered, firmware boots
the remaining Google signed kernel? What if both kernels are hacked
(no good Google kernels- i.e. what if in step #3 something installs
two bad kernels)? Will the system refuse to boot? Go into recovery
mode? Or?

Thanks in advance! Parsing to this level of detail is useful, I believe!

[Richard Barnette]

On Nov 1, 2012, at 6:07 PM, T N wrote:

> Pretty sure I understand what you're saying.
>
> What you said made me wonder though, regardless of what threat model
> we're assuming, I simply would like to know what happens if, in the
> following order, assuming we start with a clean unhacked Chrome
> device:
> 1. User enables dev-mode (physical switch or virtual on ARM units)
> 2. User successfully runs crossystem dev_boot_usb=0 dev_boot_signed_only=1
> 3. Something installs a non-signed Google kernel (perhaps it is a
> rootkitted kernel) to the default kernel partition
> 4. User reboots (no other events have happened- in other words, dev
> switch is still on and the dev_boot_signed_only=1 is still set)
>
> What then? I can't test that easily without installing my own
> non-Google signed kernel.
>

Actually, it's not too hard to test, even without a custom kernel;
After you're in dev mode, there's a command you can run from
the shell prompt that will disable the verified root (check out
/usr/share/vboot/bin/make_dev_ssd.sh).

The problem with this (or with testing a custom image) is that
afterwards, the only way back to a verified system is to go through
recovery, which is more trouble than it's worth for a short experiment.

> Since at step 4 the dev switch is still enabled and since verified
> boot is on (dev_boot_signed_only=1) and since a bad kernel is queued
> for boot, what happens?
>

I haven't tested the specific feature, but I imagine you'll see the same
thing you'd see if verified boot were enabled. That exact experience
depends on whether you've got newer or older hardware, but basically,
you'll see a screen that says your system doesn't contain Chrome OS,
and you'll have instructions on what key to press in order to start
recovery.

> We know we get the frowny face (I guess, need to try the crossystem
> command here...). When the bad kernel is encountered, firmware boots
> the remaining Google signed kernel? What if both kernels are hacked
> (no good Google kernels- i.e. what if in step #3 something installs
> two bad kernels)? Will the system refuse to boot? Go into recovery
> mode? Or?
>

Someone with more experience with the firmware will need to weigh
in here; I think that if the system has an old, valid kernel it may try to
boot that before it gives up. In any event, if both images fail to pass
verification, you'll get the sad face firmware screen, and the opportunity
to go to recovery.

> Thanks in advance! Parsing to this level of detail is useful, I believe!
>
>
>
> On Thu, Nov 1, 2012 at 5:36 PM, Richard Barnette
> <jrbar...@chromium.org> wrote:
>> On Nov 1, 2012, at 4:16 PM, Trever wrote:
>> [ … ]
>>> 2) If an attacker can get sufficient access (with or without physical
>>> access), he can install a root kit, or some equivalent, and your
>>> system could still boot.
>>>
>>>
>>> Well wait a minute. As I understand the ability to have a command line with verified boot (crossystem dev_boot_usb=0 dev_boot_signed_only=1 has been run and the dev-switch is on), the system won't boot (or it does something to alert user) if it's not a stock Google kernel. No? What's the point of the "dev_boot_signed_only=1" argument if there's no effect when the firmware detects that the kernel isn't a Google signed kernel?
>>>
>>> Because the dev-switch is on, I realize the system is already alerting the user at boot (the frowny face etc.). But is there something that happens as well to alert that the kernel is not Google's?
>>>
>> Guess I could have been clearer when I said "sufficient access":
>> If an attacker can break into your system and get root access
>> while dev mode is enabled, he can execute his own 'crossystem'
>> command to undo the settings, and install his rootkit. If verified
>> boot were on, the crossystem command wouldn't work, and
>> you'd be protected.
>>
>> Note that breaking in and getting root access is still hard. And
>> again, turning on dev mode by itself doesn't make getting root
>> access any easier as long as you guard your Chromebook, and
>> don't open up any network ports.
>>
>>
>>> --
>>> 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
>>
>>
>>

-- jrb

[Trever]

I enabled dev_boot_signed_only=1 on a stumpy box and that does seem to kick in a normalish verified boot.  While there is a long pause before boot (I guess the 30 second pause) and a beep about half way through that pause, I do not get the frowny face with the message saying: "Chrome OS verification is turned off.  Press space to begin recovery"

So it would be interesting to know (anyone?) what happens when various kernels are installed that are not signed by Google (ie. if the default kernel is not, if the standby is not, if both are not).

Presumably normal verified boot behavior but yes- a bit of a hassle to test myself.

[Trever]

...finally, if what I seemed to see (and not see) on the screen during boot with the dev-mode switch enabled but the verified boot toggled on comes out of firmware, doesn't this mean that if you're physically sitting at the device watching, you know you have a verified boot?  No rootkitted kernels and/or changes to your boot preference settings possible?

[Mike Frysinger]

if verified boot is enabled, then you can be fairly confident that the system is not rooted.  in order to break the chain of trust, someone would have to disassemble your machine, toggle the read-only firmware to read-write, install their own custom modified firmware, and then  re-assemble the device.

while it's possible with enough time, it's not trivial.

-mike

[Trever]

That's the verified boot theory- yep.

So I'll assume that if the amount of time that has passed during boot is correct, and a user does NOT see the "Chrome OS verification is turned off.  Press space to begin recovery" message, they can be certain the chain of trust has not been broken, including that no one has spoofed/covered messages at the physical console to cover that verification has been toggled off behind the user's back, etc..  I guess that message is burned in the read only firmware or that the chain works in such a way that if you don't see it and the amount of time passed is correct, you know you have an unbroken chain of trust (ie. a true verified boot).

(I realize other things are more likely to bite you in terms of security than worrying too much about all of this... but verified boot is not trivial to lose- it's good to have IMHO.)

Based on https://gerrit.chromium.org/gerrit/gitweb?p=chromiumos/platform/vboot_reference.git;a=commit;h=fa9d7782e837848a1aeb0e95295fa48ac23f7a26, it seems the older generation had the same dev-mode verified boot feature- i.e. you had to install the dev-mode bios to break verified boot (not just toggling the physical switch).  It seems you guys just changed the way you do it.  I can't test that easily but if someone knows and can chime in, I'll add it to the public TWIKI.

Thanks for all the information and staying with the thread!

Trever

[Trever]

I have added some documenation to the Chrome OS Wiki, if anyone wishes to check it for technical accuracy or pass on additional information:

https://sites.google.com/site/chromeoswikisite/home/tips-and-tricks/shell-acess-with-verified-boot

[Ottavio Caruso]

On 2 November 2012 20:36, Trever <trr...@gmail.com> wrote:
> I have added some documenation to the Chrome OS Wiki, if anyone wishes to
> check it for technical accuracy or pass on additional information:
> https://sites.google.com/site/chromeoswikisite/home/tips-and-tricks/shell-acess-with-verified-boot

Thanks for this page Trever.

Maybe unrelated to technical aspect of this discussion, but I wonder
if tinkering with dev mode would invalidate the warranty of the
device. I've read scary stories about not being able to restore to
default after playing with dev mode. I wonder if there's any truth in
this. Thanks

--
Ottavio

[Trever]

I'm quite sure that's not true.  Cracking open a case physically will
void your warranty, but dev mode is there to be used.

Furthermore, in any worst case situation, you can always go back to a
clean slate using recovery mode.

[Mike Frysinger]

obviously the final say is between the computer manufacturer (e.g. samsung) and you, so read the fine print that was in the box with the chromebook, but i'd lean towards what Trever said.

as long as the read-only firmware is intact, the system is designed so that you can nuke the entire drive, turn the dev switch off, and still be able to recover.  this page details that process:

http://support.google.com/chromeos/bin/answer.py?hl=en&answer=1080595

-mike

--

[Trever]

Turns out my KVM was doing funny things.

On my stumpy box, if I have dev_boot_signed_only=1, I still get the frowny face saying verified boot is off and to press space for recovery mode.

It seems to be this is a bug.  Whether or not I have dev mode enabled, the ability to toggle dev_boot_signed_only to re-enable verified boot to me means something like this:

1.  If I have enabled developer mode, maybe the long pause and beeps should happen, but

2.  If I have re-enabled verified boot using dev_boot_signed_only=1, it seems to me that even though developer mode is still on, I shouldn't see the screen saying it's off.  How about darkness, if not a screen saying you're in dev mode, while the pause and beeps happen?

I will file a bug report.

On Thursday, November 1, 2012 8:20:15 PM UTC-7, Trever wrote:

[Trever]

Sorry, for 2 meant:

2. If I have re-enabled verified boot using dev_boot_signed_only=1, it seems to me that even though developer mode is still on, I shouldn't see a screen saying verified boot is off, because it's not.  Etc.

[Trever]

The significance of this silliness is a way to know if verified boot has been turned off behind your back.  In theory, it can't be turned off behind your back if you haven't enabled developer mode so you don't have this concern.  (I guess?)  If I am in dev mode, I'd like to have the screen tell me correctly if verified boot has been turned on or not.  Yes?

I'm not necessarily that paranoid because we're talking about possibly impossible hacks anyways (famous last words?), but I'm not the only person I know who likes the "logical purity" (for lack of a better word) and indeed the feeling of assurance that this whole chain of trust from a read only key gives you.  It's nice.  So it'd be very nice if the displays corresponded to what's happening beneath.

[Trever]

I hope I'm not wearing out patience, I'm still curious.

Let's assume that no one has replaced the stock RO firmware chips and/or reprogrammed them as apparently is possible in new hardware (the ability to install your own root key in the RO firmware after physically toggling it to RW).  

Under normal stock firmware conditions (no reprogramming), is it impossible for any portion of the firmware to be replaced with something unsigned by Google and stay out of Recovery mode?  I'm wondering if it is impossible to break the verification until you get to the kernel (dev mode, verified boot off).   In other words impossible to break the verification between what was once described as the RO firmware and the RW firmware (I gather things are unified now)?

Another way of putting it is whether it is possible under stock hardware configuration in dev mode for the BIOS to lie about whether a verified boot is in progess... i.e. we're booting in dev mode, we see that dev_boot_signed_only=1 by hitting TAB, and we know that can't lie?  Do you know it's a verified boot if you see the correct settings there because you know the firmware can be trusted assuming it hasn't been royally hacked (i.e. reflashed)?

I probably seem obsessed... maybe but I think more so obsessed with trying to understand how it all works.  

Another question is whether the firmware can be flashed/reprogrammed from Chrome OS userland (a) ordinarily and/or (b) if you've physically opened the case and changed a switch/jumper alluded to above in current Chrome devices.  This question is because I'm wondering how to install my own keys, but also about security limitations or strengths of the design.

[Mike Frysinger]

On Thu, Nov 8, 2012 at 2:52 AM, Trever <trr...@gmail.com> wrote:
> Under normal stock firmware conditions (no reprogramming), is it impossible
> for any portion of the firmware to be replaced with something unsigned by
> Google and stay out of Recovery mode? I'm wondering if it is impossible to
> break the verification until you get to the kernel (dev mode, verified boot
> off). In other words impossible to break the verification between what was
> once described as the RO firmware and the RW firmware (I gather things are
> unified now)?

the RO firmware is RO because a hardware pin is being latched. as
long as that pin is latched, it should not be possible for software to
write to the flash where the RO firmware lives.

i don't have a schematic, but i suspect the jumper on the ARM
chromebook sits directly on the SPI flash's Write Protect line (WP).
since that's a physical line, the SPI flash itself rejects write
attempts even if the software were compromised and attempted it.

> Another way of putting it is whether it is possible under stock hardware
> configuration in dev mode for the BIOS to lie about whether a verified boot
> is in progess... i.e. we're booting in dev mode, we see that
> dev_boot_signed_only=1 by hitting TAB, and we know that can't lie? Do you
> know it's a verified boot if you see the correct settings there because you
> know the firmware can be trusted assuming it hasn't been royally hacked
> (i.e. reflashed)?

obviously no one can make a claim such as "it is impossible to break
the software chain of trust". the only thing we can do is point you
to the docs that show how the system is designed and then point to the
source where we've attempted to implement that design. in our
opinion, when you have the RO firmware locked down and the dev mode
switch disabled, the chromebooks are pretty much state of the art when
it comes to the security system and being able to trust them,
especially for a consumer device.

note that in many places, the security of the system is multi-layered
and not just relying on a single link. examples of the top of my
head:
- the rootfs is hashed & cryptographically verified & mounted read-only
- the kernel does not allow the rootfs to be mounted read-write
- set*id applications are minimized if not completely thrown out
- all applications are compiled as PIEs with SSP (stack protection)
and fortified source defines as well as other "hardening" measures
(such as runtime ASLR)
- this is just what we do w/ChromeOS -- it doesn't cover all the
security layers that Chrome itself implements

certainly we welcome researchers to analyze our designs and
implementations and point out issues so that we can adjust and make
people even more secure.

> Another question is whether the firmware can be flashed/reprogrammed from
> Chrome OS userland (a) ordinarily and/or (b) if you've physically opened the
> case and changed a switch/jumper alluded to above in current Chrome devices.
> This question is because I'm wondering how to install my own keys, but also
> about security limitations or strengths of the design.

the system design is geared towards making physical access
annoying/time consuming so as to prevent/discourage "drive by"
attacks. it is not geared towards preventing people who have physical
access and lots of time (as measured in hours/days) from taking the
machine apart, flashing their own code, and then buttoning it back up
so that the runtime "looks" like ChromeOS but isn't really. anything
that makes that harder also makes it harder for legitimate users --
people who bought the hardware and so deserve to completely own it and
do as they see fit. if you want a locked down proprietary platform,
i'm sure there are plenty of other companies out there willing to take
your money (i'll refrain from naming any for obvious reasons).

once the hardware jumper has been disabled and the RO firmware is no
longer RO, simply enabling dev mode gets you access to programming the
firmware. on most (all?) devices, we use flashrom, and the ARM
chromebook is no exception. you can use it to dump the RO firmware
via /dev/spidev1.0 or, if the jumper is disabled, program something
else in there. note that dumping (reading) can be done simply with
the dev mode switch toggled.

the SPI flash (a Winbond W24Q32DW iirc) here is a pretty common
embedded paradigm.

HTH
-mike

[Trever]

Thank you, some good info there (especially about the Winbond programming + jumper).

From a security perspective, I guess I no longer see a difference between dev-mode with verified boot and stock Chrome OS device (i.e. no dev mode), if we make certain assumptions:

1.  I always start from power off, boot the device and hit TAB to visually affirm the boot is verified (the visual confirmation seems important, whereas it would not be outside of dev mode).

2.  I know nobody else has physical access to the device except when the unit is powered off and/or I am logged out completely.

Given the verified boot and the encryption, it seems to me I always know (a) what I'm running and (b) no one can get my data (it's encrypted).  At least that seems true if dev_boot_signed_only=1 and I always follow #1 + #2 above.

Dev mode gives access to shells (chronos and root) from the physical device.  So what?  Seems to have no consequences from a security standpoint, given a re-enabled verified boot and that we always do 1 + 2, but perhaps I'm not understanding.  Perhaps (eg.) flipping on dev mode makes it theoretically possible for any existing remote exploit to escalate to root that otherwise is not possible, but I'm not sure that is true.  And if it is true, so what?  I guess in that case it might be possible to remotely de-activate verified boot and install a kernel that lies, but the reason I asked the question about whether the firmware can lie is that even if someone were somehow able to do this, they would be defeated in step #1, because we'd see verified boot is off from the firmware.  The attacker is caught.  Unless a remote root can make it so the firmware (i.e. TAB) lies to me in step #1.

Maybe I'm leaping ahead too many steps and this gets too speculative.  

But again, I don't see how dev-mode alone changes much of anything from a security standpoint, if I follow precautions as outlined here after re-enabling verified boot.   (And if my assessment of the relative risks is correct, the need to verify things post boot-- which I started this thread inquiring about- becomes obviated.  Yay!  Hopefully this fully clarifies what I'm going on about.)

I'm certainly NOT asking the Chrome OS team to sign off on things their lawyers would never allow, nor asking them to make assurances no one can make, go beyond "bright line" tests that are the engineering practice in house, etc..  I'm just looking to see if I'm understanding the basic theoretical workings underneath, so that quite possibly, what I'm saying could be true.

Perhaps at this point my question is more:  what does activating dev mode do, EXACTLY, at the account/shell/getty level (I guess that's where it would take effect...)?  I have to dig in enough to figure this out, but I'll just throw that out there at this point...

Trever

[Trever]

Just to be clear (I think this is obvious, but):

Below I'm also assuming reasonable Chrome OS device threat models.  That is, if MI6 takes my Chromebook overnight and modifies it, well then dah- all bets are off.  Not worried about those kinds of threat models here.

[Mike Frysinger]

On Wed, Nov 14, 2012 at 12:28 AM, Trever <trr...@gmail.com> wrote:
> Dev mode gives access to shells (chronos and root) from the physical device.
> So what? Seems to have no consequences from a security standpoint, given a
> re-enabled verified boot and that we always do 1 + 2, but perhaps I'm not
> understanding.

shell access allows you to easily download files from anywhere &
modify stuff Chrome itself uses. you get direct access to persistent
storage which means someone walking by can much more easily install
something that attacks Chrome itself (such as a rogue extension). or
run `sudo su -` and attack the persistent storage used by ChromeOS
daemons (such as the network or power manager).

thus, for users that have no interest in the stuff dev mode enables,
shell access is a pointless gaping hole.

> Perhaps at this point my question is more: what does activating dev mode
> do, EXACTLY, at the account/shell/getty level (I guess that's where it would
> take effect...)?

scripts can probe the dev mode switch at runtime and choose to
enable/allow things. this is how crosh knows what commands to allow
you to access such as `shell`.

off the top of my head, i don't know what all in the system changes
based on that flag. i imagine you could grep for 'crossystem' and get
some decent results.
-mike

[Trever]

On Tuesday, November 13, 2012 10:20:44 PM UTC-8, Mike Frysinger wrote:

shell access allows you to easily download files from anywhere &
modify stuff Chrome itself uses.  you get direct access to persistent
storage which means someone walking by can much more easily install
something that attacks Chrome itself (such as a rogue extension).  or
run `sudo su -` and attack the persistent storage used by ChromeOS
daemons (such as the network or power manager).

thus, for users that have no interest in the stuff dev mode enables,
shell access is a pointless gaping hole.

Hmmm... 

Allows "you" to easily download files...  Who?  Me, or remote attacker?

If you mean remote attacker... So this remote attacker now has different abilities than a remote attacker has when dev-mode is off?  

Seems like even when the dev mode is off, the shell is there... the binary is on the system and could be made to run uid=whatever-was-running-that-got-hacked   But perhaps I'm mistaken.

If you mean me.... we're assuming I'm not attacking, I alone have physical access to the device while I'm logged in (no one can have a tty shell other than me as long as I'm logged in precisely because I'm logged in and using the device and I'm not sharing it physically while I'm logged in- I fully log out when I give up the device), and every time before I log in, I start from power down and verify it's a verified boot (so anything installed while someone else used the device is caught).  Also assuming (in case it wasn't clear) that anyone accessing the device while I'm not using it doesn't crack open the case or otherwise mod the firmware.

[Trever]

To clarify (again)... I'm not worried about someone walking by an open session.  We assume I'm a relatively sophisticated user running in dev-mode.  I don't lock the device when I go for the bio break.  I fully log out.  Etc..

Seems like the gaping hole you refer to is for someone having physical access, but even that seems a little tricky.  Shell requires password at Ctrl-Alt-F2 if the screen is locked, for example.

But maybe you're also referring to remote attacks....

[Richard Barnette]

On Nov 13, 2012, at 10:40 PM, Trever <trr...@gmail.com> wrote:

On Tuesday, November 13, 2012 10:20:44 PM UTC-8, Mike Frysinger wrote:

shell access allows you to easily download files from anywhere &
modify stuff Chrome itself uses.  you get direct access to persistent
storage which means someone walking by can much more easily install
something that attacks Chrome itself (such as a rogue extension).  or
run `sudo su -` and attack the persistent storage used by ChromeOS
daemons (such as the network or power manager).

thus, for users that have no interest in the stuff dev mode enables,
shell access is a pointless gaping hole.

Hmmm... 

Allows "you" to easily download files...  Who?  Me, or remote attacker?

Anyone with physical access can get to VT2.  If there's no password

for 'chronos', or if you're already logged in, someone with physical

access can get a shell prompt.

If you mean remote attacker... So this remote attacker now has different abilities than a remote attacker has when dev-mode is off?  

Seems like even when the dev mode is off, the shell is there... the binary is on the system and could be made to run uid=whatever-was-running-that-got-hacked   But perhaps I'm mistaken.

As you say, if a remote attacker can exec arbitrary code, he can

exec /bin/sh regardless of the setting of the dev mode switch.

Mike mentioned that scripts can check the setting of the dev mode

switch, and change system behavior based on the check.  I can tell

you a few places in the source to look to see the kinds of changes

entailed:

  * In /sbin/chromeos_startup, the script will bind mount "dev_image"

    in the stateful partition as /usr/local if the source directory exists.

  * Also in /sbin/chromeos_startup there's a check to see if the switch

    has changed since the previous boot, in order to wipe the stateful

    partition.

  * In /sbin/xstart.sh, the X server is started with options that enable

    or disable VT2 based on the setting of the dev mode switch.

  * In /etc/init/hotkey-access.conf (an upstart job), the SysRq keys the

    kernel will recognize are determined based on the setting of the

    dev mode switch.

  * In /usr/bin/crosh, dev mode enables some additional commands,

    including direct shell access.

There are also checks during install and recovery, but these won't

affect already installed software.

If you mean me.... we're assuming I'm not attacking, I alone have physical access to the device while I'm logged in (no one can have a tty shell other than me as long as I'm logged in precisely because I'm logged in and using the device and I'm not sharing it physically while I'm logged in- I fully log out when I give up the device), and every time before I log in, I start from power down and verify it's a verified boot (so anything installed while someone else used the device is caught).  Also assuming (in case it wasn't clear) that anyone accessing the device while I'm not using it doesn't crack open the case or otherwise mod the firmware.

 

> Perhaps at this point my question is more:  what does activating dev mode
> do, EXACTLY, at the account/shell/getty level (I guess that's where it would
> take effect...)?

scripts can probe the dev mode switch at runtime and choose to
enable/allow things.  this is how crosh knows what commands to allow
you to access such as `shell`.

off the top of my head, i don't know what all in the system changes
based on that flag.  i imagine you could grep for 'crossystem' and get
some decent results.
-mike

[Trever]

Well it's sounding like I'm correct:  given certain disciplined use practices, there's no security implications of having dev-mode on.  For most users, of course- it's bad.  But if someone is disciplined and adheres to logging out when not physically at the Chrome OS device, and adheres to starting each new login from power down and checking that verified boot is on (from the BIOS), the security situation is same as dev-mode off.

THANK YOU for the pointers on where to look.  Just what I was looking for.  I'm assuming that init is PID=1 and init goes through /etc/init.d/...  but I think now we're into topics that belong in a different thread.

Trever