There is some truth to that, but that just means you’re lower down the list. To actually be reasonably secure, the goal is to make the estimated cost of attacking exceed the expected return if the attack is successful. Against a wise opponent, it’s expected cost times expected chance of success vs expected return, but you have to figure some people will be bad at cost analysis and may try anyway. Of course, this doesn’t save you when a new lower-cost attack vector shows up, but that’s the reason for defence-in-depth.
1 Like
I think: expected cost vs expected return times expected chance of success
would be closer to the mark.
Took the time to read the full article about the linux phones, linux in general and android. Beside a lot of facts shown, the author on first look appears very biased - the same way i might be biased towards something like the opposite. He’s got a lot of true points and security-knowledge. But what does it help?
It’s beautiful, that android’s a very secure system with an amazing amount of precautions taken. But what does it help, if the base is secure, but all the apples within that bowl are grinning and spying at me?
Since android 6 location service is mandatory if you want to connect via bluetooth tells me app xy. And as soon as i switch on location services, a little sat-icon pops up and my firewall tells me that this app - not having done anything like that the last minutes - wants to call home.
The author disregards the Librem’s switches as pure marketing-gamble. For me those little switches phsychologically give back those little pieces of control over my system to me. Wether someone that infiltrated my system can send his data once i switch the network on again, is a totally different story and requires a lot more brains and thoughts on any system - no matter how well secured by default. But in that particular moment when i switch off the sensors, its MY DECISION to do so - and perhaps to keep it this way once i got suspicious.
Each coin has two different sides and flipping it over might show a different perspective. The technical side is just one and can be improved over time. The other side is psychologically/menthally and it slowly degraded within the last decades. To improve that one again, to bring the user back in control and being counscious about it, some little physical switches can be of great help.
And libre plus open-source - faith - is the foundation. The first step to be taken. Everything on top can be improved over time.
3 Likes
And if the crook is a serial burglar, then your house next to the neighbor, yours is next on the list no matter what. Depends if he’s going by street number or on the same block. If the former he’ll be on the other side of the street next time.
And how come the pinephone has six kill switches instead of Librem’s four? What did Librem forget to kill? (Not that I have either yet, just based on what I read here.)
You could kill cameras individually and separately from the microphone: Would then need three switches instead of one.
You might want to kill Bluetooth separately from WiFi; two switches instead of one.
You could have a separate switch for accelerometers. And so on, there are many small things you just might want to turn off.
The set of three is probably a good compromise, if you want those switches on the outside of the phone. (The Pinephone has them internally, IIRC.)
We had some entertaining discussions about kill switches - and design suggestions - back when there were no official designs. I especially remember this comment 
1 Like
This.
Also, I’m not too convinced that Androids permissions system should be the gold standard. It lacks granularity and misses the temporal aspect of permissions, to my mind.
As an example, suppose there is an Address Book holding contact details for people you know, a Chat app and an Email app.
For it to function, you need to give the Email app access to the Address Book. Unfortunately, that also grants it access to the physical address and Chat ID:s of all your contacts, stuff the Email app has no business reading.
So, ideally, you’d like to slice the Address Book such that an app only gets to see “it’s own data”. (From what I can tell, Sandstorm takes this approach.) Android’s model is wholesale access, so it won’t let you do that. That’s the lacking granularity I’m talking about.
In addition, the way you normally use Chat or Email, you actually want those apps to access the Address Book at well-defined times. I.e. when you compose a message, you add specific contacts to the recipients field. Other than that, the Email app really should not be allowed to browse your Address Book as it wants.
So, ideally, access should be restricted in time, and often there are clear interactions in the UI where this happens - where you implicitly give permission. (Flatpak portals use this pattern to avoid annoying permission popups.) Android’s model won’t let you do that either.
These two deficiencies lead to apps having to request, and being granted, much wider permissions than necessary. And in order to avoid an explosion of permission settings (if I have understood right), Android bundles permissions so one thing also implies another.
Maybe I should call that a “ridiculously insecure” security model.
4 Likes
I think you make a good point. But I think it could also be argued that the issue isn’t the security model in Android, but rather the fact that you can’t trust your apps because Google encourages personal information mining and pays handsomely for it. You ever wonder how so many apps can be free?
Instead, Android security model and lack of granularity would be fine, if you knew that what your apps were looking at and what they need it for. Under this scheme the base security and hardening becomes the important aspect of the security.
Google views themselves as this trustworthy steward and so from their perspective they are doing it right.
Imagine if Google actually followed their mantra today: Do no evil.
4 Likes
Or remove bathroom’s door to let say anybody, strangers, or Facebook groupies, swarming into like flies while you’re defecating. Even normal sensible people would find it icky if they found camera and scent sensors sitting at bottom of toilet bowl. Indeed, if you have nothing to hide then don’t flush away your used toilet papers.
2 Likes
Oops! You’re right, the estimated return is multiplied by the expected chance of that return, not the expected cost.
1 Like
We limited the Librem 5 to three physical kill switches primarily for usability reasons. Once you get past three kill switches it starts being more and more difficult to keep track of which switch does which thing (as well as making it easier to trigger switches, without looking, in your pocket, if you want).
We also put the switches on the outside of the case for usability reasons. I find I use my kill switches rather often (for instance, I frequently shut off WiFi/BT when I leave the house, since I know I won’t be associating with WiFi access points on my errands). If I had to remove the case each time, I don’t think I’d use the switches nearly as often and I wouldn’t use the camera/mic kill switch at all because often you want to turn on both of those devices quickly (to take a picture of a fleeting moment, or answer a phone call).
If you want fine-grained control then I typically recommend a combination of hardware kill switches and software switches for the remaining hardware. So for instance, if you want to disable WiFi but still want to use your Bluetooth headset, I’d recommend disabling WiFi in software via the Settings app. The same goes for disabling the camera but still wanting the microphone to be enabled, or vice-versa. Kill switches are a great circuit breaker, but sometimes you only need a light switch. Because the OS itself is more trustworthy (and auditable), there are more circumstances where you might feel safe enough relying upon the software switches because you can confirm that off really means off instead of meaning “off for this app, but on for others”.
Because there are additional sensors that people in specific circumstances may want to power off beyond the three hardware kill switches, instead of relying only on software to disable them our compromise was to implement what we call “Lockdown Mode” on the Librem 5 where triggering all three kill switches also disables the remaining sensors on the system (proximity, accelerometer, GPS, ambient light, etc.).
8 Likes
Oh, I thought I saw a video with four kill switches. Must have been an earlier model.
(Or am I going Winston Smith on you, with how many fingers did you hold up?)
While your point is well taken
- some email programs also display email addresses in emails differently depending on whether the email address is in your address book (e.g. highlight suspicious emails from “randoms” and e.g. replace email address with recipient name)
- some email programs use the address book as part of anti-spam e.g. flag email as probable spam and/or move automatically to spam folder, with the heuristics / AI / logic depending on, in part, whether the sender is in your address book
The bottom line: Android / spiPhone blackbox model: if you don’t like it, tough luck for you.
After reading your most informative post, I started to think that perhaps this article we are responding to is written by a troll, a rather clever troll, but it looks like trolling behavior to me now that I reflect on it.
But if so, I too was taken in by it at first. Thanks.
1 Like
The PinePhone may have more DIP switches, but they don’t provide a way to cut the circuit to the accelerometer, magnetometer, gyroscope, ambient light and proximity sensor, whereas Lockdown Mode in the Librem 5 does cut the circuit to all those sensors.
Also the DIP switch for the microphone actually changes it from being an analog mic to using the 3.5mm audio jack as UART serial port , which I guess does stop the microphone, but I wonder about the security implications.
It is a lot more convenient to flip one switch on the side of the Librem 5’s case to cut the power to the 2 cameras and the microphone than to take off the back cover and then move 3 separate DIP switches in the PinePhone.
I would have liked to have a fourth switch on the Librem 5 for the GNSS and sensors, since I often want to keep the cellular modem or WiFi on, but the GNSS off. However, I will be satisfied as long as there is an easy way to turn on/off the GNSS in the software.
I noticed how much space the switches take up on the PCB and how the M.2 card for the WiFi/Bluetooth is placed on top of the switches, so I assume that was also a reason to avoid having more switches.
1 Like
Unlike most people in this thread, I actually find that the article raises many legitimate points.
As a security engineer myself, I’ve always found it fairly obvious that the Librem 5 compromised on security in the name of freedom. This isn’t necessarily a bad thing, it’s just how the phone is. Purism also does not have the 100k+ employees like Apple and Google, which enables them to hire hundreds of full-time security engineers to tackle issues like this. Really, this is to be expected.
That said, I am also kind of appalled by this community’s attacks on the author and not the actual content of the article. Calling people trolls, shills, etc is not acceptable, especially not when these people have done much more for security than yourself (the author in question has contributed code to Qubes, IIRC), and when you haven’t actually engaged the points mentioned.
The author’s minor, inconsequential inaccuracies about have been overblown in this thread, the actual security meat of the discussion (outlined below) passed over by people rushing to point out how the author mustn’t know anything.
In the end, either you address the concrete security issues raised in the article, or you don’t. I have neither seen an acknowledgement or refutation of the fact that the Librem 5
- Doesn’t have a robust secure boot chain
- Doesn’t have a hardware-backed keystore
- Seems to be missing many of the OS hardening features added over the years in https://source.android.com/security/enhancements
- Won’t let you update firmware, which is a security nightmare if (when) a vulnerability is discovered in the firmware
All of these are fairly critical and I haven’t seen a point-by-point refutation of all of these.
If you believe the issues exist, what is the plan to fix them going forwards? If there is no plan to fix them, why? (@Kyle_Rankin)
If you do not believe the issues exist, why?
Will I still buy a Librem 5? Sure. But I think shortcomings must be acknowledged, and mass denial will not help you in the real world where people can and will exploit the shortcomings you’ve chosen to ignore.
4 Likes
I can respect your opinion on the matter, but anyone who wishes to be seen as unbiased and only wishing to share information can’t be so obvious in their bias. I mean just look at the clickbait title of the article. Regarding your own questioning, you base everything on what Android already provides. A piece of software that has been existent for near decades, and has a massive team across many software and hardware companies. Compare Android 1 with 11 and you’ll see that your line of questioning is in many ways unfair, and in others naive.
People who are somehow blown away that a small team of people doesn’t have a rock solid perfect device when gigantic companies with nearly unlimited R&D budgets don’t can’t be helped.
Purism’s work wasn’t just to create a secure and private phone, they had to start from literal scratch. They are taking mainline Linux mobile. They are working to get the hardware and software working well together now, as they should! A super secure phone that does nothing is pointless.
Articles like what this thread is about are similar to someone accosting an individual who has just started going to gym, who can barely do a push up, and then demanding that they explain why they can’t already bench press a house.
1 Like
Did you read the reddit thread where I pointed out madaidan’s inaccuracies?
Madaidan pointed to DMA security issues, but the Librem 5 uses serial buses that don’t allow DMA. When I pointed this out, madaidan said that it was just an example, but he couldn’t point to an example that was pertinent to the Librem 5 to prove his point.
Madaidan argued that USB in Linux is insecure. When I questioned him about it because his link didn’t prove that point, his only argument was that the Linux kernel is written in a memory insecure language, but Android is also using a Linux kernel written in a memory insecure language. Maybe Android does something different with USB that makes it more secure than standard Linux (I don’t know), but madaidan didn’t bother trying to prove his point.
Madaidan didn’t know that Purism plans to implement software kill switches in addition to hardware kill switches and it will be possible to turn off the GNSS while using the WiFi or cellular modem.
Madaidan argues that apps will be insecure in the Librem 5, but when I pointed out that flatpack will use bubblewrap, he simply responded that flatpack didn’t implement bubblewrap well and didn’t provide any information to prove why flatpack+bubblewrap would be insecure.
The biggest inaccuracy of madaidan’s article was that he leaves the reader with the impression that a person buying an Android phone is going to safer than a person buying a Linux phone. It is fine to point out the security features in the Android kernel, but he and Micay had no real response to my post:
what do you think about the amount of malware found by AV-Test in Android vs Linux?
AV-Test reports the following breakdown of the malware that it found in the first half of 2016:
Windows 67.21%
Script: 19.10%
Android: 7.48%
MacOS: 0.07%
Mobile: 0.01%
DOS: 0.01%
Linux: 0.02%
Other: 6.10%
Unfortunately, this was the last time that AV-Test reported the amount of Linux malware, so we don’t have a more up-to-date comparison.AV-Test reports that the amount of new Android malware discovered each year has diminished, but it is still very high:
2014: 1.02 M
2015: 2.57 M
2016: 6.13 M
2017: 6.20 M
2018: 5.54 M
2019: 3.17 MYou and u/madaidan have pointed to a number of ways that Android is better designed for security then Linux. However, I look at these numbers from AV-Test and I have to ask if I want to run an ecosystem on my phone, where 3.17 million new pieces of malware and 1.69 million new potentially unwanted applications were found in 2019.
Even if I only install apps found in the Google Play Store, this study found that many of the apps in the Play Store are counterfeits which contain malware or ask for more permissions than are needed.
On my mobile devices, I install LineageOS and only install apps that I find in the F-Droid repo, so I know that I can avoid a lot of the garbage out there, but those are not the sorts of measures that the average user knows how to do.
Maybe this difference is simply because Linux only has about 20 million desktop users worldwide, so it isn’t a very interesting target for the developers of malware. However, I think that there are a number of factors that will help keep malware out of mobile Linux as it grows. Users of mobile Linux are likely to use repos like the PureOS Store that only accept FOSS apps and inform them about data collection (e.g., badges for privacy), which are likely to deter most bad actors.
People will flock to mobile Linux precisely because they are trying to avoid the surveillance Capitalism of Google and lack of transparency at Apple, so there will be efforts to exclude apps that violate privacy or hide their code. Because there will be less opportunity to monetize user data, display advertising, etc, there will be fewer apps that are created and fewer that need review for security flaws. With free software apps, people are more likely to join the developers of an existing app or fork an exiting code base that has already been well scrutinized for security, rather than create a bunch of buggy apps from scratch, as happens in Android and iOS.
Kyle Rankin has said that Purism is looking into implementing the Librem Key for tamper-evident booting on the Librem 5. (I personally would prefer this be implemented with hashes of the boot files and keys stored on the OpenPGP card.)
Kyle Rankin’s article on the OpenPGP smartcard in the Librem 5 seems to indicate that it will be used as a keystore. I would like to see something more detailed, but Purism does appear to be thinking about this issue.
This was madaidan’s strongest argument. However, there is no way that Purism alone can implement kernel hardening, and this will take a concerted effort involving many people at the Linux kernel and in the different Linux distros to implement these security features. Google, an organization with virtually unlimited resources, has spent years working on it. It is unrealistic to demand that Purism do this, with its tiny team of 8 programmers working on the Librem 5.
Kyle Rankin has indicated that Purism intends to provide firmware updates for the Librem 5. This is another thing that Madaidan got wrong, because he didn’t bother to look at Purism’s documentation and see the instructions on flashing the firmware for the RS9116 WiFi/Bluetooth.
It is worth pointing out that the Librem 5 has a much higher probability of getting firmware updates than most Android phones, because the standard mobile phone SoC (Snapdragon, Exynos, Helios, Tiger/SCXXXX, Kirin or Surge) only gets produced for 1 - 2 years and only gets firmware and driver updates for 2.5 - 3.5 years. In contrast, the i.MX 8M Quad is guaranteed to be manufactured till Jan 2028 and receive updates from NXP for the next decade. Most of the other components in the Librem 5 have long production lifecycles, so they are also more likely to get future firmware updates. Because the drivers are all FOSS, they can be maintained and updated by the community and NXP and Redpine Signals help maintain the mainline Linux drivers for their devices. Unlike Android phones, the Librem 5 will be using a recent mainline Linux kernel, so it will keep getting security updates in the kernel.
We can ask for more concrete plans from Purism on some of these points, but it is clear that Purism has to get the phone out the door, so Purism has to focus on making a working phone first. Things like power management and cameras have to take priority over new security features right now.
13 Likes
I’m by no means an security engineer myself but i’d like to take your points and explain how I see them.
At the moment PureOS on the Librem 5 does not have a secure BootChain but will get one like PureBoot on the other Librem devices in the future.
The imx8 Processor chosen in the Librem 5 is capable on secure boot based on keys that can be stored in the OTP EEPROM range of the processor.
But by writing their Key into the OTP they would take away from the freedom of the user since then they would have to trust that the Purism key will never get compromised and would never be able to run their own OS on the Librem 5 or need to have their bootloaders signed by Purism.
Like it’s done in almost every Android Smartphone.
I plan on enabling secure boot on my Librem 5 after reading all the documentation with my key.
Which brings me to the next point AFAIK not all of the documentation on the secure-boot implementation of the imx8 is available without an NDA. So I’m not sure if Purism could open source their implementation.
it’s got no integrated hardware-backed keystore but you get something much more valuable at least in my opinion. You can install an open Smart Card into the Librem 5 so you can have multiple hardware-backed keystores, which then also are controlled by you and not by Google or the hardware vendor of your Smartphone there is no public or private key within the Smartphone not under your control.
Not sure about this point my main complaint in this case about the Android ecosystem is that most of those security updates don’t reach Smartphones that are more than 2 years old.
And if I want in can still apply most of the Linux hardening guidelines for Debian found on the net to the OS running on the Librem 5 and have a very secure OS.
But since most of those features complicate the usage of the device for a normal user I think the decision to not do so it the better choice.
This point is not completely true at lest from my perspective you might need some flashing tool to do so but you can.
For the WLAN/Bluetooth and modem firmware I’m not sure what kind of vulnerability would cause an security Problem for the Phone since they are just USB devices with no access to any internal information and the data moved thru them is already encrypted before entering them.
Where as a security vulnerability within an Android Smartphone out of update support will never by patched an open the whole Phone due to the integrated nature of the device, with the modem for example having bus access to the whole system and being able to extract data without the OS having any chance to detect it.
Lets say even if that would be the case that the WWAN modem and the WLAN device are completely compromised. I would still be able to shut them of via the kill switches and replace them at a later date.
Where as on an typical Android Smartphone I have to trust the OS that those device are of if I click that software switch with no way to prove it, since they could fake even that state to the OS.
Hell I could even pull them out if you don’t trust the kill switches.
except for the DDR RAM training Code all the other firmware code for the access to battery cameras and so on is open source and can be updated as easy as a package of the OS.
Well this has become longer than initialy anticipated and @amosbatto was faster writing his argument but I’d still like to ad my thoughts to the discussion.
[EDIT] fixed some typos
5 Likes
I am someone who has shared the article in question on Reddit. First I would like to clear up when I share this article I only do so in order to list a pro and con. This shouldn’t be an end all be all. I for one agree with(and have complained about) Linux security issues such as mentioned in his Linux article. Yet I still use Linux(at least part of the time). No device will be perfect in every regard and the Librem 5 certainly is anything but perfect for anti exploitation. In the same way an Android won’t ever be as good as an iPhone for taking video. Doesn’t mean Android’s are useless junk(I say that as an Android user that they certainly aren’t).
I would like to note something no one seems to have noticed. https://github.com/madaidans-insecurities/madaidans-insecurities.github.io/issues There is a github page where you can raise issues. It might be worth checking out.
It is also worth noting anti exploitation is not something in user control. Malware you can learn to beat by being careful, but if someone throws enough money at you they will hack you. Frankly, Linux and Linux based systems are the cheapest(of supported systems) to do this on. It is good to know, but it shouldn’t be the only factor you consider when choosing a device. It is just one factor. This is as good of a source for anti exploitation as say a camera comparison. Both are helpful, but certainly shouldn’t be the only factor to consider.
I think everyone is blowing this way out of proportion. Librem anti exploitation isn’t great compared to Android and especially iOS. Though, there is much more to buying a phone(and even privacy) than one factor. madaidan’s source is helpful in context as much as a camera comparison would be.
3 Likes