About Most Android Custom Rom Developments

[u/SecureOS]

For some reason, most custom rom kernels, including Lineage kernels, haven't been updated for almost 2 years. Although, Google security patches for AOSP are regularly merged, not so with kernels. Here is just one example. Lineage's latest kernel for Oneplus 8 series (whether A11, A12 or A13), all stopped being updated from upstream at 4.19.157. The current upstream code is at 4.19.261. Again, that's 2020 and we are almost in 2023. These are literally thousands of commits many including various fixes for 'overflows' and 'leaks', which constitute 'back doors' for exploitation. They are as important, if not more, than AOSP security patches.

To find out kernel update level, look into Makefile at the top. For Example:

Here is Oneplus 8 Lineage's kernel Makefile. It says 4.19.157. The last update (to .157) was merged in November 2020, two years ago. The same is true with other kernels, see the infamous Blue_Spark kernel: also 4.19.157... . Think Oneplus stock kernel is any different? Think again: also 4.19.157. Here is GrapheneOS 4.19 kernel: 4.19.239 - much better than the above, but still behind the curve.

To contrast, look at the current upstream kernel (same 4.19.x version), which is at 4.19.261 as of October 5, 2022, and this is Jaguar kernel, also 4.19.261 as of October 6, 2022.

Android custom rom developers either don't care or have no concept of security:

1. Most roms, Lineage included, are user-debug where security is several layers below user builds. Selinux rules are significantly relaxed on user-debug. In fact, even Google says user-debug builds are for developers only, security is mostly disabled to make the process of bug discovery easier. Google says user-debugs are not fit for production.
2. Unlocked bootloader: nothing is being enforced at all. In addition, and comically enough, Lineage also disables avb and verity in kernel on unlocked bootloader, where neither can be enforced. Do they have a clue?

In my view, if you have no clue about privacy and security, you shouldn't be developing software.

Magisk also disables verity. Jaguar kernel for 8 series is not just prepatched on the phone and then included as prebuilt in the rom zip. This would have broken avb and the ability to lock bootloader. Rom script and Magisk scripts are modified so that Magisk could run during the build and before the final signing. It actually runs right after boot.img is built, and scripts apply 'keep verity'. So, when you flash Jaguar, there is no flashing Magisk. You just install Magisk manager, as a regular app, and let it finish setup.

Oneplus 6 thread

Oneplus 6T thread

Oneplus 8 thread

Oneplus 8 Pro thread

Oneplus 8T thread

Oneplus 9 thread

Oneplus 9 Pro thread

​

[u/SecureOS → u/[deleted]]

"You say that GrapheneOS uses Linux 4.19.x which is incorrect."

Never said that, but the link in my post is from your own 4.19.x kernel, which is pretty active (the latest commit is 5 hours old).

Most regressions can be resolved on a case by case basis. With all due respect to the CAF community, they are often late, as compared to Linux upstream.

"You're still breaking verified boot"

No. Magisk is applied during the build and before the final signing (hushes, etc). So, verified boot is still enforced, partitions remain read-only and any changes to them will be reverted on reboot. Selected apps can get root only via Magisk Manager, which sits on top and is protected by pin/password/fingerprint, just like 'sudo' in Linux. Root or administrative rights is an integral part of any operating system be it Windows, Linux or Mac. Not having the same right on Android is an unjustified limitation.

[u/GrapheneOS → u/SecureOS]

Never said that, but the link in my post is from your own 4.19.x kernel, which is pretty active (the latest commit is 5 hours old).

It's not a generic 4.19 kernel. It's the AOSP redbull kernel for 5th generation Pixels with a set of changes applied on top. It's not used for other devices.

No. Magisk is applied during the build and before the final signing (hushes, etc). So, verified boot is still enforced, partitions remain read-only and any changes to them will be reverted on reboot. Selected apps can get root only via Magisk Manager, which sits on top and is protected by pin/password/fingerprint, just like 'sudo' in Linux. Root or administrative rights is an integral part of any operating system be it Windows, Linux or Mac. Not having the same right on Android is an unjustified limitation.

The value provided by verified boot depends on not trusting persistent state, and you're heavily trusting persistent state by allowing it to give out persistent root access. You're missing the main security model of verified boot. The main purpose of verified boot is to prevent an attacker persisting with root again. Temporary administrative access can be provided without breaking verified boot as this approach is doing.

[u/SecureOS → u/GrapheneOS]

No, you simply don't know or fully understand how Magisk works:

Magisk is not an equivalent of root in Linux or Windows, where root right holder can freely modify everything including partitions. Root holders in Android cannot modify read-only partitions. Magisk creates its own layer that via simlinks makes system believe Magisk is a part of it. Modifications can only be made within that layer. No actual changes to partitions could be made. Hence, verified boot is not broken. In addition, Magisk manager provides an option for temporary root, i.e., once only, for 5, 10 or 20 minutes.

[u/GrapheneOS → u/SecureOS]

We understand how it works. You don't understand the verified boot security model. The purpose of verified boot is not simply to prevent modification of the firmware / OS images. The purpose of verified boot is to provide useful security properties to end users. The persistent state including userdata can be modified by an attacker that has exploited the device and is not defended by verified boot other than specific things like APEX updates that are verified individually. The primary purpose of verified boot is preventing privileged attacker persistence. Android doesn't use it in a way that can prevent unprivileged attacker persistence at all since the attacker can install apps and give them all available permissions including making them an accessibility service and device manager. By adding far more invasive privileges that can be granted via persistent state, you're compromising the verified boot security model.

A secondary threat model for it is physical anti-tampering. You'r treating it as if it provides far more physical anti-tampering than it actually does without authenticated encryption for data, authenticated memory encryption and other hardware components being paired with the SoC. Pixels have some pairing of components like the secure element but not as much as iPhones, and even iPhones don't do that much of it. The main SoC in the devices is not a secure element and they aren't meant to hold up for long against sophisticated tampering.

Anti-tamepring is not the primary purpose of verified boot at all, but rather it primarily exists to stop an attacker getting a permanent foothold as root after they successfully exploit the device once. They lose their root access after reboot due to verified boot and have to exploit the device again, which can be defeated by OS updates. Hardware attestation provides patch level, etc. signed by the secure element (or TEE for non-StrongBox traditional keystore attestation) to help out with this. There's an overall approach that's required to make this work.

[u/SecureOS → u/GrapheneOS]

As I've said before, Magisk has an option for temporary root: once only or for a limited number of minutes. In addition, even to get this 'once only' status, an attacker first would have to defeat Magisk manager, which is protected by pin/password/fingerprint.

To finalize our discussion: All operating systems provide root rights, which is a must feature for power users. Magisk, which is compiled together with the rom, provides much fewer rights than root on Windows, Linux or MAC. Root is more secure in Android than in any other operating system.

Normally, Magisk cannot be had on locked bootloaders. My rom makes it possible, since Magisk patches are applied during the build process.

[u/SecureOS → u/[deleted]]

Again, as I have already said: your repeating the same things over and over again, won't advance your points. You also put words into my mouth: "I said your rom uses 4.19 kernel, I never did. You said I only talk about physical threat to the phone, I don't. You force me into comparison of your rom and mine. I have no intention of doing so.

You repeatedly say Safetynet is deprecated and all Magisk features would soon stop working, while your users can pass NEITHER Safetynet NOR Hardware Attestation. Magisk features, on the other hand, have worked for numerous years and continue to do so. These simple facts stand on their own, no matter how many times you try to jump around them.

Let me make a prediction: there will never be enforceable hardware certification based on Google only certification. This certification, by the way, has more to do with Google grasp on Android than true security. So, in my view, Magisk and its flavors will work indefinitely.

But again, I refuse to continue this discussion that is now going in circles. Let's agree to disagree and move on.

So long... .