New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 127 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature



Sign in to add a comment
link

Issue 761329: allow "Unknown Sources" in Android without requiring that the device is in Developer Mode

Reported by h...@guardianproject.info, Sep 1 2017

Issue description

UserAgent: Mozilla/5.0 (X11; CrOS armv7l 9592.85.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.112 Safari/537.36
Platform: 9592.85.0 (Official Build) stable-channel veyron_minnie

Steps to reproduce the problem:
1. Go to the Android Settings
2. Go to the Security section
3. notice the lack of "Unknown Sources"
4. enable Android "Developer options"
5. go to "Developer options" section
6. notice the lack of "Unknown Sources"

What is the expected behavior?

What went wrong?
There is no way to directly install APKs without forcing the whole Chromebook into Developer Mode.

Did this work before? N/A 

Chrome version: 60.0.3112.112  Channel: n/a
OS Version: 9592.85.0
Flash Version: 

When testing on people's devices in the wild, it makes it impossible to request them to switch their Chromebook to Developer Mode.  It takes a long time, it opens up their device to security issues, it deletes all the locally cached data, it is a process with scary warnings, etc.

All Android devices provide the "Unknown Sources" switch in the Security section of the Settings.  At the very least, make it available in "Developer options" or via networked ADB.
 

Comment 1 by h...@guardianproject.info, Sep 1 2017

I forgot to add another important use case for user access to "Unknown Sources": lots of people around the world use nearby file sharing apps like Share-It, Zapya, etc.  because the internet is unavailable, too expensive, or blocked.  None of those apps will work without "Unknown Sources"

Comment 2 by rodrigue...@gmail.com, Sep 4 2017

I support this request.

Comment 3 by abelxl...@gmail.com, Sep 6 2017

It should absolutely be possible to enable unknown sources on devices when not in developer mode, this is vital to the openness of the system. Without this the OS can't be used in many situations where it is otherwise impossible to install apps.

Forcing users into developer mode is a big security risk.

Comment 4 by jaredha...@gmail.com, Sep 10 2017

We shouldn't have to use any Developer Mode to use open source app repositories like F-Droid, or discount app stores (where a 30%+ charge on a pay-what-you-can transaction with charity makes little sense) like Humble Bundle.

Comment 5 by dhadd...@chromium.org, Sep 15 2017

Components: Platform>ARC
Labels: -Type-Bug Type-Feature

Comment 6 by uekawa@google.com, Sep 15 2017

Labels: -Pri-2 Pri-3

Comment 7 by uekawa@google.com, Sep 15 2017

Cc: xzhou@chromium.org
+xzhou FYI.

Comment 8 by xz...@google.com, Sep 15 2017

Cc: yoshi@chromium.org jorgelo@chromium.org mnissler@chromium.org
Work as intended for security reasons. 

APK sideloading weakens verified boot and allows unverified native code running on the device. The attacker could use sideloading apps to:
1. Persist their attacks.
2. Distribute malicious APK outside Play Store.
3. Exploit known vulnerabilities in sideloaded APKs. For example, Play Store will check for insecure uses of HTTP/HTTPS.

So, for now we only allow sideloading in dev mode.

Comment 9 by xz...@google.com, Sep 15 2017

Cc: jhorwich@chromium.org

Comment 10 by jaredha...@gmail.com, Sep 17 2017

There are valid security threat models where any singular source, such as the Google Play Store, would in itself constitute an availability threat during turmoil. For example: a national takeover of all Internet infrastructure allows a bad government actor to pretend to be Google Play services, including the sole source of all security and app updates. A user-selected alternative installation and update source like F-Droid could mitigate this threat by providing an alternative route to security updates whenever the primary source (Play Store) is compromised, particularly when it offers an alternative or competitive form of transit cryptography and trusted signature confirmation.

Lack of retail source competition is in itself an economic security threat.

Comment 11 by h...@guardianproject.info, Sep 19 2017

It makes perfect sense to require developer mode to sideload chrome apps because a chrome app is a website, and anyone who can make a website can also just post the website to a webserver, and then any Chromebook would access it.  So there is only a tiny trade-off to restricting how chrome apps are installed.  Even if the internet is restricted or unavailable, local networks and servers will still work here.  With Android apps on Chromebooks, you're dead in the water.

Android APKs are a different story, and that's why Android itself has always supported user-controlled "Unknown Sources". If someone wants to run an Android app on a Chromebook that's not available in Google Play or the internet is not available, they are totally blocked.  

One use case that is quite important to me is using Chromebooks as a hardened travel laptop.  If I go to China, I cannot install Android apps on it since Google is blocked there.  Switching to developer mode for this scenario totally defeats the purpose.

Comment 12 by jorgelo@chromium.org, Sep 25 2017

Status: WontFix (was: Unconfirmed)
In this case, we've decided to fall on the security side of the security-usability tradeoff.

Webpages and Chrome apps run in Chrome renderer processes that have little access to the rest of the system. The Chrome sandbox prevents most access to the file system, networks, and presents a heavily-restricted kernel attack surface.

Android apps, on the other hand, run in a significantly looser sandbox. They have access to almost all of the host kernel (at least in Android N, which is currently shipping on Chromebooks). Moreover, not only do Android apps have significantly more access to the host kernel, they're also not covered by Chrome OS's verified boot: apps are downloaded from the Play Store, but then they're compiled to native code on-device and therefore that code cannot currently be verified.

The combination of significantly higher exposed kernel attack surface + unverified code means that we need to rely more heavily on the scanning done by the Play Store to root out malicious apps. Therefore, we cannot realistically allow sideloading in Verified mode and still call it "Verified". Those apps could contain trivial bugs or vulnerabilities and would have extensive access to the host kernel. Hence the dev-mode requirement.

This is currently working as intended. We can consider changing this restriction when we make the Android app runtime as restricted as a Chrome renderer process.

Comment 13 by elijahtaylor@chromium.org, Sep 27 2017

Cc: elijahtaylor@chromium.org
Labels: -Pri-3 M-65 Pri-2
Owner: jhorwich@chromium.org
Status: Assigned (was: WontFix)
We have been talking about how to enable unknown sources without dev mode for a while, and have a proposal.  Note: this is not as simple as just letting users turn it on through Android settings for the reasons mentioned by jorgelo@ and others above.  There will have to be some friction to enabling/disabling unknown sources to be able to reason about the security of the device, and it will take time to implement.  Optimistically targeting M-65 ATM.

Comment 14 by jaredha...@gmail.com, Sep 29 2017

That's great news! Given the perceived security tradeoffs above (which are not purely security vs. usability in that they completely ignored the known threat models I already indicated -- fraudulent Google certs have been created by powerful State actors before after all), maybe the proper framing of this problem isn't to simply duplicate the other Android releases' "Unknown Sources" option, but instead to add an "Alternative Trusted Repositories" option for users/admins to define one or more their own. If I'm not mistaken, they can already install multiple vulnerability scanners of their own, so the premise of forcing dependency on solely the Play Store scanner is already moot. This also seems to be a better match with the Android Oreo APK source permission model.

Based on my IT experiences, I'm sure there's plenty of businesses that would love to be able to deploy internal-only tools repository access to all employee devices in this fashion, without giving everyone a "developer" level of access to company-owned devices. This would also satisfy the open source users (like myself) who just want to define their own OSS repository sources based on tangential trust systems, not to give blanket APK access from all sources vs. just one. This would be so useful, in fact, that maybe it should go upstream into AOSP directly? Is the Android Oreo APK source permission model already effectively the same thing, and could it be ported back to Nugat?

Comment 15 by jorgelo@chromium.org, Sep 30 2017

I think what you describe is indeed, essentially, the new Oreo APK source permission model. I don't think it's feasible to backport that to Nougat though, but I agree that it is the right way to solve this problem.

I imagine that when Android on Chrome OS moves to O+, we can provide an APK source that's managed by Chrome OS and that allows more flexibility.

Comment 16 by yoshi@chromium.org, Jan 3 2018

Cc: -yoshi@chromium.org

Comment 17 by c...@chromium.org, Jan 16 2018

Cc: c...@chromium.org

Comment 18 by i...@leesah.name, Feb 17 2018

Does "targeting M-65" in #13 mean version 65 of Chrome OS? I see v65 is already available on the beta channel. Is there any update regarding this bug?

Comment 19 by jorgelo@chromium.org, Feb 20 2018

I don't think M-65 there is accurate anymore.

Comment 20 by i...@leesah.name, Feb 20 2018

He did say "optimistically" tho. Is there a new estimation then?

Comment 21 by jorgelo@chromium.org, Feb 20 2018

I'll let Elijah comment on that since he's overseeing this process.

Comment 22 by mhoberha...@gmail.com, Mar 30 2018

Any updates on a new target release?

Comment 23 by elijahtaylor@chromium.org, Apr 4 2018

Labels: -M-65 M-69
The M-65 target was indeed far too optimistic. For security and other reasons, we're delaying this until M-69 at earliest to align with other ongoing work.

Comment 24 by bjarnehe...@gmail.com, May 18 2018

Would love to see this sooner than later, especially now with the support for Linux apps. I really look forward to be able to run Android Studio and deploy my apps directly to my Pixelbook without having to set it to developer mode.

Comment 25 by guanlele...@gmail.com, Jun 20 2018

69.0.3464.0 on dev channel has been released. Still cannot find the option. Any updates?

A technical question:
   As explained by jorgelo, the major security concerns about sideloading APK are higher exposed kernel attack surface + unverified code. I wonder if the same applies to Crostini, which runs Linux in a container having access to most kernel interface and also runs unverified code. What is the key consideration that separates the security policy of Android from Crostini?

Comment 26 by jorgelo@chromium.org, Jun 20 2018

Crostini (including the container) is running in a virtual machine, while APKs are not. Therefore, in Crostini the kernel attack surface is that of the *guest* kernel, while for sideloaded APKs the kernel attack surface is that of the *host* kernel, which is shared with the rest of the Chrome OS system, and therefore significantly more critical than a guest kernel.

Comment 27 by guanlele...@gmail.com, Jun 20 2018

Thanks, jorgelo, that makes sense.

Maybe after accelerated graphics is supported in Termina, Android can be put in another container inside Termina. In this way, sideloading APK can be relaxed automatically.

Comment 28 by linuxi...@gmail.com, Jun 24 2018

Doesn't ARCWelder allow this, essentially?

I just tried it, and it worked fine with a random APK I had laying around.

Comment 29 by weifangsun@chromium.org, Aug 3

Components: Platform>Apps>ARC

Comment 30 by gavinfer...@gmail.com, Aug 3

ARCWelder is the older implementation that's based on NaCl (Native Client) if I'm not wrong, while what we use on our Chromebooks is ARC++ that's based on some form of containers. ARCWelder didn't use any form of VM, and was buggy for quite a few apks apparently (None of those that I tried long ago worked).
PS: Sorry for the OT @ the chromium guys and gals

Comment 31 by achand...@gmail.com, Aug 11

Is this still expected to release in M-69?

Comment 32 by aidrees@chromium.org, Aug 11

Labels: Hotlist-ConOps-CrOS

Comment 33 by i.heart....@gmail.com, Sep 3

Posting to subscribe. This is mostly a semantic argument and I understand and agree with your decision making, but what you are doing isn't justified from a security standpoint, since you are forcing ordinary use case users into an insecure environment. Instead what justifies your decision is the Pareto principle; you are making ChromeOS more secure for 80% of the users and less secure for 20%.

Please keep up the good work. While a third mode that retains most of the security built in to ChromeOS but allows sideloading apps is sorely needed, this is definitely the sort of thing that needs to be done correctly and needs to be well thought out, and I am more than happy to wait a few years for a good compromise feature.

Until then I'd also like to commend you for the thought you put into Chronos, and the robustness you already added to developer mode's security. It is nice to be able to "roll my own" mode between developer mode and standard mode until you get this sorted. I'll admit I've groaned about powerwash before, but honestly resetting to factory is something I frequently do with any OS anyway and encrypting and backing up sources is a habit I formed as a developer long before using my pixelbook.

Comment 34 by markmack...@gmail.com, Sep 15

I would really like to see this feature as well.  I'm a developer and would like to permit specific approved android applications run our our daughter's chromebook, but don't want to leave her using a less secure device by switching to developer mode.
I completely understand and agree with the need to protect the average user from violating the security of their device.  I think they key is to make it possible, but also so much of a pain for a non-developer that it passes the threshold of effort that the average user would be willing to do to install whatever scam they're being offered, but a developer still could due to being more comfortable working in the shell / setting up servers etc.

Maybe something like:
1) You have to wipe your device to get in to developer mode ONCE to access a special serial number from the terminal that you're only allowed to read in developer mode, maybe by typing in a command like "thisCanBeUsedToHackMe".  This should already deter a lot of people due to the need to wipe everything, but if an organization or individual wants to, they can record this number when first setting up the machines.
2) On a different machine, you spin up an apk server that's initialized with the machine-specific serial number(s).  Most developers will be much more comfortable spinning up a server than an inexperienced user, and it's limited to specific machines, so can't be used to target lots of uncooperative users.
3) After switching back to non-developer mode on the chromebook, you can only sideload an APK from the local network and from a apk server setup with the machine's serial.  This prevents drive-by downloads from shady adverts outside the network, nor running a service for everyone regardless of serial.

If you were worried about 3rd party apps being made to make it too easy/user friendly to run the server, you could do things like custom challenge/responses that have to be typed in crosh that a guide can't know the answers for in advance while doing a download, or require the server be run from the chromebook itself with a long series of terminal commands that aren't copy & paste / script friendly.  This is one of the very rare times we're actively trying to make usability worse for non-developer users.

The above are just some straw man ideas, but the bottom-line is that I believe it's important we allow individual developers to add content to the devices that they administer (and not only in a corporate managed environment), WITHOUT giving up the normal security model for the device's regular users.

Comment 35 by elijahtaylor@chromium.org, Sep 17

Labels: -Pri-2 -M-69 M-72 Pri-1
Thanks everyone for your patience while we work on this.

To set expectations, we do have a design and large part of the implementation done and ready to go, but we're waiting on some significant changes on our Android implementation before being able to land and turn this on.  Retargeting to M-72 for now as the dependent changes are expected to land in M-71 and then we can start landing "unknown sources" support.

Comment 36 by seldnp...@gmail.com, Nov 3

72 is out in the wild now. Any updates?

Comment 37 by xzhou@chromium.org, Nov 5

Chrome OS security team is working on a design that can better secure side loading.

Comment 38 by de...@derekgordon.com, Nov 6

This is much needed.

Comment 39 by hexin...@gmail.com, Nov 27

It seems like we still don't have it in M72. Maybe it's been pushed off to M73?

Comment 40 by achand...@gmail.com, Nov 27

Can a developer please comment. This has been pushed back a few versions
already.

Ahmed Chandab

On Wed, Nov 28, 2018, 8:52 AM hexin… via monorail <
monorail+v2.1710676136@chromium.org wrote:

Comment 41 Deleted

Comment 42 by john.sza...@gmail.com, Dec 30

+1 this should be possible without developer mode.

Comment 43 by trumbull@chromium.org, Jan 3

Cc: shihuis@google.com

Comment 44 by mutexlox@chromium.org, Jan 8

Cc: mutexlox@chromium.org

Comment 45 by elijahtaylor@chromium.org, Jan 8

Labels: -M-72
Hi folks,

Thanks for being patient while we sort this feature out.  I can give some details, but don't want to commit to an exact milestone given that this has been punted a few times already.

We're still working on this, and would like to be able to deliver in the next couple milestones (M-74/M-75 timeframe hopefully).  Unfortunately it's been pre-empted a couple of times due to higher priority issues; for instance, you may have seen we've recently launched Android Pie on Pixel Slate and have been starting to roll it out to more devices.

We'll provide more details on this bug when we can, hopefully in the form of landed code reviews as we get further into the development of this.

Comment 46 by hoyeeke...@gmail.com, Feb 7

This is the most anticipated feature

Comment 47 by marshall...@gmail.com, Feb 10

+1 on this feature.  I would rather not have my CB in Dev mode daily just because I am running a couple 3rd party apps when it is so easily done on an Android phone or tablet without the extra hit on security.

Comment 48 by noirx...@gmail.com, Feb 11

+1 on this as well. I really don't want to put my pixelbook in dev mode to use a couple of applications either. I have these apps on most of my other devices and would love to be able to use them on my pixelbook. I think most of us are aware of the risks of not using things on the play store so making a thing we have to sign/acknowledge to allow us to do this would be totally acceptable.

Comment 49 by grillitd...@gmail.com, Feb 11

I totally can't wait for this feature.

Comment 50 by gavinfer...@gmail.com, Feb 12

hoyeeke...@gmail.com marshall...@gmail.com noirx...@gmail.com grillitd...@gmail.com and any others that intend to comment here, please do refrain from +1 posts, try getting more people to star this instead through other means (like the r/chromeos subreddit).

Comments are sent as emails to the subscribers of this issue, and we don't want to spam them with +1s, it won't help them code any quicker. Also the owner might decide to lock down the comments here to limit spam, which we don't want. Don't mean to be rude if I came off in the wrong way.

@The Devs/Mods, sorry for the OT

Sign in to add a comment