Linux Phones [are less secure than mainstream Android](madaidans-insecurities.github.io)
madaidans-insecurities.github.io
Linux Phones [are less secure than mainstream Android]
https://madaidans-insecurities.github.io/linux-phones.html
85 comments
It always depend of your definition of security, I'm personally prevented from checking those claims on Android so I trust it much less than my Linux laptop, despite whatever Google could claim. Additionally, who knows what's really running in userland in Android...
I trust my versions of Linux infinitely more times than anything corporate made, despite the claims, just as you succinctly said.
Did people switch because Linux was thought to be more secure, or did they switch because they were sick of Apple?
While everything the author writes makes sense to me, I think the kind of security threats he focuses on aren't the main concern for most people.
What % of Android devices have their bootloader unlocked or root enabled? Or have the ability to enable signature spoofing for MicroG? I doubt that malware targeting such weaknesses would be economically profitable to develop, considering also that the typical hardcore user is less likely to just install random Play Store or unverified APKs .
This seems a list of security weaknesses against _targeted_ attacks - the inclusion of "evil maid" attacks is exemplary. If somebody gains physical access to my phone, by far the greatest risk to me is that they will steal it and immediately wipe it, not that they will install bootloader malware and put it back.
So yeah, if you're e.g. a professional user and might be the target of industrial espionage, follow the author's advice to the T (going with GrapheneOS or not depends on whether your company trusts Google with your business data). Graphene > Google > Lineage > Linux. If you just don't want to have your personal data tracked by Google and want better control over the apps you install, Graphene > Lineage > Linux > Google.
What % of Android devices have their bootloader unlocked or root enabled? Or have the ability to enable signature spoofing for MicroG? I doubt that malware targeting such weaknesses would be economically profitable to develop, considering also that the typical hardcore user is less likely to just install random Play Store or unverified APKs .
This seems a list of security weaknesses against _targeted_ attacks - the inclusion of "evil maid" attacks is exemplary. If somebody gains physical access to my phone, by far the greatest risk to me is that they will steal it and immediately wipe it, not that they will install bootloader malware and put it back.
So yeah, if you're e.g. a professional user and might be the target of industrial espionage, follow the author's advice to the T (going with GrapheneOS or not depends on whether your company trusts Google with your business data). Graphene > Google > Lineage > Linux. If you just don't want to have your personal data tracked by Google and want better control over the apps you install, Graphene > Lineage > Linux > Google.
> if you just don't want to have your personal data tracked by Google and want better control over the apps you install,
Which is the most common security risk for common people let's be realistic. Yeah they are we could say ""protected"" by the trusted boot but in reality the google & manufacturer blobs sending their data somewhere are their main security threat, much more than any other kind of attacks.
Which is the most common security risk for common people let's be realistic. Yeah they are we could say ""protected"" by the trusted boot but in reality the google & manufacturer blobs sending their data somewhere are their main security threat, much more than any other kind of attacks.
The article also mentions a lot of things that will make it generally easier for remote attackers to gain a "permanent" foot in the door once they find a way in (e.g. an exploitable "app"), like the lack of "app" sandboxing (for the most part).
> given the amount of people that claim to have switched to Linux Phones
If any significant number of people had switched, we’d have seen announcements by Purism and Pine.
If any significant number of people had switched, we’d have seen announcements by Purism and Pine.
But Linux based phones might be better in terms of privacy and data collection en mass, and giving back to society via open source software and hardware.
Large firms offer platforms that are secure against anyone other than themselves (and their partners, such as states).
Google tracks and collects huge data through various channels, and Apple scans your information in your own device (and its operating system is even closed source and cannot be verified). Their platforms might be incrementally more secure against advanced expensive attacks, e.g., targeted attacks performed by a company such as NSO.
If you are an average user, do you worry more about maximizing the security or major privacy concerns, namely: automatic mass data collection, tracking and profiling by governments and those in power, or fancy attacks targeted to you?
Large firms offer platforms that are secure against anyone other than themselves (and their partners, such as states).
Google tracks and collects huge data through various channels, and Apple scans your information in your own device (and its operating system is even closed source and cannot be verified). Their platforms might be incrementally more secure against advanced expensive attacks, e.g., targeted attacks performed by a company such as NSO.
If you are an average user, do you worry more about maximizing the security or major privacy concerns, namely: automatic mass data collection, tracking and profiling by governments and those in power, or fancy attacks targeted to you?
I was overseas recently checking out the Huawei Harmony OS devices and did stop to consider that while the Chinese could be spying on me with their distribution, they’d totally lack authority over me and may be less inclined to provide account details as Google will do for location based dragnet requests.
I d be cautious of that approach given Apple's history in China. Your use case is a mirror image of it (Apple in China).
> Apple scans your information in your own device (and its operating system is even closed source and cannot be verified).
Open source may be better in certain ways, but a statement that closed source cannot be verified as to what it’s doing is narrow and incomplete. Android’s key parts are also closed source (there’s a lot more in “Android” than AOSP).
Open source may be better in certain ways, but a statement that closed source cannot be verified as to what it’s doing is narrow and incomplete. Android’s key parts are also closed source (there’s a lot more in “Android” than AOSP).
Open source is also quite meaningless in terms of privacy, unless you can verify that the running binary is build from the visible source.
Thats where reproducible vuilds come in - I would not be surprised if reproducible builds became a legally enforced default in security sensitive contexts after all the high level cases of outside attackers slipping mallware into blobs built by enterprise vendors.
Reproducible builds are pretty standard in Debian.
Only if your definition of "security" ignores privacy, freedom from surveillance and bugdoors.
That's complete bullshit propaganda and you know it. Remember how the govt simply pushed Covid surveillance apps to Android users without their consent? Yeah, try that on a bare Linux phone.
The article makes plenty of completely arbitrary statements and ignores entire categories of attacks.
Which govt?
I would be interested to see a more comprehensive article.
Pure OS, and the Librem phone get a lot of coverage but they aren't the totality of Linux phones.
As I understand it Ubuntu Touch, which is the most mature Linux phone OS, does have app sandboxing.
This blog post might be a little out of date but is hopefully useful; https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-sa...
Pure OS, and the Librem phone get a lot of coverage but they aren't the totality of Linux phones.
As I understand it Ubuntu Touch, which is the most mature Linux phone OS, does have app sandboxing.
This blog post might be a little out of date but is hopefully useful; https://ubports.com/blog/ubports-news-1/post/ubuntu-touch-sa...
I'm considering a Cosmo communicator with Sailfish OS.
Sailfish already uses selinux and there is work in progress for firejail (sailjail). Sailjail is already enabled for system apps, but not for third party apps. Also, the Android App Support is running under LXC.
Thanks for the information, is there an page with an overview of the SailfishOS security concept and progress somewhere (other than reading the changelogs)?
I found this:
https://sailfishos.org/wiki/Security
https://forum.sailfishos.org/t/privacy-and-security-of-sailf...
But personally I don't think sandboxing is the the one and only ideal solution - already I can introspect the environment on my Sailfish OS device much better than an Android device with hundreds of opaque proprietary services running in background doing something.
Also basically all the third part native apps are open source & developed by long term trusted community members.
So I personally trust Sailfish OS devices much more to be secure and private just as a result of these things.
https://sailfishos.org/wiki/Security
https://forum.sailfishos.org/t/privacy-and-security-of-sailf...
But personally I don't think sandboxing is the the one and only ideal solution - already I can introspect the environment on my Sailfish OS device much better than an Android device with hundreds of opaque proprietary services running in background doing something.
Also basically all the third part native apps are open source & developed by long term trusted community members.
So I personally trust Sailfish OS devices much more to be secure and private just as a result of these things.
Security is only one of many factors people consider when purchasing a phone.
That said, the author isn't very convincing when he mentions trivial stuff like verified boot. My takeaway is that Linux (or PureOS) has some issues but Android still has more closed source.
That said, the author isn't very convincing when he mentions trivial stuff like verified boot. My takeaway is that Linux (or PureOS) has some issues but Android still has more closed source.
What a crap. Secure boot is a straw man for "locked down" phone. In this view it is insecure to be free to use any software you like. And this article on a hacker site. BS.
>In this view it is insecure to be free to use any software you like.
How is this "BS"? If you can replace the software to whatever you like, so can the baddies. Readers of a "hacker site" (you do realize the "hacker" in hn refers to hackathons rather than bad guys breaking into servers?) might accept this trade-off, but it still means it's less secure
How is this "BS"? If you can replace the software to whatever you like, so can the baddies. Readers of a "hacker site" (you do realize the "hacker" in hn refers to hackathons rather than bad guys breaking into servers?) might accept this trade-off, but it still means it's less secure
> How is this "BS"? If you can replace the software to whatever you like, so can the baddies.
And how are we confident that the ROM preinstalled is itself secure? Nobody can assert that and the owner is even prevented to check it.
The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs, all behind the so-called trusted boot.
And how are we confident that the ROM preinstalled is itself secure? Nobody can assert that and the owner is even prevented to check it.
The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs, all behind the so-called trusted boot.
>And how are we confident that the ROM preinstalled is itself secure?
And what about your linux phone's rom? Do they have reproducible builds yet? Sure, it might be open source, but did anyone audit the millions of line of code to make sure it's actually backdoor/bug free? Moreover, HN readers might actually understand this stuff, but what about non-technical people? They're probably better off using a locked down phone with OEM ROM (you already have to trust the OEM) than with a locked down phone that can possibly be replaced with malicious firmware.
>The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs
source?
And what about your linux phone's rom? Do they have reproducible builds yet? Sure, it might be open source, but did anyone audit the millions of line of code to make sure it's actually backdoor/bug free? Moreover, HN readers might actually understand this stuff, but what about non-technical people? They're probably better off using a locked down phone with OEM ROM (you already have to trust the OEM) than with a locked down phone that can possibly be replaced with malicious firmware.
>The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs
source?
> And what about your linux phone's rom? Do they have reproducible builds yet?
Actually, yes.
> Sure, it might be open source, but did anyone audit the millions of line of code to make sure it's actually backdoor/bug free?
Yes, that's what Linux distribution, large companies and independent researchers do. I reviewed an amount of code myself. Also wrote sandboxes.
Actually, yes.
> Sure, it might be open source, but did anyone audit the millions of line of code to make sure it's actually backdoor/bug free?
Yes, that's what Linux distribution, large companies and independent researchers do. I reviewed an amount of code myself. Also wrote sandboxes.
I'm not even talking about reproducible builds, pre-installed phone ROMs are one step below that, there's no "builds". You just have no idea at all what's in it, there's not even a simple list available of what's in it...
Here's a reminder that there's not a single android phone on the planet which runs AOSP.
> They're probably better off using a locked down phone with OEM ROM (you already have to trust the OEM) than with a locked down phone that can possibly be replaced with malicious firmware.
I don't think so, unless OEM are going to increase their standards, a thirdparty ROM will always be better since they can be reviewed and have at least a list of what's in there. That's a very low bar indeed but preinstalled ROMs have such low standards, that makes it better.
> source?
Which source? They aren't publishing any. Those services blobs have full permission to do whatever they want. They update in the background, can escape the sandbox, send device data home...
Here's a reminder that there's not a single android phone on the planet which runs AOSP.
> They're probably better off using a locked down phone with OEM ROM (you already have to trust the OEM) than with a locked down phone that can possibly be replaced with malicious firmware.
I don't think so, unless OEM are going to increase their standards, a thirdparty ROM will always be better since they can be reviewed and have at least a list of what's in there. That's a very low bar indeed but preinstalled ROMs have such low standards, that makes it better.
> source?
Which source? They aren't publishing any. Those services blobs have full permission to do whatever they want. They update in the background, can escape the sandbox, send device data home...
>You just have no idea at all what's in it, there's not even a simple list available of what's in it...
What can you meaningfully do with this information?
>Here's a reminder that there's not a single android phone on the planet which runs AOSP.
Again, for the people who don't care about running a full FOSS stack, why does it matter?
>a thirdparty ROM will always be better since they can be reviewed
You mean how on lineageos, most devices have a grand total of two maintainers?
>That's a very low bar indeed but preinstalled ROMs have such low standards, that makes it better.
motorola and google puts out mostly vanilla android on their phones.
>>>The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs
>> source?
>Which source?
You're being obtuse here. "source?" in this context obviously refers to me asking you for evidence for your claim you made.
What can you meaningfully do with this information?
>Here's a reminder that there's not a single android phone on the planet which runs AOSP.
Again, for the people who don't care about running a full FOSS stack, why does it matter?
>a thirdparty ROM will always be better since they can be reviewed
You mean how on lineageos, most devices have a grand total of two maintainers?
>That's a very low bar indeed but preinstalled ROMs have such low standards, that makes it better.
motorola and google puts out mostly vanilla android on their phones.
>>>The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs
>> source?
>Which source?
You're being obtuse here. "source?" in this context obviously refers to me asking you for evidence for your claim you made.
> What can you meaningfully do with this information?
Check the security of my device and my data? It would help build a trust with my device. Until that happens, phones are at best toys and not real computers you can trust.
> Again, for the people who don't care about running a full FOSS stack, why does it matter?
It's not about FOSS but basic freedom & security here.
> You mean how on lineageos, most devices have a grand total of two maintainers?
As opposed to preinstalled roms which have exactly zero external people reviewing them. Yes, the standards are THAT low.
> motorola and google puts out mostly vanilla android on their phones.
No they don't. Some people are trying to replicate the ROMs for other phones (like https://download.pixelexperience.org/ ) but that's some community effort. There's nothing vanilla about motorola or google phones.
> You're being obtuse here. "source?" in this context obviously refers to me asking you for evidence for your claim you made.
Why though? Even Android admits it, just go into Settings > Security and Settings > Account and look the amount of stuff that they say runs in the background. That's only what they want to admit though, who really knows what it's doing.
Check the security of my device and my data? It would help build a trust with my device. Until that happens, phones are at best toys and not real computers you can trust.
> Again, for the people who don't care about running a full FOSS stack, why does it matter?
It's not about FOSS but basic freedom & security here.
> You mean how on lineageos, most devices have a grand total of two maintainers?
As opposed to preinstalled roms which have exactly zero external people reviewing them. Yes, the standards are THAT low.
> motorola and google puts out mostly vanilla android on their phones.
No they don't. Some people are trying to replicate the ROMs for other phones (like https://download.pixelexperience.org/ ) but that's some community effort. There's nothing vanilla about motorola or google phones.
> You're being obtuse here. "source?" in this context obviously refers to me asking you for evidence for your claim you made.
Why though? Even Android admits it, just go into Settings > Security and Settings > Account and look the amount of stuff that they say runs in the background. That's only what they want to admit though, who really knows what it's doing.
>Check the security of my device and my data?
A phone operating system probably uses hundreds of libraries/codebases. Are you seriously keeping tabs on all of them?
>It's not about FOSS but basic freedom & security here.
Sounds like you're more objecting to the "FOSS" label than the general attitude of "the entire software/hardware stack has to be open source".
>As opposed to preinstalled roms which have exactly zero external people reviewing them. Yes, the standards are THAT low.
exactly zero? https://twitter.com/topjohnwu/status/1234547148785475585?lan...
>No they don't. Some people are trying to replicate the ROMs for other phones (like https://download.pixelexperience.org/ ) but that's some community effort. There's nothing vanilla about motorola or google phones.
1. I said "mostly" vanilla
2. what's your definition of vanilla? If google makes android, then arguably whatever they puts out can be considered vanilla, even if it isn't part of AOSP. Of all the chromium based browsers out there, I'd still consider google chrome "mostly vanilla", even if it does has proprietary bits that aren't part of the chromium project.
>Why though?
Because you're making the claim.
>Even Android admits it, just go into Settings > Security and Settings > Account and look the amount of stuff that they say runs in the background.
"There's a lot of stuff running" =/= "The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs"
A phone operating system probably uses hundreds of libraries/codebases. Are you seriously keeping tabs on all of them?
>It's not about FOSS but basic freedom & security here.
Sounds like you're more objecting to the "FOSS" label than the general attitude of "the entire software/hardware stack has to be open source".
>As opposed to preinstalled roms which have exactly zero external people reviewing them. Yes, the standards are THAT low.
exactly zero? https://twitter.com/topjohnwu/status/1234547148785475585?lan...
>No they don't. Some people are trying to replicate the ROMs for other phones (like https://download.pixelexperience.org/ ) but that's some community effort. There's nothing vanilla about motorola or google phones.
1. I said "mostly" vanilla
2. what's your definition of vanilla? If google makes android, then arguably whatever they puts out can be considered vanilla, even if it isn't part of AOSP. Of all the chromium based browsers out there, I'd still consider google chrome "mostly vanilla", even if it does has proprietary bits that aren't part of the chromium project.
>Why though?
Because you're making the claim.
>Even Android admits it, just go into Settings > Security and Settings > Account and look the amount of stuff that they say runs in the background.
"There's a lot of stuff running" =/= "The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs"
> A phone operating system probably uses hundreds of libraries/codebases. Are you seriously keeping tabs on all of them?
No but I have a right to inspect & modify whatever is running on my device and check it's behavior / replace it if I want to.
> Sounds like you're more objecting to the "FOSS" label than the general attitude of "the entire software/hardware stack has to be open source".
I have no problem with apps being closed source providing that they can use open formats. For operating systems / drivers though, it's kind of essential to have access to the source for security reasons & long term support of devices.
Additionally, openness is even more important to me than open-source and I would still be okay with a closed-source system but very open in mentality, Android currently lacks both.
> exactly zero? https://twitter.com/topjohnwu/status/1234547148785475585?lan...
This guy is from Google and reviewing Android software, that's not an external review and that's not even a rom review itself but a security bug...
> 2. what's your definition of vanilla? If google makes android, then arguably whatever they puts out can be considered vanilla, even if it isn't part of AOSP. Of all the chromium based browsers out there, I'd still consider google chrome "mostly vanilla", even if it does has proprietary bits that aren't part of the chromium project.
Vanilla for me is flashing AOSP straight into the device and booting it. This represents zero device on earth right now.
> "There's a lot of stuff running" =/= "The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs"
Just ask your average user if he knows that all his behaviour & data is recorded and sent to Google on a standard ROM by default and see their reaction.
No but I have a right to inspect & modify whatever is running on my device and check it's behavior / replace it if I want to.
> Sounds like you're more objecting to the "FOSS" label than the general attitude of "the entire software/hardware stack has to be open source".
I have no problem with apps being closed source providing that they can use open formats. For operating systems / drivers though, it's kind of essential to have access to the source for security reasons & long term support of devices.
Additionally, openness is even more important to me than open-source and I would still be okay with a closed-source system but very open in mentality, Android currently lacks both.
> exactly zero? https://twitter.com/topjohnwu/status/1234547148785475585?lan...
This guy is from Google and reviewing Android software, that's not an external review and that's not even a rom review itself but a security bug...
> 2. what's your definition of vanilla? If google makes android, then arguably whatever they puts out can be considered vanilla, even if it isn't part of AOSP. Of all the chromium based browsers out there, I'd still consider google chrome "mostly vanilla", even if it does has proprietary bits that aren't part of the chromium project.
Vanilla for me is flashing AOSP straight into the device and booting it. This represents zero device on earth right now.
> "There's a lot of stuff running" =/= "The most common security threat aren't coming from the trusted boot but play services blobs & manufacturer blobs"
Just ask your average user if he knows that all his behaviour & data is recorded and sent to Google on a standard ROM by default and see their reaction.
> You mean how on lineageos, most devices have a grand total of two maintainers?
So you're saying that there are hundreds of LineageOS maintainers who overlap each other and test a lot of the same things, but have a relatively few number of things only they're responsible for. Additionally, many of the third-party open source libraries have ecosystems of their own that are looking after their libraries source code. That sounds pretty good to me, especially when you consider the transparency that Linux provides.
So you're saying that there are hundreds of LineageOS maintainers who overlap each other and test a lot of the same things, but have a relatively few number of things only they're responsible for. Additionally, many of the third-party open source libraries have ecosystems of their own that are looking after their libraries source code. That sounds pretty good to me, especially when you consider the transparency that Linux provides.
>If you can replace the software to whatever you like, so can the baddies
What are you talking about? A "baddie" can grab my phone, replace my OS, and I won't even notice? How does he know my encryption passphrase to set it back? Or he would insert malicious software into a powered-off encrypted block device?
What are you talking about? A "baddie" can grab my phone, replace my OS, and I won't even notice? How does he know my encryption passphrase to set it back? Or he would insert malicious software into a powered-off encrypted block device?
>What are you talking about? A "baddie" can grab my phone, replace my OS, and I won't even notice?
Is that so hard to believe when you consider that you're unconscious 8 hours a day? Even when you're awake I don't imagine it's too hard to find some time where you're separated from your phone.
>How does he know my encryption passphrase to set it back? Or he would insert malicious software into a powered-off encrypted block device?
He inserts malicious software into the bootloader, which can't be encrypted. See: https://en.wikipedia.org/wiki/Rootkit#Bootkits
Is that so hard to believe when you consider that you're unconscious 8 hours a day? Even when you're awake I don't imagine it's too hard to find some time where you're separated from your phone.
>How does he know my encryption passphrase to set it back? Or he would insert malicious software into a powered-off encrypted block device?
He inserts malicious software into the bootloader, which can't be encrypted. See: https://en.wikipedia.org/wiki/Rootkit#Bootkits
>Is that so hard to believe
Yes. It's virtually impossible with the physical security measures I employ. Also, if someone did that, my phone would either be left off/prompting encryption passphase - which would be incredibly suspicious, or prompting the screen unlock code, which I could safely insert, realize the phone was tampered, re-install my system and use a different screen lock password having given no useful information, even if the attacker was sophisticated enough to emulate my wallpaper.
In the comically-absurd case you still need to protect yourself against that, having a separate device with /boot in a safe location is simple.
Yes. It's virtually impossible with the physical security measures I employ. Also, if someone did that, my phone would either be left off/prompting encryption passphase - which would be incredibly suspicious, or prompting the screen unlock code, which I could safely insert, realize the phone was tampered, re-install my system and use a different screen lock password having given no useful information, even if the attacker was sophisticated enough to emulate my wallpaper.
In the comically-absurd case you still need to protect yourself against that, having a separate device with /boot in a safe location is simple.
>Yes. It's virtually impossible with the physical security measures I employ
Do you live in a bunker or something? I'm interested in knowing what types of security measures you employ that protects your phone when you're unconscious for 8 hours. Moreover, the fact that you can adopt such security measures doesn't mean everyone else can or is willing to, and they'd rather have a technological solution. This is especially true if they're not the type of person to compile and flash their own ROMs.
>Also, if someone did that, my phone would either be left off/prompting encryption passphase - which would be incredibly suspicious,
Phones shut off all the time. It doesn't seem too implausible to fake an excuse, eg.
1. battery ran out
2. the power button was held too long (from being in an awkward position in your pocket?), forcing a reboot
3. flaky software crashing/hanging
> re-install my system
How can you trust the system was actually reinstalled? Do you disassemble your phone and flash the chips with your computer?
>having a separate device with /boot in a safe location is simple.
1. that doesn't actually fix the problem, just moves it around
2. I know of exactly zero phones that can boot off a removable device.
Do you live in a bunker or something? I'm interested in knowing what types of security measures you employ that protects your phone when you're unconscious for 8 hours. Moreover, the fact that you can adopt such security measures doesn't mean everyone else can or is willing to, and they'd rather have a technological solution. This is especially true if they're not the type of person to compile and flash their own ROMs.
>Also, if someone did that, my phone would either be left off/prompting encryption passphase - which would be incredibly suspicious,
Phones shut off all the time. It doesn't seem too implausible to fake an excuse, eg.
1. battery ran out
2. the power button was held too long (from being in an awkward position in your pocket?), forcing a reboot
3. flaky software crashing/hanging
> re-install my system
How can you trust the system was actually reinstalled? Do you disassemble your phone and flash the chips with your computer?
>having a separate device with /boot in a safe location is simple.
1. that doesn't actually fix the problem, just moves it around
2. I know of exactly zero phones that can boot off a removable device.
My bedroom door has shifted and makes a loud noise when opened. Those 8 hours of unconsciousness are very likely to be interrupted when an attacker opens my door (and then proceeds to trip over the stuff on my floor). Oh, he also has to prevent our paranoid house dog from barking while he's picking the lock on the door.
> 2. I know of exactly zero phones that can boot off a removable device.
I know several, including Librem 5 and PinePhone.
I know several, including Librem 5 and PinePhone.
Secure boot doesn't preclude using any software you like.
Apps and Javascript websites are not the only software you could run on hardware.
I think he means that most secureboot implementations (ie. PC, since phones don't adhere to the secureboot standard), you can replace the microsoft keys with your keys.
How generous from Microsoft, that they might allow me to use my hardware. That they didn't build or rent out to me. But that was manufactured somewhere else and sold to me. Maybe next time I ask my plumber if I may decide by myself what kind of toilet paper I use.
Secure boot is a prerequisite for having a walled garden. It was never an answer to the question of how to prevent rootkits from persisting by hooking into the boot process, because that was never a widespread problem. It's an answer to the question of how we can make sure we get 10¢ every time someone sells a $1.50 download of Angry Potato Fiends. Maybe, in some cases, there's a concession where the end user can drill down into some third-tier menu and press up-down-left-right-triangle-square to set the device in "developer mode" so they can run what they like, but that's nowhere near the same as it just being free.
I'm involved in postmarketOS, one of the Linux phone distributions the article talks about. Also a heavy Qubes OS user and previously user of a certain hardened android project on the nexus 5x while strcat was still involved in it.
I think it's quite simple,
* if you are a more casual user with strong security and privacy needs, then the Linux phone distros are not there yet. Use something else.
* if you are a Linux enthusiast/developer/hacker who is interested in getting away from Google and Apple eco systems, consider getting involved in one of these Linux phone projects and helping out there.
This should not be seen as competition, it's all free and open source software. Android hardening projects focus on delivering a reasonable solution today while Linux phone projects focus on getting something truly independent in the long run.
I think it's quite simple,
* if you are a more casual user with strong security and privacy needs, then the Linux phone distros are not there yet. Use something else.
* if you are a Linux enthusiast/developer/hacker who is interested in getting away from Google and Apple eco systems, consider getting involved in one of these Linux phone projects and helping out there.
This should not be seen as competition, it's all free and open source software. Android hardening projects focus on delivering a reasonable solution today while Linux phone projects focus on getting something truly independent in the long run.
When you say:
> the Linux phone distros are not there yet
Is there any indication that Linux is going to catch up to Android/iOS in terms of security?
From my perspective, not only has Linux userspace security barely improved at all over the past few decades (almost all programs run as the user with all of their privileges, no sandboxing, barely any permission/access control to speak of (and yes, I know that there are some projects that aim to fix this, but they're all woefully immature and barely adopted)), but the Unix philosophy itself seems opposed to these security measures. Am I just being overly pessimistic?
> the Linux phone distros are not there yet
Is there any indication that Linux is going to catch up to Android/iOS in terms of security?
From my perspective, not only has Linux userspace security barely improved at all over the past few decades (almost all programs run as the user with all of their privileges, no sandboxing, barely any permission/access control to speak of (and yes, I know that there are some projects that aim to fix this, but they're all woefully immature and barely adopted)), but the Unix philosophy itself seems opposed to these security measures. Am I just being overly pessimistic?
I like to think there are some groups thinking about these problems.
Could using something like Fedora Silverblue or OpenSUSE MicroOS (immutable OSes) plus Flatpak (containerized apps) plus SELinux (access controls) get you almost there?
These already exist, but I've seen the push back to the concepts in real life among admins around me, so I wouldn't expect the mass adoption it'd need to stabilize anytime soon. I'm not even including the Internet rage and arguments about these technologies.
Could using something like Fedora Silverblue or OpenSUSE MicroOS (immutable OSes) plus Flatpak (containerized apps) plus SELinux (access controls) get you almost there?
These already exist, but I've seen the push back to the concepts in real life among admins around me, so I wouldn't expect the mass adoption it'd need to stabilize anytime soon. I'm not even including the Internet rage and arguments about these technologies.
No an immutable OS does not help, also flatpak is necessary and selinux not powerful enough. You just need sandboxing.
> strong security and privacy needs, then the Linux phone distros are not there yet
Citation needed. Android does plenty of homecalling and also a lot of phones came preloaded with bloatware with tracking functions.
You have to provide some justification to claim that a Linux phone protects users privacy less than Android.
Citation needed. Android does plenty of homecalling and also a lot of phones came preloaded with bloatware with tracking functions.
You have to provide some justification to claim that a Linux phone protects users privacy less than Android.
I have no idea how Linux phones are different, but if you compare Android to traditional Linux, app sandboxing is huge difference alone. Is anyone implementing it? How are app specific permissions handled? How full e2ee or secure boot is implemented? By default, you have to add alot in top of Linux kernel.
> app sandboxing is huge difference alone. Is anyone implementing it?
No, sandboxing exists in Linux and tools like firejail are built-in in Debian/Mobian.
> How are app specific permissions handled?
With fine grained security profiles.
Besides, this is all largely irrelevant when the average android TORCH app is a blob of closed source code that can do telemetries.
Contrasted to FOSS applications developed in the open, reviewed by package managers and users, built reproducibly.
> How full e2ee or secure boot is implemented?
It's there and it works. And secure boot is really unimportant for the attack vectors of most phones.
> By default, you have to add alot in top of Linux kernel.
Not at all, it's all supported by seccomp, cgroups and co.
No, sandboxing exists in Linux and tools like firejail are built-in in Debian/Mobian.
> How are app specific permissions handled?
With fine grained security profiles.
Besides, this is all largely irrelevant when the average android TORCH app is a blob of closed source code that can do telemetries.
Contrasted to FOSS applications developed in the open, reviewed by package managers and users, built reproducibly.
> How full e2ee or secure boot is implemented?
It's there and it works. And secure boot is really unimportant for the attack vectors of most phones.
> By default, you have to add alot in top of Linux kernel.
Not at all, it's all supported by seccomp, cgroups and co.
For one, apps in a Linux distro are generally built from source on distro infrastructure, often maintained by a separate person - the distro maintainer - from the original authors of the software. With the source code fully in the open like this, its much harder to slip in user hostile behavior, without anyone noticing and doing something about it.
In comparison on Android or iOS Autors directly upload unauditable binary blobs to an app store that then pushes app updates without almost any user control, often fully automatically. Sandboxing makes more sense in this context as a result.
In comparison on Android or iOS Autors directly upload unauditable binary blobs to an app store that then pushes app updates without almost any user control, often fully automatically. Sandboxing makes more sense in this context as a result.
Unauditable binary blobs will come to Linux phones as well, if they hit the mainstream. It should exists on phones already if the want to say that they are privacy friendly.
There area already many closed source apps such as Spotify client or Slack. Nothing is stopping those apps to read your browser cookies if they want, in case they are installed as regular apps and not sandboxed.
There area already many closed source apps such as Spotify client or Slack. Nothing is stopping those apps to read your browser cookies if they want, in case they are installed as regular apps and not sandboxed.
Android gives each installed app a unique userid and groupid. Do phone Linuxs do that.
The usefulness of this approach depends, I think, on whether the apps are actively working against the user's interests and need to be treated as hostile entities.
Putting "ls" in a sandbox would make it much less useful and doesn't provide much benefit. On the other hand, the .NET Core CLI utilities, which collect telemetry on Microsoft's behalf, would benefit from sandboxing.
Putting "ls" in a sandbox would make it much less useful and doesn't provide much benefit. On the other hand, the .NET Core CLI utilities, which collect telemetry on Microsoft's behalf, would benefit from sandboxing.
User choice could be good
Better: they can sandbox each application.
The article seems to be considering only security against vulnerabilities. It is completely ignoring security against the vendor.
Yeah. Exploit mitigations or access controls can improve security in various circumstances, but they are not synonymous with security, and there are circumstances where such security features are just dead weight. Real security is more complicated than just a checklist of features.
Sure, if you measure security by the amount of buzzwords that were deployed, these phones don't look that great.
In practice, these phones are more secure because nobody will bother to target this vanishingly small installed base - except for a highly targeted attack, in which case Android probably isn't going to protect you any better either.
In practice, these phones are more secure because nobody will bother to target this vanishingly small installed base - except for a highly targeted attack, in which case Android probably isn't going to protect you any better either.
I would be surprised by any other result. Android/iOS phones are used by millions of users and backed by huge companies with the resources and strong motivation to make the phones secure. Of course they are going to have fewer vulnerabilities than a niche open-source OS with far fewer resources behind it.
I have seen this article a few times, and there's enough wrong info in it that it makes me question the rest of its claims:
- The article confuses FireWire and USB in the last paragraph. USB, to my knowledge, doesn't do DMA, while FireWire does. (USB-C can if it has thunderbolt, but Linux phones don't have thunderbolt). The article then references this link for why USB is bad: https://madaidans-insecurities.github.io/linux.html (here's an archived link: https://web.archive.org/web/20210903200926/https://madaidans... )
But a crtl+f "USB" comes out empty.
- While the accelerometer hack is theoretically possible, it's practically infeasible, EVEN if the accelerometer takes measurements above 4 KHz (being extremely generous here, you probably really want close to 8-10 KHz). But you need that high of a sampling rate to overcome Nyquist. Accelerometer are much closer to 100-500 Hz, so Nyquist will tell you that theorically, you can only recover audio data below 250 Hz.
I'm all for discussing security tradeoffs with Linux Phones vs Android vs iOS, but seeing those two issues alone makes me question the other claims that I don't have knowledge about.
Edit: For a paper on using an accelerator as a microphone:
https://crypto.stanford.edu/gyrophone/files/gyromic.pdf
So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.
- The article confuses FireWire and USB in the last paragraph. USB, to my knowledge, doesn't do DMA, while FireWire does. (USB-C can if it has thunderbolt, but Linux phones don't have thunderbolt). The article then references this link for why USB is bad: https://madaidans-insecurities.github.io/linux.html (here's an archived link: https://web.archive.org/web/20210903200926/https://madaidans... )
But a crtl+f "USB" comes out empty.
- While the accelerometer hack is theoretically possible, it's practically infeasible, EVEN if the accelerometer takes measurements above 4 KHz (being extremely generous here, you probably really want close to 8-10 KHz). But you need that high of a sampling rate to overcome Nyquist. Accelerometer are much closer to 100-500 Hz, so Nyquist will tell you that theorically, you can only recover audio data below 250 Hz.
I'm all for discussing security tradeoffs with Linux Phones vs Android vs iOS, but seeing those two issues alone makes me question the other claims that I don't have knowledge about.
Edit: For a paper on using an accelerator as a microphone:
https://crypto.stanford.edu/gyrophone/files/gyromic.pdf
So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.
Following the leads, DOI:10.1145/2742647.2742658 says the accelerometer in Apple iPhone 6, Google Nexus 5 and Samsung Galaxy S5 supports 4kHz sampling. However, the OS limits it to 200Hz to conserve power. Googling around, it appears there are accelerometers with much higher bandwidths.
Here's how 8 bps mono speech at 4kHz sounds like: https://vocaroo.com/102J6NRULedu (download link: http://fpaste.dy.fi/oyU/dl)
Sounds pretty good. At 2kHz it gets a bit hard to listen to but I can still understand a fair proportion of it. I imagine it shouldn't be too hard to come up with an algorithm (or neural net) to resynthesize the higher frequencies and make it easier to understand.
2kHz sample: https://vocaroo.com/18F3LkYrsPNQ (download: http://fpaste.dy.fi/rvy/dl)
(Obviously these are not accelerometer recordings, just normal microphone recordings downsampled with sox)
I agree it's a bit silly complaint though. I see it a lot in security circles: if some feature doesn't give you perfect protection against all possible attacks, it's a problem. At the same time, the same people advocate mitigations and techniques that only apply to certain attacks. It's as if there's no silver bullet, but it's a damn shame if you deploy something that isn't a silver bullet!
Here's how 8 bps mono speech at 4kHz sounds like: https://vocaroo.com/102J6NRULedu (download link: http://fpaste.dy.fi/oyU/dl)
Sounds pretty good. At 2kHz it gets a bit hard to listen to but I can still understand a fair proportion of it. I imagine it shouldn't be too hard to come up with an algorithm (or neural net) to resynthesize the higher frequencies and make it easier to understand.
2kHz sample: https://vocaroo.com/18F3LkYrsPNQ (download: http://fpaste.dy.fi/rvy/dl)
(Obviously these are not accelerometer recordings, just normal microphone recordings downsampled with sox)
I agree it's a bit silly complaint though. I see it a lot in security circles: if some feature doesn't give you perfect protection against all possible attacks, it's a problem. At the same time, the same people advocate mitigations and techniques that only apply to certain attacks. It's as if there's no silver bullet, but it's a damn shame if you deploy something that isn't a silver bullet!
https://crypto.stanford.edu/gyrophone/files/gyromic.pdf
So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.
Good to know about the various phones though. I'm honestly not sure why such a high sample rate is even needed/wanted (though in the paper, it is mentioned that there are ones with much lower sampling rates, so if this is a real concern, populate you device with a chip with a lower sampling rate).
So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.
Good to know about the various phones though. I'm honestly not sure why such a high sample rate is even needed/wanted (though in the paper, it is mentioned that there are ones with much lower sampling rates, so if this is a real concern, populate you device with a chip with a lower sampling rate).
The higher the sample rate the more fine grained movement it can detect, and, with decimation, the better the signal to noise ratio. MEMS stuff is really noisy because they're mechanical stuff is wobbly enough and the ADCs are pretty sensitive since the mechanical stuff is so small.
Heh, that's good to know, thanks! So how find grained can it detect like that? I would think with a phone, you are only looking for large movements (phone being g picked up, in an automobile, etc.)
Sorry for the late reply: Accelerometers[0] are usually rated by the peak acceleration per second they can measure, say 8g/s.
Gyroscopes apparently are now rated at degrees per second, so, 4000 degrees/s for example.
The higher those numbers, the more time the ADC has to sample, be that on the sensor itself (digital output, say SPI, 1-wire, or serial) or an intermediary (arduino, ADC board with digital output) if the sensor is analog. The sensors in even mid-range cellphones is probably enough to determine what road you're driving on and how fast, judging by viewing the graph output form something like Torque Lite or some other sensor display app.
I had some $12 9 degree of freedom sensor, gyroscope, accelerometer, compass (or something), and when displaying the combined gyro and accelerometer as a line on a graph you could watch me leave the room (footsteps, doors) walk all the way across the house, and turn off a loud radio. The sensor was on a desk.
[0] https://www.adafruit.com/category/682
P.S. the Bosch sensors are crazy. expensive, but if you can find a SoC board with a bosch (BNO is the part prefix) sensor for like $50, get it. Atomic Pi is one board that has a Bosch on, and it's barely over $35 itself!
Gyroscopes apparently are now rated at degrees per second, so, 4000 degrees/s for example.
The higher those numbers, the more time the ADC has to sample, be that on the sensor itself (digital output, say SPI, 1-wire, or serial) or an intermediary (arduino, ADC board with digital output) if the sensor is analog. The sensors in even mid-range cellphones is probably enough to determine what road you're driving on and how fast, judging by viewing the graph output form something like Torque Lite or some other sensor display app.
I had some $12 9 degree of freedom sensor, gyroscope, accelerometer, compass (or something), and when displaying the combined gyro and accelerometer as a line on a graph you could watch me leave the room (footsteps, doors) walk all the way across the house, and turn off a loud radio. The sensor was on a desk.
[0] https://www.adafruit.com/category/682
P.S. the Bosch sensors are crazy. expensive, but if you can find a SoC board with a bosch (BNO is the part prefix) sensor for like $50, get it. Atomic Pi is one board that has a Bosch on, and it's barely over $35 itself!
> The article confuses FireWire and USB in the last paragraph.
I believe he's not; the paragraph about USB and the one about FireWire are separate ones. And his point that kernel isolation of the modem is flawed because of properties of the Linux kernel seem accurate, though I don't have the expertise to confirm that (you'd need to ctrl+f "kernel", not "USB", since the point is a general one)
I believe he's not; the paragraph about USB and the one about FireWire are separate ones. And his point that kernel isolation of the modem is flawed because of properties of the Linux kernel seem accurate, though I don't have the expertise to confirm that (you'd need to ctrl+f "kernel", not "USB", since the point is a general one)
So why bring in FireWire at all to the argument? Why not give USB examples? Giving the benefit of the doubt, the writing is extremely unclear and, to me, gives the impression of a comparison between the two.
Same with referring to the other article, there's a general link to another article, where the reader is left guessing where they are making the point. To me, if you reference an article in this manner:
"Linux kernel USB stack which is not a strong barrier as shown in the Linux article"
I would expect the linked article to reference....well the USB stack, or USB in general. Or reference what section you mean, or quote it and bring it in to the article.
Same with referring to the other article, there's a general link to another article, where the reader is left guessing where they are making the point. To me, if you reference an article in this manner:
"Linux kernel USB stack which is not a strong barrier as shown in the Linux article"
I would expect the linked article to reference....well the USB stack, or USB in general. Or reference what section you mean, or quote it and bring it in to the article.
This is spectacularly bad.
Author rails against separating the modem, claiming iommu is sufficient (yeah, google qualcomm iommu cve, you'll find plenty of fun to be had). Then goes on claiming that chips connected by usb 2.0 (a protocol explicitly used because it doesn't have rdma) might be vulnerable to some rdma attack.... because firewire exists?
They rail against being unable to swap out "the firmware", while failing to mention that "the firmware" in question is nothing more than the ddr4 memory training blob.
Author rails against separating the modem, claiming iommu is sufficient (yeah, google qualcomm iommu cve, you'll find plenty of fun to be had). Then goes on claiming that chips connected by usb 2.0 (a protocol explicitly used because it doesn't have rdma) might be vulnerable to some rdma attack.... because firewire exists?
They rail against being unable to swap out "the firmware", while failing to mention that "the firmware" in question is nothing more than the ddr4 memory training blob.
This is a veiled attack on user freedom itself. The article is based on the idea that software isn't free and doesn't give controls to the user that the user should rightfully have as the device owner.
When it talks about security models and "modern security features", it assumes that the running software utilities aren't trusted.
One interesting point is the firmware being difficult to update. I guess that that could hypothetically become an issue if the firmware were open-sourced or reversed, but still it seems like a reasonable decision once you realize that firmware updates can introduce new bugs/vulnerabilities.
When it talks about security models and "modern security features", it assumes that the running software utilities aren't trusted.
One interesting point is the firmware being difficult to update. I guess that that could hypothetically become an issue if the firmware were open-sourced or reversed, but still it seems like a reasonable decision once you realize that firmware updates can introduce new bugs/vulnerabilities.
> but still it seems like a reasonable decision once you realize that firmware updates can introduce new bugs/vulnerabilities.
As opposed to having only old bugs and vulns…
As opposed to having only old bugs and vulns…
It's not true though, the firmwares aren't difficult or impossible to update on these phones. It's a common myth that's often being repeated just because PureOS does not include non-free firmware updates in its repositories.
If retaining control of my own devices makes me less secure, then I want to be less secure.
The authors suggestion to “install android” as a way to fix the security on these Linux phones obviously misses the point. People want a phone where they can do whatever they want with it.
While most of this article can be argued to be true, they missed a key point of early adoption of linux phones- privacy. They forgot to mention how both Ios/Android are less private than the linux phone. Also, they should have delineated between security, privacy, and anonymity to be clear on what point they were trying to make. Poorly written at best.
The only remotely sane points are about UX and the fact these GNU/Linux systems allow users to do stupid things if they want to.
Running software from your distro's repos? That's safe, I mean, how could you use a system and not trust the people who make it? The only alternative here is writing your own OS (analyzing everything is much harder than that).
Running something else? Firejail is really simple to use. Sometimes flatpak or docker can get you covered (just don't assume it's safe by default). You can always use SELinux if you have to.
You can't prove linux-libre is less safe than a slightly more recent non-libre, and it'd be surprising if that were the case.
Not having kill switches isn't better than having them.
The rest either have been considered acceptable in the safety-paranoid Linux community for years or are absurd. Claiming something like DMA is possible from the isolated modem is a VERY strong claim presented with zero evidence.
Running software from your distro's repos? That's safe, I mean, how could you use a system and not trust the people who make it? The only alternative here is writing your own OS (analyzing everything is much harder than that).
Running something else? Firejail is really simple to use. Sometimes flatpak or docker can get you covered (just don't assume it's safe by default). You can always use SELinux if you have to.
You can't prove linux-libre is less safe than a slightly more recent non-libre, and it'd be surprising if that were the case.
Not having kill switches isn't better than having them.
The rest either have been considered acceptable in the safety-paranoid Linux community for years or are absurd. Claiming something like DMA is possible from the isolated modem is a VERY strong claim presented with zero evidence.
> Running software from your distro's repos?
An important distinction to make: open-source software has a high chance of not being malicious. It doesn’t make them safe, especially with the overwhelming majority of them being C all the way down. A single bug (of which they are not absent at all) can introduce security implications depending on their usecase. Eg a firefox bug can easily make your device running untrusted code without any other remaining defense on your device.
So open-source is orthogonal to security.
An important distinction to make: open-source software has a high chance of not being malicious. It doesn’t make them safe, especially with the overwhelming majority of them being C all the way down. A single bug (of which they are not absent at all) can introduce security implications depending on their usecase. Eg a firefox bug can easily make your device running untrusted code without any other remaining defense on your device.
So open-source is orthogonal to security.
Github repository there is a lot of criticism: https://github.com/madaidans-insecurities/madaidans-insecuri...
I also slightly editorialized the title, since it is extremely non-descriptive of article contents.