[PSA] disabling shell script usage on noexec mounts

[Mike Frysinger]

this is more of a pre-psa as the CLs are still in progress, but tests are passing, so we're aiming for M64 or M65

tl;dr: if you have shell scripts on noexec mounts and you try to execute/source them, we're taking that away from you

bug: https://crbug.com/569168

CrOS has long mounted many paths as "noexec" so that arbitrary programs can't be copied to them and executed.  we've only permitted execution from the rootfs, and when in dev mode, /usr/local.  for direct execution, this works great.  however, we've been bit a couple of times now by people managing to execute shell code out of noexec mounts because the shell itself doesn't care.

a summary of existing behavior:

- direct execution like `/run/test.sh` and `/tmp/test.sh` are blocked via the noexec mounts (great!)

- indirect execution are permitted everywhere like `sh /run/test.sh` or `sh -c "source /run/test.sh"`

we're going to update the shell so that it checks the source of the script and checks the "noexec" markings itself and refuses to load code.  scripts in / and /usr/local will continue to work (as they are both mounted "exec").  we also continue to permit people to run code via pipes (e.g. `cat /run/test.sh | sh`) until we can figure out how to support the programs using this functionality (namely upstart).

if this change will adversely affect you or code in CrOS, now is the time to highlight things.

note: we're aware that our changes are not a magic bullet.  you can still bypass things by running `sh -c "$(cat /run/test.sh)"`.  the goal here is to block inadvertent bugs (tricking rootfs scripts from sourcing code on noexec points which has happened), and to make things more difficult for attackers (instead of allowing any escape to go directly to shellcode).  we're also going to look at disabling more shell features when running in verified mode vs dev mode.

-mike

[Keith I Myers]

I wonder if this will impact the use of things like crouton. I know this is not the place to discuss unsupported third party products but I do know it is quite popular and may drive some bad press. 

Crouton specifically does execute from /tmp/XXXXXX-installer-cache/ (XXXXXX being the crouton release string)

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

---
You received this message because you are subscribed to the Google Groups "Chromium OS dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-dev+unsubscribe@chromium.org.

--

Keith I Myers http://KMyers.me +Keith I Myers Mobile : (305)-929-3475

[Mike Frysinger]

[ +drinkcat, +dnschneid ]

iiuc, crouton is mostly hosted out of /usr/local, so that'll continue to work.  if it relies on /tmp being executable for shell scripts, that will break.  crouton will have to adapt to using paths like /usr/local/tmp i think.

-mike

[David Riley]

This will affect my new quick provisioning code which currently is fetching a provision script from the devserver to /tmp and then executing it with "bash /tmp/quick-provision".

[Mike Frysinger]

test images remount /tmp with exec support, and afaik, autotests require a test image, so that won't be an issue

-mike

[David Schneider]

Chromium OS of course doesn't guarantee any compatibility with or support for crouton, but since you asked:

The crouton installer is canonically run via "sh ~/Downloads/crouton".  If this breaks, every single tutorial, forum post, and doc on crouton will be broken.

The installer then downloads, extracts, and caches the installer into a subdir of tmp, then runs "sh /tmp/whatever/installer/main.sh".  This will be broken if the above is broken.  We can move the cache to a subdirectory in /usr/local, but that prevents crouton from being able to download as non-root (a minor use-case; primarily good for spitting out help text without having to run as root).  This also means people who have stale crouton scripts in their Downloads folder will have obscure error messages and have to re-download.  The reason we have this two-stage installer is because people were keeping stale crouton scripts downloaded, so this will trip up a large chunk of our userbase.

The installer uses . to pull in some common functions initially; this will break even if "sh /tmp/..." does not.

Bootstrapping downloads debootstrap to a temporary directory and executes it via "sh /tmp/...".  This will break, and debootstrap itself uses . to source things, which will break as well, and is out of our control.  I think we can move this to /usr/local/tmp as well, or create an exec-mounted directory in /tmp just for bootstrapping...at this point we have root.

Once your chroot is installed, binaries are, by default, in /usr/local/bin, so that should be fine.  However, people also install crouton to external media, and run enter-chroot via "sh /media/removable/.../enter-chroot"...this will also not work, breaking a lot of tutorials.

Looking at the original bug, I don't see how blocking "sh /x/y/z" based on noexec is related to the issue of sourcing libraries/settings from stateful.  Executing a script directly via "sh" results in no useful side-effects for the calling script, so it's unlikely to be used in an insecure manner on stuff in stateful (well, aside from user-initiated usages like crouton).

I can understand, accept, and work around the blocking the sourcing of scripts from noexec, but preventing "sh /whatever" seems excessive and will have dire consequences on the crouton side.

[Mike Frysinger]

yes, breaking shell script execution out of ~/Downloads/ is expected and what we want.  we've seen exploits use this vector specifically.  on non-test images, execution of code in /tmp will also break.  both are mounted noexec.

with chroots on removable media, i don't think the shell part is new.  if you're attempting to chroot & execute code in there (like a shell or any other program), if it was mounted noexec, those would fail.

the bug referenced inadvertent execution that came up during code review in comment #0, and referenced `sh xxx.sh` in comment #1.  it also came up again in a recent bug chain (crbug.com/766253).

we could make the behavior dependent upon "am i in verified mode", but we don't usually throw dev-mode users under the bus.  it will also mean we can't verify any of this behavior in the CQ/release trybots because all the DUTs are running in dev mode.  so any breakage won't show up until we actually ship the release to users.

-mike

[David Schneider]

On Mon, Nov 6, 2017 at 2:28 PM, Mike Frysinger <vap...@chromium.org> wrote:

yes, breaking shell script execution out of ~/Downloads/ is expected and what we want.  we've seen exploits use this vector specifically.  on non-test images, execution of code in /tmp will also break.  both are mounted noexec.

with chroots on removable media, i don't think the shell part is new.  if you're attempting to chroot & execute code in there (like a shell or any other program), if it was mounted noexec, those would fail.

Please look carefully at the commands I typed.  For removable media, enter-chroot is run via "sh /media/removable/.../enter-chroot", which works today regardless of noexec and will be broken by this change.  The only direct-exec stuff in crouton is /usr/local/bin/*-chroot.

 

the bug referenced inadvertent execution that came up during code review in comment #0, and referenced `sh xxx.sh` in comment #1.  it also came up again in a recent bug chain (crbug.com/766253).

The bug referenced the inadvertent execution via "source" or ., but only mentioned explicit execs of "sh" as another way to bypass noexec, and not in a reference to actual exploits.

I do not have access to 766253, so perhaps that proves without a doubt "sh /a/b/c" is dangerous.  From what I *can* see, we have a clear and fairly common misuse of source (or . ) for pulling in stateful configuration that needs protection in depth against.  Explicitly calling "sh" to execute a shell script is highlighted as another way of executing scripts, but it is not (in the bugs I have access to) shown to be an exploitable error in the scripts on our roofts, and I have a hard time seeing it being used in such a way.

Since I doubt everyone on this list will get access to 766253, could you please explain the usage style of explicitly calling sh that is dangerous?

 

we could make the behavior dependent upon "am i in verified mode", but we don't usually throw dev-mode users under the bus.  it will also mean we can't verify any of this behavior in the CQ/release trybots because all the DUTs are running in dev mode.  so any breakage won't show up until we actually ship the release to users.

Yeah, I'm aware making dev mode behave differently is generally a bad idea, which is why I didn't suggest it.  

-David

[Mike Frysinger]

On Mon, Nov 6, 2017 at 5:48 PM, David Schneider <dnsc...@chromium.org> wrote:

On Mon, Nov 6, 2017 at 2:28 PM, Mike Frysinger <vap...@chromium.org> wrote:

yes, breaking shell script execution out of ~/Downloads/ is expected and what we want.  we've seen exploits use this vector specifically.  on non-test images, execution of code in /tmp will also break.  both are mounted noexec.

with chroots on removable media, i don't think the shell part is new.  if you're attempting to chroot & execute code in there (like a shell or any other program), if it was mounted noexec, those would fail.

Please look carefully at the commands I typed.  For removable media, enter-chroot is run via "sh /media/removable/.../enter-chroot", which works today regardless of noexec and will be broken by this change.  The only direct-exec stuff in crouton is /usr/local/bin/*-chroot.

i'm aware of what you typed -- that doesn't change my response which itself included qualifications.

if you're implying that the unpacked chroot lives on the removable media, then as i said, the shell part is irrelevant -- you already need to have that device mounted "exec".  if it wasn't, then the ELF files living in that chroot fail to run today.

if the chroot isn't in the removable media, then what's the point of putting scripts like "enter-chroot" in there if it's going to turn around and `chroot` into paths in /usr/local ?

the bug referenced inadvertent execution that came up during code review in comment #0, and referenced `sh xxx.sh` in comment #1.  it also came up again in a recent bug chain (crbug.com/766253).

The bug referenced the inadvertent execution via "source" or ., but only mentioned explicit execs of "sh" as another way to bypass noexec, and not in a reference to actual exploits.

you're ignoring comment #1 which i referenced already.  if you search for "geohot pwnium bug" you'll find open exploit chains that involved running `sh xxx.sh`.

I do not have access to 766253, so perhaps that proves without a doubt "sh /a/b/c" is dangerous.  From what I *can* see, we have a clear and fairly common misuse of source (or . ) for pulling in stateful configuration that needs protection in depth against.  Explicitly calling "sh" to execute a shell script is highlighted as another way of executing scripts, but it is not (in the bugs I have access to) shown to be an exploitable error in the scripts on our roofts, and I have a hard time seeing it being used in such a way.

flip it around: there is no valid use case for running `sh foo.sh` when foo.sh lives on a noexec point.  since we have multiple examples of exploit writers using this, and we can safely kill it off, we might as well.  crouton abusing that function is not critical to crouton continuing to work (ignoring intermediate migration pain).

as i mentioned in the original post, we know this doesn't fix all possible methods for running shell code, and exploit writers will move on to other methods.  our plan is to keep chipping away and remove features that are not necessary so that at some point we can close this off entirely.  that's the standard security dance: attackers find a method, defenders close it off, and attackers move on to the next.  we don't look at the system and say "well you could do this other thing that's almost as easy, so let's not bother fixing that bug until we can make everything bullet proof".

Since I doubt everyone on this list will get access to 766253, could you please explain the usage style of explicitly calling sh that is dangerous?

Chromium security bugs are automatically unrestricted and made visible to the world after a timeout (some number of weeks).  the exact details aren't relevant considering the data/statements above.

-mike

[David Schneider]

On Mon, Nov 6, 2017 at 3:14 PM, Mike Frysinger <vap...@chromium.org> wrote:

On Mon, Nov 6, 2017 at 5:48 PM, David Schneider <dnsc...@chromium.org> wrote:

On Mon, Nov 6, 2017 at 2:28 PM, Mike Frysinger <vap...@chromium.org> wrote:

yes, breaking shell script execution out of ~/Downloads/ is expected and what we want.  we've seen exploits use this vector specifically.  on non-test images, execution of code in /tmp will also break.  both are mounted noexec.

with chroots on removable media, i don't think the shell part is new.  if you're attempting to chroot & execute code in there (like a shell or any other program), if it was mounted noexec, those would fail.

Please look carefully at the commands I typed.  For removable media, enter-chroot is run via "sh /media/removable/.../enter-chroot", which works today regardless of noexec and will be broken by this change.  The only direct-exec stuff in crouton is /usr/local/bin/*-chroot.

i'm aware of what you typed -- that doesn't change my response which itself included qualifications.

if you're implying that the unpacked chroot lives on the removable media, then as i said, the shell part is irrelevant -- you already need to have that device mounted "exec".  if it wasn't, then the ELF files living in that chroot fail to run today.

enter-chroot sh-runs mount-chroot, which will create an exec-able bind mount (or ecryptfs mount if the chroot is encrypted) in a shadow tree in /var.

Summarized:

1. User runs "sudo sh /mount/removable/.../bin/enter-chroot" [canonical, and broken]

2. which itself runs "sh /mount/removable/.../bin/mount-chroot" [broken, but can be worked around in an update]

3. which bind-mounts (with exec) or encryptfs-mounts (also with exec) to a shadow tree in /var

4. after which everything that is +x'd in the chroot is executable. [not broken]

 

if the chroot isn't in the removable media, then what's the point of putting scripts like "enter-chroot" in there if it's going to turn around and `chroot` into paths in /usr/local ?

the bug referenced inadvertent execution that came up during code review in comment #0, and referenced `sh xxx.sh` in comment #1.  it also came up again in a recent bug chain (crbug.com/766253).

The bug referenced the inadvertent execution via "source" or ., but only mentioned explicit execs of "sh" as another way to bypass noexec, and not in a reference to actual exploits.

you're ignoring comment #1 which i referenced already.  if you search for "geohot pwnium bug" you'll find open exploit chains that involved running `sh xxx.sh`.

It also involves running tar, and base64, and a few other commands before ultimately executing the extracted shell script via sh.  I'm not going to pretend I can fully understand the code, but is it actually an integral part of the exploit, or just a convenience that can easily be done without?  [you comment on this below; continuing there...]

 

I do not have access to 766253, so perhaps that proves without a doubt "sh /a/b/c" is dangerous.  From what I *can* see, we have a clear and fairly common misuse of source (or . ) for pulling in stateful configuration that needs protection in depth against.  Explicitly calling "sh" to execute a shell script is highlighted as another way of executing scripts, but it is not (in the bugs I have access to) shown to be an exploitable error in the scripts on our roofts, and I have a hard time seeing it being used in such a way.

flip it around: there is no valid use case for running `sh foo.sh` when foo.sh lives on a noexec point.  since we have multiple examples of exploit writers using this, and we can safely kill it off, we might as well.  crouton abusing that function is not critical to crouton continuing to work (ignoring intermediate migration pain).

That is an argument for removing a lot of the conveniences we provide for users of dev mode.

Yes, the instructions on all of the abandoned (but popular) blog posts for crouton will probably change from:

1. Click link to download crouton

2. sudo sh ~/Downloads/crouton

to:

1. Click link to download crouton

2. sudo install crouton /usr/local/bin/

3. sudo crouton

which isn't terrible. And if you're ignoring the intermediate migration pain, then yes, we can keep hacking around things so crouton works.  Unfortunately, many popular blog posts are *still* telling people to VT switch into chroots, so the odds of ever getting past the migration pain are slim to nil.

 

as i mentioned in the original post, we know this doesn't fix all possible methods for running shell code, and exploit writers will move on to other methods.  our plan is to keep chipping away and remove features that are not necessary so that at some point we can close this off entirely.  that's the standard security dance: attackers find a method, defenders close it off, and attackers move on to the next.  we don't look at the system and say "well you could do this other thing that's almost as easy, so let's not bother fixing that bug until we can make everything bullet proof".

Sure, but there's a difference between an exploitable hole and something that just provides short-hand convenience once access has already been gained.

source /to/noexec is an exploitable hole.

As far as I can tell from the geohot exploit, sh /to/noexec is a short-hand used after the system is already wide open.

-David

[Mike Frysinger]

On Mon, Nov 6, 2017 at 6:46 PM, David Schneider <dnsc...@chromium.org> wrote:

On Mon, Nov 6, 2017 at 3:14 PM, Mike Frysinger <vap...@chromium.org> wrote:

On Mon, Nov 6, 2017 at 5:48 PM, David Schneider <dnsc...@chromium.org> wrote:

On Mon, Nov 6, 2017 at 2:28 PM, Mike Frysinger <vap...@chromium.org> wrote:

yes, breaking shell script execution out of ~/Downloads/ is expected and what we want.  we've seen exploits use this vector specifically.  on non-test images, execution of code in /tmp will also break.  both are mounted noexec.

with chroots on removable media, i don't think the shell part is new.  if you're attempting to chroot & execute code in there (like a shell or any other program), if it was mounted noexec, those would fail.

Please look carefully at the commands I typed.  For removable media, enter-chroot is run via "sh /media/removable/.../enter-chroot", which works today regardless of noexec and will be broken by this change.  The only direct-exec stuff in crouton is /usr/local/bin/*-chroot.

i'm aware of what you typed -- that doesn't change my response which itself included qualifications.

if you're implying that the unpacked chroot lives on the removable media, then as i said, the shell part is irrelevant -- you already need to have that device mounted "exec".  if it wasn't, then the ELF files living in that chroot fail to run today.

enter-chroot sh-runs mount-chroot, which will create an exec-able bind mount (or ecryptfs mount if the chroot is encrypted) in a shadow tree in /var.

Summarized:

1. User runs "sudo sh /mount/removable/.../bin/enter-chroot" [canonical, and broken]

2. which itself runs "sh /mount/removable/.../bin/mount-chroot" [broken, but can be worked around in an update]

3. which bind-mounts (with exec) or encryptfs-mounts (also with exec) to a shadow tree in /var

4. after which everything that is +x'd in the chroot is executable. [not broken]

what's the point of keeping scripts in the USB stick ?  are people nuking everything else often enough to warrant keeping a copy like that ?

if the chroot isn't in the removable media, then what's the point of putting scripts like "enter-chroot" in there if it's going to turn around and `chroot` into paths in /usr/local ?

the bug referenced inadvertent execution that came up during code review in comment #0, and referenced `sh xxx.sh` in comment #1.  it also came up again in a recent bug chain (crbug.com/766253).

The bug referenced the inadvertent execution via "source" or ., but only mentioned explicit execs of "sh" as another way to bypass noexec, and not in a reference to actual exploits.

you're ignoring comment #1 which i referenced already.  if you search for "geohot pwnium bug" you'll find open exploit chains that involved running `sh xxx.sh`.

It also involves running tar, and base64, and a few other commands before ultimately executing the extracted shell script via sh.  I'm not going to pretend I can fully understand the code, but is it actually an integral part of the exploit, or just a convenience that can easily be done without?  [you comment on this below; continuing there...]

shell scripts are frequent attack vectors for people because of the pure arbitrariness of their inputs.  it allows them to easily pivot and attack other services and modify things.  it's why the term "shellcode" exists.  if people didn't have access to the shell, they'd have to find other ways to do basic manipulations and chain them together (if they could).

look at it like a toolbox.  if you have every tool, it's much easier to get the job done.  but if we take away tools from attackers, at some point they might find bugs, but they can't actually exploit them.

I do not have access to 766253, so perhaps that proves without a doubt "sh /a/b/c" is dangerous.  From what I *can* see, we have a clear and fairly common misuse of source (or . ) for pulling in stateful configuration that needs protection in depth against.  Explicitly calling "sh" to execute a shell script is highlighted as another way of executing scripts, but it is not (in the bugs I have access to) shown to be an exploitable error in the scripts on our roofts, and I have a hard time seeing it being used in such a way.

flip it around: there is no valid use case for running `sh foo.sh` when foo.sh lives on a noexec point.  since we have multiple examples of exploit writers using this, and we can safely kill it off, we might as well.  crouton abusing that function is not critical to crouton continuing to work (ignoring intermediate migration pain).

That is an argument for removing a lot of the conveniences we provide for users of dev mode.

yes, we balance this every day.  it's why `dev_install` exists instead of just shipping the programs directly in the rootfs.  it's why bash is still on the rootfs (even when, for security, we'd rather remove it and only allow dash).

in the case of noexec, our intention has always been to not allow people to execute out of most mount points.  the fact that bash allowed it is a limitation that we've finally hit the tipping point for spending time on resolving.

Yes, the instructions on all of the abandoned (but popular) blog posts for crouton will probably change from:

1. Click link to download crouton

2. sudo sh ~/Downloads/crouton

to:

1. Click link to download crouton

2. sudo install crouton /usr/local/bin/

3. sudo crouton

considering the benefits, i don't think that is onerous

which isn't terrible. And if you're ignoring the intermediate migration pain, then yes, we can keep hacking around things so crouton works.  Unfortunately, many popular blog posts are *still* telling people to VT switch into chroots, so the odds of ever getting past the migration pain are slim to nil.

as i mentioned in the original post, we know this doesn't fix all possible methods for running shell code, and exploit writers will move on to other methods.  our plan is to keep chipping away and remove features that are not necessary so that at some point we can close this off entirely.  that's the standard security dance: attackers find a method, defenders close it off, and attackers move on to the next.  we don't look at the system and say "well you could do this other thing that's almost as easy, so let's not bother fixing that bug until we can make everything bullet proof".

Sure, but there's a difference between an exploitable hole and something that just provides short-hand convenience once access has already been gained.

source /to/noexec is an exploitable hole.

As far as I can tell from the geohot exploit, sh /to/noexec is a short-hand used after the system is already wide open.

it isn't wide open, it's a toe hole that can be used to kick the door in with `sh`

in the geohot exploit, we close the basic `sh /tmp/x.sh` now.  but the series of commands he ran was itself a buffer that was passed to a shell to run (mkdir/wget/etc...), and if we can enforce that the shell only loads code from exec mount points, that wouldn't work either.

-mike

[Hung-Te Lin]

I think few factory or firmware related scripts may fail since they all use indirect execution for "downloaded" resources to prevent unnecessary remount, for example

 src/platform2/init/upstart/test-init/cros-payloads.conf

 src/platform/factory_install/factory_install.sh

Can we enable indirect execution when $(crossystem cros_debug) is 1?

--

[Mike Frysinger]

cros-payloads.conf will break, so we'll have to adjust that.  that is only part of a test image right ?  it could copy the scripts to a dir in /tmp first and execute it from there (since on test images, /tmp will be exec).

in factory_install.sh, looks like all of its scripts run via `mktemp -d` which should create a dir in /tmp.  is this run as part of a test image ?  or is this in a factory install shim ?  for test image, /tmp is exec.  for initramfs projects, iirc, /tmp is just a dir on / which is a tmpfs already mounted as exec.

as mentioned in this thread, we don't want to tie to dev mode because it means none of our DUTs will check things which means all CQ/release bots will pass, so bugs won't show up until the code actually ships to users.

-mike

[Hung-Te Lin]

2017-11-07 22:38 GMT+08:00 Mike Frysinger <vap...@chromium.org>:

cros-payloads.conf will break, so we'll have to adjust that.  that is only part of a test image right ?  it could copy the scripts to a dir in /tmp first and execute it from there (since on test images, /tmp will be exec).

   We were trying to prevent an extra copy because the payloads there may be pretty huge, for example an compressed rootfs.

   Will it help if we do "mount -o exec,remount /mnt/stateful_partition" in cros_payloads.conf?

 

in factory_install.sh, looks like all of its scripts run via `mktemp -d` which should create a dir in /tmp.  is this run as part of a test image ?  or is this in a factory install shim ?  for test image, /tmp is exec.  for initramfs projects, iirc, /tmp is just a dir on / which is a tmpfs already mounted as exec.

   That is executed in factory_shim - initramfs after switch_root.

   switch_root will invoke /sbin/init, which may do the mounting of /tmp again with noexec I think?

[Mike Frysinger]

On Tue, Nov 7, 2017 at 7:17 PM, Hung-Te Lin <hun...@chromium.org> wrote:

2017-11-07 22:38 GMT+08:00 Mike Frysinger <vap...@chromium.org>:

cros-payloads.conf will break, so we'll have to adjust that.  that is only part of a test image right ?  it could copy the scripts to a dir in /tmp first and execute it from there (since on test images, /tmp will be exec).

   We were trying to prevent an extra copy because the payloads there may be pretty huge, for example an compressed rootfs.

   Will it help if we do "mount -o exec,remount /mnt/stateful_partition" in cros_payloads.conf?

to be clear, i'm only referring to copying the shell scripts, not the payloads themselves.  assuming the payload isn't a shell script with a large binary appended/embedded ?

cros-payloads.conf does:

  PAYLOADS="/mnt/stateful_partition/cros_payloads"

  INSTALL_DIR="${PAYLOADS}/install"

  for script in "${INSTALL_DIR}"/*.sh; do

so we'd want to set up an executable path somewhere and copy only the scripts there.

do you have some code i can refer to for more details ?  i.e. the stuff that populates these paths ?

in factory_install.sh, looks like all of its scripts run via `mktemp -d` which should create a dir in /tmp.  is this run as part of a test image ?  or is this in a factory install shim ?  for test image, /tmp is exec.  for initramfs projects, iirc, /tmp is just a dir on / which is a tmpfs already mounted as exec.

   That is executed in factory_shim - initramfs after switch_root.

   switch_root will invoke /sbin/init, which may do the mounting of /tmp again with noexec I think?

my reading of factory_shim/bootstrap.sh looks like it should be fine.  switch_root is run inside of $NEWROOT_MNT which is /newroot and is simply a tmpfs mount point created on the fly (with exec permissions).  /tmp isn't mounted under there afaict which means it re-uses the tmpfs mount.  patch_new_root also explicitly nukes pre-startup.conf which is what mounts /tmp as noexec.

-mike

[Mike Frysinger]

we're a bit late in the M64 cycle, and considering the history, there's potential for a long tail of latent bugs.  so i'll hold off on merging until after the M64 branch (which will prob be start of Dec).

i'll look at improving the messaging and perhaps adding logging/crash-reports.  that should help transition people to the NWO and avoid us chasing down weird bugs late in the branch cycle.

-mike

On Mon, Nov 6, 2017 at 2:01 PM, Mike Frysinger <vap...@chromium.org> wrote: