ROM: Ungoogled Stock

[tdm 2,322]

2 hours ago, okayphoneme said:

I appreciate the explanation, thank you.

I've been reading up on Lineage and I'm not super keen on it now - the project seems to put an emphasis on features over security - which is fine, but I think I'm actually interested in using something like the Ungoogled ROM you've posted here. The thing is, I'd like to make some modifications to it (entirely for my own purposes). I can see the stuff in the Android source that I would change but my knowledge of how the whole thing slots together is rather limited.

My question is: is there a way of merging in the proprietary (binary) bits of this BSP into AOSP so that I can obtain something similar to what you have here, or is not having access to the source going to scupper idea that completely?

 

That's an interesting perspective.  May I ask how you came to that conclusion?  My feeling is exactly opposite.

 

The OEM may or may not provide security updates for a period of time after release.  My copy of the BSP is on tag LA.UM.7.4.r1-05500-8x98.0 which was released August 23, 2019.  Incremental updates may have newer code, I'm not sure because I don't do OTAs.  But either way, IdeaLTE will stop publishing updates at some point.

 

As a member of Lineage and former Cyanogen employee, I can assure you that many/most of the Lineage developers care a great deal about security.  You can see the evidence -- Lineage faithfully merges security patches every month, even for older releases.  So at some point Lineage is assuredly going to be more secure than stock.

 

The direct answer to your question is yes, but not easily.  You can create your own source tree based on the publicly available qcom BSP, merge in any missing security patches, and then add in the vendor blobs just like Lineage does.  But it's quite a lot of work.  I did exactly this some years ago for my devices using jellybean and kitkat.  If you are interested in going this route, I would suggest looking on XDA for one of the "pure" Android ROMs and use that as a starting point.  And even after you do all that, you have a set of vendor blobs that are frozen in time and may have security issues which cannot be patched at all.

 

Edited January 10, 2020 by tdm

[Polaris 423]

4 hours ago, okayphoneme said:

I've been reading up on Lineage and I'm not super keen on it now - the project seems to put an emphasis on features over security

Features over security?  Humm, that hasn't been my experience... more like extra security plus bonus features.

Edit: I replied before switch to this new page where I saw tdm's response.  His is much more elaborate, lol.

Edited January 10, 2020 by Polaris

[okayphoneme 28]

2 hours ago, tdm said:

That's an interesting perspective.  May I ask how you came to that conclusion?  My feeling is exactly opposite.

There are some concerns raised here, for example - I don't know if they still apply, one year later:

https://www.reddit.com/r/CopperheadOS/comments/917yab/can_anyone_technically_explain_why_lineageos_as/

[tdm 2,322]

10 minutes ago, okayphoneme said:

There are some concerns raised here, for example - I don't know if they still apply, one year later:

https://www.reddit.com/r/CopperheadOS/comments/917yab/can_anyone_technically_explain_why_lineageos_as/

Uhhhmmmm, you do realize that the Copperhead team is rather antagonistic to Lineage, right?  It's not surprising that they would slam Lineage as being insecure.  They do raise some valid points (particularly about verified boot), but most are bogus and/or outdated.

 

Verified boot requires a locked boot loader.  You cannot run any custom software with it enabled, including this ROM.  That may be fine at the time of release (though with a BSP that is already 4 months out of date, probably not).  But as soon as the OEM stops updating, you have a choice of running with verified boot and known security issues or running with an unlocked boot loader and getting security fixes with custom software.  Personally, I'll choose the latter every time.

 

Some responses to the other issues:

• ffmpeg, is long since gone, it has not been present since CM 13.x (that's before Cyanogen died and Lineage was created).
• CAF code is OEM code that gets released.  There are no alpha/experimental commits, but there are many security fixes.  You want the newest code to be up to date and have the latest security patches.
• For firmware, Lineage cannot ship proprietary bits.  Only your OEM can do that.  But there are different levels of firmware.  Much of the stuff in vendor will be freshly built and up to date in Lineage long after the OEM stops updates.
• Lineage does not, in general, disable or weaken any selinux rules that affect device security.  That would be silly.

 

I realize that everyone has different opinions on security.  If you feel that Lineage is not secure enough for you -- perhaps you value verified boot -- then by all means, run stock.  But as for me and quite a few other folks, we value the up to date security fixes that Lineage offers long after the OEM has stopped updating.

 

I'll also mention that I personally don't trust a no-name Chinese OEM (sorry idealte, it's true) to not do something stupid and/or sneaky.  There are plenty of examples of smaller OEMs putting back doors, malware, and other things into stock software.  Here's a quick example that popped up on the top of my duckduckgo search:

 

https://www.nowsecure.com/blog/2017/11/14/oneplus-device-root-exploit-backdoor-engineermode-app-diagnostics-mode/

 

 

[silversolver 849]

13 minutes ago, tdm said:

I'll also mention that I personally don't trust a no-name Chinese OEM (sorry idealte, it's true) to not do something stupid and/or sneaky.  There are plenty of examples of smaller OEMs putting back doors, malware, and other things into stock software.

Can't disagree, BUT on the other hand, if you have that concern, you can always flash the image Chen provided over the top as soon as you get the device to verify that the manufacturer didn't do anything sneaky. Or are you saying they built the image and Chen may not even know what's in it?

That's not to say I'm not eagerly awaiting your success. :)

Edited January 10, 2020 by silversolver
mysterious

[tdm 2,322]

10 minutes ago, silversolver said:

Can't disagree, BUT on the other hand, if you have that concern, you can always flash the image Chen provided over the top as soon as you get the device to verify that the manufacturer didn't do anything sneaky. Or are you saying they built the image and Chen may not even know what's in it?

That's not to say I'm not eagerly awaiting your success. 🙂

 

FxTec does not build anything.  Chen only distributes what FxTec gets from IdeaLTE.

 

EDIT: And further, I know that FxTec does not have the device signing keys.  So if they did build something, it wouldn't boot with a locked boot loader.

 

 

Edited January 10, 2020 by tdm

[silversolver 849]

2 minutes ago, tdm said:

 

FxTec does not build anything.  Chen only distributes what FxTec gets from IdeaLTE.

 

EDIT: And further, I know that FxTec does not have the device signing keys.  So if they did build something, it wouldn't boot with a locked boot loader.

 

 

OH! Well then. I guess eternal vigilance will be needed on the part of the stock users.

[okayphoneme 28]

1 hour ago, tdm said:

Uhhhmmmm, you do realize that the Copperhead team is rather antagonistic to Lineage, right?  It's not surprising that they would slam Lineage as being insecure. 

I'm mostly concerned with the facts. Either the claims are true or not...

1 hour ago, tdm said:

Verified boot requires a locked boot loader.  You cannot run any custom software with it enabled, including this ROM.  That may be fine at the time of release (though with a BSP that is already 4 months out of date, probably not).  But as soon as the OEM stops updating, you have a choice of running with verified boot and known security issues or running with an unlocked boot loader and getting security fixes with custom software.  Personally, I'll choose the latter every time.

Verified Boot does concern me. It's not absolutely critical, but I'd like to have it running if possible and didn't, in fact, realise that LineageOS was missing this functionality at first. Ideally I would like to have built and signed releases myself using my own keys.

1 hour ago, tdm said:

Some responses to the other issues:

• ffmpeg, is long since gone, it has not been present since CM 13.x (that's before Cyanogen died and Lineage was created).
• CAF code is OEM code that gets released.  There are no alpha/experimental commits, but there are many security fixes.  You want the newest code to be up to date and have the latest security patches.
• For firmware, Lineage cannot ship proprietary bits.  Only your OEM can do that.  But there are different levels of firmware.  Much of the stuff in vendor will be freshly built and up to date in Lineage long after the OEM stops updates.
• Lineage does not, in general, disable or weaken any selinux rules that affect device security.  That would be silly.

I realize that everyone has different opinions on security.  If you feel that Lineage is not secure enough for you -- perhaps you value verified boot -- then by all means, run stock.  But as for me and quite a few other folks, we value the up to date security fixes that Lineage offers long after the OEM has stopped updating.

Ok, fair enough,

1 hour ago, tdm said:

I'll also mention that I personally don't trust a no-name Chinese OEM (sorry idealte, it's true) to not do something stupid and/or sneaky.  There are plenty of examples of smaller OEMs putting back doors, malware, and other things into stock software.  Here's a quick example that popped up on the top of my duckduckgo search:

https://www.nowsecure.com/blog/2017/11/14/oneplus-device-root-exploit-backdoor-engineermode-app-diagnostics-mode/

Of course, I completely agree. Are the idealte bits not used at all for Lineage?

[tdm 2,322]

59 minutes ago, okayphoneme said:

Verified Boot does concern me. It's not absolutely critical, but I'd like to have it running if possible and didn't, in fact, realise that LineageOS was missing this functionality at first. Ideally I would like to have built and signed releases myself using my own keys.

 

That is not possible.  If it were, anyone could do the same and it would defeat the purpose of verification.  Only the OEM has the signing key and only the OEM can create signed images to pass verified boot.

 

Quote

Are the idealte bits not used at all for Lineage?

 

As mentioned, yes, some of the IdeaLTE bits/blobs are used to build Lineage.  But only those necessary to support the hardware.  In general, OEMs that do stupid and/or sneaky things place them into the upper layers of Android which Lineage does not use.

 

Briefly, code running on Qualcomm devices (and most/all Android devices) can be divided into four broad categories:

 

1. The modem co-processor

This is entirely closed source.  You have no choice but to trust it if you want to use phone.

2. The trusted execution environment (TEE)

Same, entirely closed source.

3. The boot loader

This is the "BIOS" of the phone.  It is mostly closed source, but I have access to some of it via the BSP.  In particular, the abl code (though, of course, it is not absolutely guaranteed that idealte published the same code that they used to build the release bits).  You mostly have to trust it to use your phone.

4. The upper layers

This is the code that we can control, for the most part.  It can further be divided into boot/kernel, vendor, and Android/AOSP.

4a. Boot/Kernel

Lineage builds this entirely from source.  OEMs can introduce security issues here, but the code is open and you can be assured that Lineage built kernels will not have any such issues.

4b. Vendor

The vendor code consists of both lower layers to support hardware and upper layers to support ... other things.  Lineage needs the hardware bits -- things like camera, fingerprint, gps, and such.  Lineage does not need or build the upper layers -- things like vendor-specific apps (including adups OTA support) and such.  These upper layers are where vendors will typically place malware, backdoors, and such.

4c. Android/AOSP

Lineage builds this entirely from source.

 

So the takeaways are (1) you need to trust a certain amount of closed source bits on your device for it to function, and (2) Lineage takes the only the closed source bits that are necessary for hardware support and nothing else.

 

As always, remember that security and trust are never absolutes.  You decide what you trust and what are acceptable risks and tradeoffs.  Lineage attempts to minimize the amount you need to trust by using the most open source code possible.  But in order to do this, it needs to have verified boot disabled.

 

EDIT: Regarding the vendor hardware bits, there are some 1000 files that are needed for full hardware support on msm8998.  Qualcomm has different levels of OEM licenses that afford different levels of access to the sources for these files.  IdeaLTE appears to have a rather low level (read: cheap) license.  The BSP that they published has roughly half of the files closed source and prebuilt straight from Qualcomm.  They have access to the source and do build roughly the other half.

 

Edited January 10, 2020 by tdm

[okayphoneme 28]

6 minutes ago, tdm said:

That is not possible.  If it were, anyone could do the same and it would defeat the purpose of verification.  Only the OEM has the signing key and only the OEM can create signed images to pass verified boot.

Maybe it's limited to certain devices, but the Android docs mention this as a possibility (CopperheadOS / GrapheneOS uses it). If you provide a key when the bootloader is unlocked, then it should be possible to install signed updates after relocking.

[tdm 2,322]

Just now, okayphoneme said:

Maybe it's limited to certain devices, but the Android docs mention this as a possibility (CopperheadOS / GrapheneOS uses it). If you provide a key when the bootloader is unlocked, then it should be possible to install signed updates after relocking.

This is news to me.  I'm not terribly familiar with qcom devices on this level, but in the past when I was working at Cyanogen, I had a co-worker sign a new device with a freshly generated key.  He told me that it was a one-time operation that could not be reversed or changed.  I'd be interested in hearing more about this.  But even if it is possible, I have strong doubts that any mainstream device would be setup to do this.

 

[okayphoneme 28]

15 minutes ago, tdm said:

This is news to me.  I'm not terribly familiar with qcom devices on this level, but in the past when I was working at Cyanogen, I had a co-worker sign a new device with a freshly generated key.  He told me that it was a one-time operation that could not be reversed or changed.  I'd be interested in hearing more about this.  But even if it is possible, I have strong doubts that any mainstream device would be setup to do this.

 

There's a bit more info here:

https://source.android.com/security/verifiedboot/device-state

So your co-worker was right (the original key is permanently baked into the hardware), but you can also in theory supply another key to use. It guess this feature isn't widely implemented though (or at least, nobody cares / hasn't tried it) - supposedly OnePlus 5/5T and a Xiaomi phone in addition to Google's own devices.

Edited January 10, 2020 by okayphoneme

[tdm 2,322]

8 minutes ago, okayphoneme said:

There's a bit more info here:

https://source.android.com/security/verifiedboot/device-state

So your co-worker was right (the original key is permanently baked into the hardware), but you can also in theory supply another key to use. It guess this feature isn't widely implemented though (or at least, nobody cares / hasn't tried it) - supposedly OnePlus 5/5T and a Xiaomi phone in addition to Google's own devices.

Well, what do you know ... the qcom bootloader in the bsp does reference avb_custom_key.  I'll have to dig more to see if it's actually enabled and usable.

 

Thanks!

 

[tdm 2,322]

Well, this looks promising...

 

tommy@neuron:~$ echo x > foo
tommy@neuron:~$ fastboot flash avb_custom_key foo
target reported max download size of 536870912 bytes
sending 'avb_custom_key' (0 KB)...
OKAY [  0.009s]
writing 'avb_custom_key'...
OKAY [  0.003s]
finished. total time: 0.011s
tommy@neuron:~$ fastboot erase avb_custom_key
erasing 'avb_custom_key'...
OKAY [  0.003s]
finished. total time: 0.003s
tommy@neuron:~$ 

 

[Noob 158]

Thanks @tdm for this build, this is awesome.  My only question is, in the absense of OTA, how feasible is it to create updated builds?  And I presume there'd be no data loss on upgrade, like updating LOS?

9 hours ago, tdm said:

As a member of Lineage and former Cyanogen employee, I can assure you that many/most of the Lineage developers care a great deal about security.  You can see the evidence -- Lineage faithfully merges security patches every month, even for older releases.  So at some point Lineage is assuredly going to be more secure than stock.

I noticed that last week when I did my first LOS build for my Droid 4, Android security patch level is "5 December 2019".   

Edited January 11, 2020 by Noob

[tdm 2,322]

4 hours ago, Noob said:

Thanks @tdm for this build, this is awesome.  My only question is, in the absense of OTA, how feasible is it to create updated builds?  And I presume there'd be no data loss on upgrade, like updating LOS?

That's entirely up to how often I get bsp updates. IdeaLTE gives updates to FxTec on request and they are passed along. So I can't just grab the latest code on demand.

 

Yes you can upgrade without data loss. Generally you should always be able to update the same ROM without loss. You only need to wipe when switching ROMs.

 

[Zamasu 258]

@tdm

Thank you so much for the information you're posting here, it's very interesting. I do have a question about the "firmware" though, some people say that custom ROMs will lack the firmware updates that official (still supported) ROMs have, and thus can be less secure in that way. Are they talking about what you're calling the "vendor bits" for hardware support? And how out of date could these be for this ROM or LineageOS for the Pro1?

[tdm 2,322]

6 hours ago, Zamasu said:

@tdm

Thank you so much for the information you're posting here, it's very interesting. I do have a question about the "firmware" though, some people say that custom ROMs will lack the firmware updates that official (still supported) ROMs have, and thus can be less secure in that way. Are they talking about what you're calling the "vendor bits" for hardware support? And how out of date could these be for this ROM or LineageOS for the Pro1?

 

In this case, I would take "firmware" to mean everything closed source.  Particularly the abl partition and the vendor bits for hardware support which occasionally have security issues.

 

The official Lineage policy for device maintainers is to assert on the latest firmware version from the OEM (eg. fail to install if it is out of date).  Some maintainers are better than others at following through on this.

 

Here's an example of how this is supposed to work.  I have been using OnePlus devices for the last year or so.  Every time they release a new firmware, the maintainer extracts it from the package, makes a recovery flashable package out of it, and posts it for download.  He also updates the vendor blobs on TheMuppets and updates the firmware version to be asserted.  When I go to flash the lasted Lineage ROM on an outdated firmware, it tells me this, and I have to go through the (annoying but more secure) process of downloading the updated firmware and flashing it first.

 

[tdm 2,322]

So I've been thinking about this custom key that AVB allows, and I've also read a bit of the source for abl where it's implemented.  I've come to the conclusion that AVB is worthless at best and dangerously misleading at worst on devices that have Secure Boot (*) disabled, and the Pro1 is such a device by design.  Let me explain...

 

The security that AVB intends to provide is to ensure that you are running code that has been signed, either by your OEM or by your custom ROM vendor that does AVB signing (Copperhead, Graphene, etc.)  Note that it does not ensure the integrity of your data nor that your data has not been decrypted -- it's only about the system/vendor code.  This is all good in theory, as long as there is an unbroken chain of trust.  But when Secure Boot is not enabled, the chain of trust is broken.  xbl will not verify abl, and abl may be modified by an attacker.  All it takes is a root exploit or access to EDL mode.  Once that happens, abl can be modified to always pass the custom key check no matter what it finds in the boot partition.  Then the boot partition can be modified with any kernel of the attacker's choosing while still showing you a yellow boot state.

 

Now, I'm not a security guy.  I am somewhat interested in security issues but I am pretty bad at spotting security flaws in code and I would never even so much as call myself a hacker.  So you can be guaranteed that if I thought this out independently in less than a day, pretty much all attackers that are even halfway serious would also be aware of this.  I presume this is why Copperhead and Graphene are only available for select devices, and I certainly hope that they make it known to users in big, bold print that AVB is worthless when Secure Boot is not enabled.

 

Now, having said all that, it is probably possible to enable Secure Boot on a Pro1 and enjoy all this security goodness.  But if anything goes wrong, you'll have an expensive paper weight.  Who's going to be the first to try?  😄

 

(*) Secure Boot is Qualcomm's implementation of the chain of trust from the lowest level of the boot loader up to the Linux kernel.  It uses a key that is baked into the hardware (this was referenced a few posts ago) using a physically destructive and irreversible process.  The secure boot flag itself is also stored in the same manner and, once enabled, can never be disabled on a given device.

 

Edited January 11, 2020 by tdm

[silversolver 849]

16 hours ago, Noob said:

Thanks @tdm for this build, this is awesome.  My only question is, in the absense of OTA, how feasible is it to create updated builds?  And I presume there'd be no data loss on upgrade, like updating LOS?

I noticed that last week when I did my first LOS build for my Droid 4, Android security patch level is "5 December 2019".   

Oooh, how's it running? I might like a copy of your build! I'm still dailying a D4!

[silversolver 849]

1 hour ago, tdm said:

Now, having said all that, it is probably possible to enable Secure Boot on a Pro1 and enjoy all this security goodness.  But if anything goes wrong, you'll have an expensive paper weight.  Who's going to be the first to try?  😄

Ya, nope. I'll just not give root access to questionably-sourced code.

Realistically, it's unbelievable how bad the security flaws in most devices are. It's the dumb people touching the screen! 😒

@VaZso might have an extra device soon that he'd potentially sacrifice to science. 😂

Edited January 11, 2020 by silversolver

[VaZso 1,988]

28 minutes ago, silversolver said:

@VaZso might have an extra device soon that he'd potentially sacrifice to science. 😂

 Sure, why not. 

Anyway, I would like to try Sailfish OS on it (after checked if it works correctly using stock firmware) after having some protection foils also on that device.
I may also try other things but definitively not as much as if I were a beta tester as I would not like to worn out it's built-in flash too far as being my spare device to be used later in case my current Pro1 has problems.

[tdm 2,322]

So just a quick update regarding Secure Boot.  I had considered posting a new thread about this but I'm not sure it's warranted.  So I'll just drop this here...

 

I spoke with FxTec and they confirmed that they disabled Secure Boot intentionally.  The rationale was that it makes the device more developer friendly, especially for non-Android OS's.  I'm not sure I agree with this conclusion, but that is/was the decision.  The one thing that disabling Secure Boot allows is building a custom abl (boot loader).  I have yet to see anything that requires a custom abl.  But it does leave the door open for me to reconfigure the device as non-AB and reclaim that 4gb of storage without getting the OEM to rebuild and sign a custom abl.  Which is good, because I have doubts that they would be willing to do that.

 

[Sean McCreary 328]

As a former computer security professional, I want to emphasize that everything tdm has said is correct. But any serious discussion about security needs to be very concrete about the threat model, or it becomes very difficult to determine what the effects of any change might be. Google has produced a detailed white paper describing the security model of Android, and it lists 15 different threats in section 2.3. Only the first two critically depend upon secure boot, i.e. the cases where, "Adversaries can get physical access to Android devices," and the primary attack vector involves modifying the system software installed on the device. All the other threats can be mitigated at a higher level, whether secure boot (or AVB) is enabled or not.

Also, please remember that secure boot only provides the root of the chain of trust. In order to keep the chain from breaking, the bootloader must not be unlockable without cryptographic authentication. Otherwise, malicious code could change the unlock flag directly, and even a signed, trusted abl would then honor the 'trojaned' unlock flag. If you really think secure boot is necessary, then you are also arguing for F(x)tec to restrict bootloader unlocking,

On 1/10/2020 at 7:02 AM, okayphoneme said:

I've been reading up on Lineage and I'm not super keen on it now - the project seems to put an emphasis on features over security

This is completely wrong. I my experience, LineageOS has always chosen security over features, including refusing to accept unnecessary closed-source components, and insisting that all devices have well designed SELinux policy. IMHO the most important reason for using LineageOS is when it provides security fixes for devices that are no longer supported by their OEMs.

On 1/10/2020 at 3:00 PM, okayphoneme said:

Ideally I would like to have built and signed releases myself using my own keys.

As tdm pointed out, this is not possible given the security model used by Qualcomm and the OEMs. They aren't securing the device for you, they are securing the device for the OEM. If you don't trust the OEM, then secure boot doesn't buy you anything.

[Noir 112]

thanks alot @tdm for your work,

has anyone tried to use microG with this build? I am not experienced with microG, but I am trying to gain some knowledge about it. Having admitted that sorry if this question is unnecessesary, but maybe an answer is possible nevertheless.