LineageOS for microG – Access Google services without closed software
lineage.microg.org
lineage.microg.org
Q) "Wait, on their FAQ page I see that they don't want to include the patch for security reasons. Is this ROM unsafe?"
A) "No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services... Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users."
This is such a petulent attitude towards what sound like well-founded objections to the outright spoofing of Google signed apps that I'm just plain out already.
Also, using the phrase "no security threat is posed to our users" in ANY context is blindingly arrogant, and pretty irresponsible to boot.
This seems reasonable to me. How is this more dangerous than, e.g., giving an app permission to continously track your physical location?
One is replacing signed system components, the other is volunteering to share whereabouts with a third party.
The biggest concern with this is that Google has the resources (and pressure) to get something so central to the security model correct. I've no inside information on how Google develops Play Services, but I imagine they have quite stringent policies with regards to testing and peer review.
The actual functionality of Play Services is only one part of the work that goes into delivering it to your phone, and it's a lot of trust to place in anyone to get something like that right (considering the personal, security-sensitive information we keep on our phones now).
My point was that the FAQ was a big red flag for me in thinking that the developers grasp this aspect of what they're proposing here.
On the other hand, I think your implicit trust in internal Play Services policies may be a little over-egged. Google definitely has some great security teams (Chrome/Chromium's security team have made some good contribs to the web, Project Zero is also cool, if a little externally-focused) but this is by no means universal. Android's been a bit of a sore spot in this regard generally (particularly in comparison to Apple).
Sure, Apple makes their own life easier in terms of security by applying draconian restrictions on the freedoms of their own users. But this and the fact that things are not as easy for Google to do effective security doesn't make it any less true that they aren't doing it.
Again, Apple's Uber backdoor isn't really relevant - I never implied Apple were benign, just that Google's security record is imperfect, and compares poorly.
The openness and diversity of Android's platform isn't a wholesale excuse for not securing users.
Google also designed the media system, and that leads the security patches every month - what would have rehabilitated them?
https://interviews.slashdot.org/story/16/08/26/1338246/the-s...
"Don't start me on Stagefright and Mediaserver, I could rant for 2 or 3 hours non-stop! Seriously, the code over there is crap, and has insane concepts, like aborting the whole mediaserver (and all related media decoding of all other applications running at the same time), when it parses a file with attributes it does not know, instead of skipping the file. We discovered some issues in Stagefright (busy loops, device reboots, mediaserver crashes) quite early, but we never thought about submitting them."
If there is a permission that violates the trust between the system and an app using aforementioned APIs all bets are off. This is similar to why rooted devices are bad for security.
As a device owner and user I don't care for DRM style 'security' protecting app authors from me running my software on my computer.
People are 100% vigilant all the time.
There are people who don't want any binary blobs from Google on their devices.
With certificate spoofing, the risk is that I might accidentally click through permissions on a malicious, already installed and privileged app.
With LineageOS the risk is that I will, with 100% certainty, run code that I have deemed malicious (== any service-facing client-side Google blob).
Maybe you haven’t decided those binaries are malicious, but that doesn’t change my opinion, and what I do with my phone isn’t your business.
I don’t see why certificate spoofing is controversial at all (especially amongst the “free as in freedom” crowd).
Yes, and LineageOS is not. LinesageOS has an interest in maintaining the ability to run Google blobs and accepting such a patch might potentially harm that interest.
Instead of accepting that, this project acts all butt hurt and whines that LinesageOS's position is inconceivable.
Maybe I'm being a little pedantic, but my point is it's not LineageOS that makes that call. LineageOS does not distribute gapps and is not in any agreement with google that would possibly adversely impact users' ability to run gaps due to such agreement being revoked were LineageOS to act against googles interest. CM on the other hand likely would have been either directly or indirectly when it was buddied with one plus (which is when this went down).
There are a lot of subtly incorrect statements in this thread and I'm trying to help clarify because I find this discussion interesting and important.
LineageOS doesn't want to give the provocation to prevent them from being able to run the blobs.
I think you mean the reverse?
If an application is in /system/priv-app, it can do pretty much anything anyway. Worse than that, a threat-model assuming an attacker can write in /system/priv-app, he can most likely write into the whole /system, and replace everything of Android, install Xposed, etc... So I totally agree that if the patch does what it says (I didn't read, but it's possible.), "no security threat is posed to our users".
Though an acceptable reason from LineageOS imo is "this will be used to circumvent protections (read SafetyNet), we don't want that"
Signature spoofing only affects app you explicitly give permission to use it, and only apps that call for it.
I get that it's annoying if you choose not to run Google Services. But from a developer perspective if 99.9% of their target market does run Google Services and they make development of the app easier or provide useful features, I can see why they would choose to rely on them.
You can't access the stepcounter directly anymore, only through Google Fit.
Most location features are only available through Google Play's location API.
You can't even get up-to-date openssl or OpenGL support in your app without Play Services.
Not doing so reveals there actual reason: control. Forcing every manufacturer to ship Play Services and thus being able to force various things on their devices is a major financial benefit. It also ensured that Amazon or Nokia were unable to set up a commercially viable Android Fork without Google.
The comment above has to do with package signing, which is a security feature. It prevents malicious software from replacing legitimate programs on your device (e.g. a malicious "messages" app cannot overwrite the legit "messages" app you installed). It doesn't have anything to do with DRM.
That's all the μG team is asking for: If you already have write access to the entire system, at least provide a simple API to circumvent the signatures.
I understand why this seems alarming to a bystander. But if you're still dubious go read the Gerrit reviews--it's pretty clear the CM team was unwilling to accept the patch because "it allows one app to impersonate another" not because it presents a security hole. The patch went through multiple iterations ending on one that means users would literally see a prompt:
"microGapps is requesting permission FAKE_SIGNATURE to ..."
The microGapps team then asked "how would you propose we land on a solution so that we can provide an alternative to gapps while still checking the [x] security box? The CM team failed to provide any sort of compromise stating that allowing one app to impersonate another is not a feature they were willing to support on their platform.
So you see, it's not security that was the issue. The issue is that the CM team was unwilling to give users the freedom to allow the system to work as they want. What's infinitely ironic is that CM used to ship with root. It was the community fork "for the community by the community". It's not hard to correlate their sell out with their rollback on providing support for apps that need root and then irrational stance on letting some other thing be google play services.
The uGapps team is frustrated, but it's not petulant. It's very valid.
I will read more into the security claims and concerns, and may be persuaded, but at first blush I support not spoofing application signatures, as this is the same sort of chain of trust that package managers and app stores are built on.
As a consumer, I appreciate that LineageOS with Google services passes most to all of the CTS/Safetynet checks, and doesn't make me choose between having an updated, streamlined version of Android, and using my bank app, or playing Pokemon Go.
I think merging these changes could easily jeopardize that and maintaining it as a fork makes sense to me.
I'm not so sure about this though. It seems like they've disabled some very important security features. Their justification of "Lineage obviously hate freedom and are in bed with Google" doesn't sit right with me. Also there seem to be a lot of hoops to jump through just to re-enable the Play Store, which I'd consider basic functionality for any Android device.
Still, the pursuit of more freedom is a noble goal and I wish them all the best.
IIRC some root detection mechanisms still check for an unlocked bootloader.
This is handy if you only need root occasionally, e.g. Titanium Backup, and don't mind messing about in TWRP.
With that said, I highly question why any banking app would check root, mine doesn't and it seems to me like even if it did I could still use their website on my phone while rooted or my Windows machine with no sandboxing whatsoever. Requiring it just for the app seems pretty damn pointless.
At least all German banks have to have an open API for transactions, and I can run my transactions with curl if I wanted to.
A banking app shouldn't care about how I run it, otherwise I'll just throw it out and use one of the open apps for HBCI.
I'm guessing this is a gut feeling as opposed to any empirical data? Either way I'm curious as to why this would be the case. Unless I misunderstand the kernel is identical between LineageOS & whatever stock OS was on the device. And it's the kernel that presumably impacts most on battery consumption.
I installed LineageOS on an old Nexus 5. The stock OS on the Nexus is already pretty clean so I can't say I noticed a massive difference (although I didn't spend much time on it)
EDIT: Realised parent comment was about regular LineageOS, not the microG fork, never mind
This is completely anecdotal however, and it's likely that the reduced battery is down to having installed different/fewer apps on Lineage.
Also, installing SSL Packet Capture showed me that some of my (not even considered shady) apps made a lot of things in the background, eg sending stats or other data to their mothership.
What did do the thing for me was to go into battery settings and set the device in the lowest mode, that severely restricts background work. This, plus airplane, and the device basically doesn't drop anything over a night.
I miss some option (non-root since I want to be able to use bank apps) to tell my phone to never allow anything from apps A, B, and C unless it is active and/or in foreground.
Sorry if I sound like a broken record but to me run at boot, run in background, storage (outside your own not-shared-with-other-third-party-apps sandbox), and network should all be explicitly opt-in.
I find it infuriating when it's obvious some app is draining my phone's battery fast, but I can't see which, because Google is allowing developers to hide that activity within those two generic categories.
Specifically, it allows microG apps (which are open-source and auditable) to impersonate Google Play Services apps (which are closed-source and not auditable) and thus provide their functionality.
There may be many valid reasons to prefer open source software but security audits aren’t one of them.
Open source software is much easier to audit than closed source software. People have a finite amount of time to do things like audit their software.
This is rarely the case unfortunately, and for most of open source prebuilt software you use, you rely on trust and not on audit.
Trusting trust is one of the seminal talks in software.
Open Source vs Closed source is not where I or the security professionals I know put most trust emphasis. I would enthusiastically trust something closed from Google over a rando open source project.
But back to the original point, even the most basic audit steps are the same on an open source project vs closed one. Observe what the binary does & inspect it for standard patterns.
I think having a trusted compiler is an important first step to trusting software, even if you have to analyize it in depth yourself.
https://www.dwheeler.com/trusting-trust/dissertation/wheeler...
But note you are now adding a lot of extra preconditions that are largely not available.
The counter argument is reverse engineering & black box audits are actually easier than getting the conditions right to trust code audits. As a bonus they work regardless of the code availability.
My original claim, that I stand beside, is that code audit-ability for security purposes is not a reason to prefer open source software. For all the reasons this thread points out, that is just as fraught as auditing closed source software. Further, a competent audit of the software would not look much different between open and closed source projects.
Absent a competent audit, there are lots of other factors that are higher on my (and many more knowledgeable peoples) lists for importance to security and privacy than open vs closed source. Things such as documented and approved algorithms, the team involved, the amount of legal backing, the market incentives etc.
That is not to say there aren't reasons to prefer non-Google based API or to prefer open sourced software for other reasons. Just security audit-ability is a bad one.
I never said that. Come on, dude.
Seems waaaay easier than looking for the mythical badCodeGoesHere function.
The thing is this isn't just about network interactions. By taking a quick scan of the code you also (1) might learn something new, (2) can see the athors general attitudes to things, (3) might spot some other nasty activity (does this program hot load code from a remote source, try to obscure what it is doing, scan the file system? Etc)
() No app spoofing () Microg apps can spoof Google apps () Any apps can spoof any apps
This would be similar to how root apps originally allowed anything to use root capabilities (with user permission), and then they made the default "Apps-only".
The only thing this patch does is provide a clean API for it, so that microG doesn't have to patch your entire system every time.
So I hope they will at one point support sandboxed Android apps.
Some won't work if the device is rooted. That's why the latest version of Lineage doesn't come with root.
[1] https://guardianproject.info/2016/03/28/copperhead-guardian-...
How is the collaboration with The Guardian Project and F-Droid announced in [1] going?
Don't you think Copperhead might become a really niche choice given how expensive Pixels (vs Nexus) are?
[1] https://guardianproject.info/2016/03/28/copperhead-guardian-...
Signature spoofing in the past and now can only be enabled on a per-app basis by the user. So the ROM can have signature spoofing support, and the user can have 20 malicious apps installed; none of those 20 apps can spoof signatures unless the user allows it.
It's basically just another permission.
With that said though; if a user blindly-enables the permission on any app that asks, that's a pretty big security issue. But I'd rather have the choice than accommodate uninformed users...
I don't know why. Lack of space on some phones maybe, or they could be configured to autoupdate via wifi only but never see wifi. Whatever the reason, if you use google play services, you'll see a few devices with old versions that don't update even though there is a newer version for that OS version.
(∗) for the occasional banking/railway app
It says to me that they expect it to be super expensive in comparison to other stretch-goals, and that it's not a core goal of the project (and the latter should be true for literally every stretch-goal, in any kickstarter ever).
If I need other apps, I install them with Yalp store or F-droid. Lots of them run fine without Play Services (including Google Maps).
The phone is fast, the battery lasts a lot, slightly better security
Can you recommend a good free gmail client? The default email app doesn't work well with gmail -- double sends every time.
And there's also OsmAnd, which I think deserves a try.
I haven't used Google Maps in a few years, but I initially switched, because OsmAnd was much more reliable with offline maps. I've also heard people say that they've found OsmAnd's maps to be better, especially in more secluded areas.
What am I missing?
Edit: here's the review comment:
> Adnan Begovic > Oct 8, 2015 > > Patch Set 2: > > Also "dangerous" doesn't limit third party apps from using it, you'd have to limit this explicitly to system|signature if you wanted any realm of a security model.
That doesn't sound like "politics" to me. That's a spot-on reply.
> Moreover, to further strengthen the security of our ROM, we modified the signature spoofing permission so that only system privileged apps can obtain it, and no security threat is posed to our users.
I wonder if PackageManagerService is hard coded in many places, rather than using XML dependency injection. If the latter then may it be possible to override the method in a subclass, e.g. MicroGPackageManagerService and distribute the change via a once-only installable zip?
That way Lineage OS doesn't need to break security, only downstream.
LineageOS works without the GApps, but you lose lots of (fundamental) things, like network location and GCM (push notifications). Moreover lots of apps require the GApps API to work (often the Maps API) and crash if the GApps are not installed.
I've been providing a similar fork for the Nexus 6 for a little while: https://forum.xda-developers.com/nexus-6/development/rom-lin...
I use F-Droid because I don't want to use Google services. I do miss voice dialing, though.
Please Google, don't be evil.
Maybe someone else will will find this useful: https://wiki.lineageos.org/devices/
Can this properly support Google Fi and their network-switching magic? Preliminary research claims it's possible.
https://www.reddit.com/r/Nexus6P/comments/5qusmn/lineage_os_...
if you install it from the play store you need to make sure that Project Fi has all of it's permissions granted
The lineage folks didn't want to merge it in on grounds of security concerns.
(I'm not affiliated with the project, I just read the code reviews because I had the exact same question).
EDIT: for those interested: https://review.lineageos.org/#/c/64967/ and https://review.lineageos.org/#/c/65366/
So MicroG people created this fork with the patch builtin.
More info here: https://github.com/microg/android_packages_apps_GmsCore/wiki...
Also http://blogs.fsfe.org/larma/2016/microg-signature-spoofing-s... is an interesting read
No. LineageOS' developers hide behind the "security reasons" shield, but in reality they don't care enough about the freedom of their users to risk to upset Google by giving them an alternative to the Play Services."
LineageOS's have a policy of not circumventing integrity checks e.g.:
https://www.lineageos.org/Safetynet/
The people behind this ROM seem a bit immature if that's how they react to their policy especially since they're just taking the upstream code wholesale to stick their patch in.
I use Whatsapp, Riot (APK from Google Play with GCM enabled), Google Maps, and a bunch of other apps that depend on Maps and GCM services and all of them work fine.
Sometimes I almost forget I don't have GoogleApps installed.
OpenGApps are just the usual bloated proprietary Google Apps, just packaged in a nice and handy way.
But anyway, what's the point if I'm going to use ~10 of proprietary GApps anyway (maps, keep, inbox...) ?
I'm trying to figure out how to rebuild from non-official github repos, then I'll look at setting up a proper automated build of my own.
Works fine for me. I only use Google services to play Ingress and Pokemon GO, and both work without issue with microG.
Only difference when comparing against LineageOS is that the OpenGApps package is "free".
Rather GApps (google) functionality is re-implemented from scratch and the necessary means (app signature spoofing) to replace GApps with microG is built into this LOS fork
I don't know for sure but probably not, the services aren't UserReplaceable.
As you can see, microG doesn't strictly depends on the Google cloud services.
Edit: That license might just be for FOSS components used within google play services, I'm hard pressed to find any specific license anywhere.
That's the most likely route they will take. It keeps their hands clean, as they can drum up a perfectly valid technical reason to break the API.
Also note that most Google ToS don't specifically forbid third party usage (and some also specifically allow them), the only thing that's forbidden is to misuse APIs in a harmful way. Just another example would be the login/account management part of microG, that uses the publicly described OAuth APIs, obviously intended for third-party use.
But then, there's no TOS at this URL, and there's no point in taking this repo down, it would only make Google look bad and give microG free advertisement.
Specifically, it allows the open-source, auditable microG apps to impersonate the closed-source, unauditable Google Play Services apps.
I think the larger problem, the one that caused the microg gang to go this route, is the increasing control Google wants to hold over their platform. Fanatics always promote Android as the "open source alternative" to iOS and Windows Phone, but if you have to strip out so much proprietary gunk that it renders the device unusable, how can they claim it's open source with a straight face? Sure, the core Android code and kernel is still open, but there's a huge difference between being able to boot a device and actually using it daily.
(Edit to add: I agree with everything in your second paragraph.)