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."
People are 100% vigilant all the time.
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.
There are people who don't want any binary blobs from Google on their devices.
I think you mean the reverse?
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.
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.
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"
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 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.
Signature spoofing only affects app you explicitly give permission to use it, and only apps that call for it.
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.