Well, you get weekly updates, and you can see what changes are made. Most of them are security ones, and you're getting them 4/5 times a month vs once per month with stock Android in my previous experience.
For example, here you can see the changekog for the Motorola Moto G7 Plus.
I don't think this can be compatible woth corporate policies, though. As an end user, I'm more than satisfied.
> corporate settings that do ha
Use a dedicated phone
As for the Android stack itself, LineageOS follow the upstream Android branches very closely where it can. Most vulnerabilities in that stack will probably be shared among devices, so security issues will probably be fixed within a reasonable amount of time. Google's Android patches should also be present in the nearest weekly updates after public release.
The lack of official driver and kernel patches make the security of LineageOS a little strange. There are definitely some patches that LineageOS can apply, but in the end they rely on the vendor to publish all the necessary patches, and that can take a while.
There's also the fact to consider that out of necessity, the bootloader on the phones is unlocked. Most phones won't allow you to lock it again with your own keys (if you try, you'll often brick the device!) so it's trivial for a malicious actor to flash a new OS full of spyware and key loggers onto the system partition.
Having said that, LineageOS supplies weekly updates to my Oneplus One, even though it's showing its age. Neither Qualcom nor Oneplus will ever release any more patches for this device, so for kernel level security I'm boned. However, I still get the latest and greatest Android 11 framework security patches. This should protect the phone against the huge Bluetooth exploit found a few years back despite it being over eight years old now.
LineageOS is quite transparent about this, even showing that their device is missing patches right inside the settings (https://www.xda-developers.com/lineageos-trust-centralized-i...). I don't think you can expect much more from a project run by volunteers.
My daily driver phone receives "quarterly" security updates (sometimes off by a month or so) so I'd rate LineageOS above Xiaomi in this sense. The LOS Android stack itself should also be on par with or even better than some flagship phones.
Sadly, for the complete picture, Qualcom and other manufacturers determine how secure LineageOS can be. In general, the bootloader lock status and lacking supply of source code are a real pain for open source efforts. Some phones may see a mainline kernel with all of the recent Linux patches as a result of the postmarketOS efforts (https://wiki.postmarketos.org/wiki/The_Mainline_Kernel) but cleaning up vendor code and reverse engineering drivers isn't exactly a fast process.
I personally think the booloader lock is of dubious value. It protects against physical attacks against the device (evil maid attacks).
That's very low in the list of threats I worry about.
(Though I am using GrapheneOS, and am happy with it.)
I'd be more worried about the lag between Android security patches (and vendor blobs, which GrapheneOS gets direct with android updates, from what I can tell) and custom ROM updates.
You're much more likely to get hit by some Samsung zero day that impacts 100M active devices than something targeting a custom ROM.
(All of this is assuming you're a boring target, which most people are.)
Anyway, the main deciding factor for me between the two operating systems was device support.
I have no experience with GrapheneOS, but I've heard good stories so far. It's very good to hear that the Pixel devices allow re-locking of the bootloader.
Personally, I consider exploits in the Android framework itself and drive-by-exploits (like BlueFrag) to be the most important security vulnerabilities so I'm fine with LineageOS.
Not everyone might agree, though, and custom ROMs come with some security challenges or problems that stock software does not. I don't think such flaws should be left out of discussions like these.
Security is not their top competency, nor mission.
Check out the pages on GrapheneOS.org, definitely seems they're who you're after.
LineageOS's first priority isn't security - it's freedom. Graphene and CalyxOS have security as the first priority - but have only a couple of phones on their support list and they deprecate old devices as soon as they stop receiving vendor updates.
`userdebug` is used to have a few specific debugging capabilities that aren't available on a `user` ROM. Note that this is not the same as the standard `userdebug`, as most security measures that would otherwise get removed are manually reinstated.
> pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.)
So... no security fixes at all are better in your opinion?
> ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates),
Where are you getting this from? Neither F-Droid nor its privileged extension is included in the system.
> don't support locking the bootloader to enable verified boot on many supported devices
There is nothing that inherently prevents you from relocking your bootloader on LineageOS. But technically, something may go wrong at any time, so it neither is officially supported nor endorsed, and the keys necessary for relocking the bootloader are not provided.
If someone wants to, they can always just build LineageOS themselves (with all system modifications built-in, because anything else would break the signature), sign it with their own keys, and reconfigure their bootloader to use that key.
They don't "pretend" anything. They are very clear that, after a device no longer gets kernel/driver updates from the manufacturer, they can only provide OS/framework updates.
> don't support locking the bootloader to enable verified boot on many supported devices
Can you expand on this more? My understanding was that you could do this on Pixel phones, but that no other manufacturer supports adding user keys to the bootloader.
The point is, it's not as secure to run around with this disabled.
No, it's not only about in-person or targeted attacks.
What specific security problem does this cause?
> pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.)
This is good for security. Not everyone can afford to get a new phone as soon as the vendor drops support, and just because you can't fix everything doesn't mean that you shouldn't fix what you can.
> ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates)
What's incorrect about it?
> don't support locking the bootloader to enable verified boot on many supported devices
This isn't really their fault. On most devices, relocking the bootloader with anything non-stock has a high chance of permanently hard bricking.
No, it isn't. It's good for reducing e-waste, your security is on the line.
Having the newly shaped and colored Android UI doesn't do anything to fix security issues..
But, importantly, they also care about security, and you'll get security updates faster and more often than with the vendor's stock ROM.
This is sarcasm, to be clear.
(on my device, it is possible to just "fastboot oem lock", but that is aside the point)
Can you provide evidence for this?
From another subthread:
> They ship userdebug builds as production releases, pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.), ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates), don't support locking the bootloader to enable verified boot on many supported devices, etc..
I don't see any evidence for your claim there.
> From another subthread:
Replied in that one.
If you want to skip paying $150 for a Pixel to use on Graphene or Calyx or something halfway decent, and "just use Lineage how bad could it be", be my guest!
Also, for supported Pixels $150 or less, https://swappa.com only has the Pixel 3a, which loses manufacturer support next month, and the Pixel 4, which loses manufacturer support 6 months from now.
In addition to providing a stable platform to build upon, Android gives additional support to developers in a number of ways. The Android security team looks for potential vulnerabilities in apps and suggests ways to fix those issues. For devices with Google Play, Play Services delivers security updates for critical software libraries, such as OpenSSL, which is used to secure app communications. Android security released a tool for testing SSL (nogotofail) that helps developers find potential security issues on whichever platform they are developing.
Vs.
>Android is designed for users. Users are provided visibility into the permissions requested by each app and control over those permissions. This design includes the expectation that attackers would attempt to perform common attacks, such as social engineering attacks to convince device users to install malware, and attacks on third-party apps on Android. Android was designed to both reduce the probability of these attacks and greatly limit the impact of the attack in the event that it was successful. (Read: Handcuff users to keep them from violating developer expectations and assumptions)
>Android security continues to progress after the device is in the user's hands. Android works with partners and the public to provide patches for any Android device that is continuing to receive security updates. (Read: we work with developers (them again)* to provide patches to devices that are convenient to deliver patches to)
>More information for end users can be found in the Nexus help center, Pixel help center, or your device manufacturer’s help center. (Read: we take no responsibility for explaining how any developer's use of this power is exercised, ask them!)*
>This page outlines the goals of the Android security program, describes the fundamentals of the Android security architecture, and answers the most pertinent questions for system architects and security analysts. It focuses on the security features of Android's core platform and doesn't discuss security issues that are unique to specific apps, such as those related to the browser or SMS app. (Again, even when talking about users, the language drifts back to people we'd lump under developers... who exactly is the User here?)
Then this gem:
>Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption (oh, is corruption where user programs are classed under?).
It establishes a full chain of trust (for whom, OEM's again?), starting from a hardware-protected root of trust to the bootloader (whose root of trust, OEM?), to the boot partition and other verified partitions.
Sorry, but the language used to describe all of this completely lets the cat out of the bag on who the Android community holds to be the true benefactors of your "ownership" of a handset.
https://source.android.com/security/
Straight from the source. Quiet parts emphasized and said out loud by me.
Android is the most transparently User/operator hostile piece of Open Source software I have ever had the misfortune of laying my eyes upon. The fact you basically have to be a developer to list and understand the things you need to do to get anything non-trivial done speaks volumes.
How does it compare to flagship Samsungs/Pixels/iPhones? Is it usable in, say, corporate settings that do have some security standards in the vein of "two years old iPhone OK, six years old Android not"?