jorgelo, this might be in your area of expertise.  Can you comment on this or re-assign as appropriate?  Thanks.

Guessing sev high, not sure why you'd even get as far as running the debugger in dev mode.

Elijah, Dylan, is this expected?

No, that certainly shouldn't be possible.

Where did the installation of apk's get restricted?

This does require local access to switch the ADB toggle inside the container though.

I haven't been able to get this to work on my corp device. adb won't connect to localhost.

While I can't speak to any difference between a corp device and my own, there is an extra step to reproduce that I accidentally omitted from the bug report. 

I just powerwashed my device and retried the procedure, and it turns out that a reboot of the device is in fact necessary before adb will connect successfully. 

Apologies for the omission of this additional step in the original bug report.

I'll set up a device in verified mode that isn't enrolled and try again. The reboot didn't help on my enrolled device.

Thanks for following up!

Got it. On a non-corp, normal mode device I can push an apk I download from the web. I don't understand why this doesn't happen on a corp device, but we will try to figure that out separately.

I was under the impression PackageInstaller should also be invoked via the ADB install path, which should be restricted to dev mode, but seems like I'm mistaken.  +jhorwich who implemented this

+jhorwich for real and +lhchavez too

Two things *should* prevent PackageInstaller from handling the android.intent.action.INSTALL_PACKAGE intent in cases like this. First, the check for dev_mode when running on a Chromebook. Second, the normal check for Settings.Secure.INSTALL_NON_MARKET_APPS.

Given that the user's "steps to reproduce" don't include "enable sideloading in Settings > Security" (*) - and even explicitly mentions it's not necessary - I'm inclined to believe that adb must be using a different mechanism to install the APK - e.g. through PackageInstallerService (base/services/core/java/com/android/server/pm/PackageInstallerService.java), not the PackageInstaller app / intent handlers.

I was also able to install via adb onto my Chromebook, which was in Dev Mode, but did NOT have sideloading enabled by the user in Settings > Security.

(*) Which *also* shouldn't be possible on a Verified-Boot (non-Dev) mode Chromebook FWIW.  

Josh, can you figure out how to disable the PackageInstallerService method of installation too?

One thing that's not clear to me is why adbd is running in verified mode as well.  At one point we had conditionalized adbd on dev mode, does anyone have history of why this was changed?

Even though init.cheets.rc does gate starting adbd on dev mode, there's another .rc (init.usb.rc) that can start adbd under different conditions. concretely, the steps outlined in #c0 wil cause sys.usb.config to have the value of "adb" (instead of "mtp,adb").

The best course of action is probably to remove the /init.usb.rc and /init.usb.configfs.rc altogether so this can't happen again. Also, add a stanza in init.cheets.rc so that it also matches property:sys.usb.config=adb instead of just property:sys.usb.config=mtp,adb.

comment #17 sounds like a good approach, then we can grey out the adb option later as a UI optimization.

Should we also make pms/installd be aware of the source of an app? If the app does not come from Play store, then ignore the installation request?

For comment #19; that sounds optimal, as long the check can be bypassed if the chromebook is in developer mode.

CLs outlined in #c17 have landed in Android. jhorwich@ is currently working on the adb option.

+ketakid@ for merge approval.

+josafat@ for M60 merge approval.

Patches landed in nyc-mr1-arc and nyc-mr1-arc-m61 branches.

61 should have the fix as of platform version 9765.33.0.
62 should have the fix as of platform version 9854.0.0.

this was tracked internally as b/64720460

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an eligible charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
*********************************

Thanks for the report!  The VRP panel decided to award $500 for this - many thanks!

A member of our finance team will be in touch to arrange payment.

Also, if this is included in Chrome release notes, how would you like to be credited?

Pleasure to assist, and thanks for the reward!

If mentioned in any release notes, I'd like to be credited as "Julian J.". 

Cheers!

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot