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.).
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.
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.
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
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.
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.
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 M
You 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.
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.
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
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).
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.
How does a normal person protect herself from malware in Android? The Google Play Store is filled with it and that is the approved source of supposedly safe software for Android users. Just two days ago, my friend came to me asking me for help because full screen ads were popping up on his Galaxy every couple minutes, and he only installed software from the Play Store. After uninstalled every program that it was possible to uninstall, the problem remained, so this was some program that was deliberately hiding from the user.
In 21 years of using Linux on the desktop and on my servers, I have never encountered a virus or any other type of malware. It is far easier to find tools on the internet to hack Android and Windows than tools to hack Linux, so I’m not sure why you would conclude that it cheaper to hack Linux.
It strikes me as extremely irresponsible for a guy like madaidan to post a poorly sourced article with inaccuracies on the internet that can cause a company to lose thousands of dollars in orders. When it was pointed out that Purism intends to provide firmware updates, madaidan did not change the text of his article to reflect that fact. When it was pointed out that his DMA example wasn’t relevant to the Librem 5, madaidan didn’t change his article to reflect that either. When it was pointed out that he wasn’t providing evidence that USB in Linux is less secure than in Android, he didn’t update his article to link to evidence or remove the argument. When it was pointed out that apps in the Librem 5 will use bubblewrap, he should have updated his article to acknowledge that and then try to explain why flatpack+bubblewrap is less secure than Android’s approach to app security.
The fact that madaidan did none of these things tells me that he is irresponsible and untrustworthy. He’s right that Android has some secure boot features and kernel hardening that PureOS/Phosh lacks, but the fact that he doesn’t even bother to mention the OpenPGP card and acknowledge that we don’t yet know what features it will implement tells me that he is not an honest actor.
I haven’t had a Google Account since pre-Snowden era. F-Droid for me works great or using something like Aurora Store(successor to Yalp Store). This tells me what known tracking/ad companies have code in the app. It even tells me if the app has ads at all. Running Google Play on AOSP is like running Wine on Ubuntu. Yes, you can do it(and some version ship with it), but do you want to? Wine malware can do just as much damage on Ubuntu as it can on Windows. Even if you get malware on Android it is not going to be able to keylog or spy on your without your express permission(for example the almost never used Accessibility Services gives an app more rights than the user).
I hear this argument. Though low marketshare is not a feature Linux actively seeks out and promotes. It is not a maintained security feature by any stretch of the imagination. I have never gotten malware on Windows and I used Windows since 95. Windows 10 has CFG, a meaningful implementation of ASLR much much sooner, it can force important hardening features like CFG, ACG, SimExec, CallerCheck, SEHOP, StackPivot even in userland. It has a minimal kernel. Windows 10 UWP apps are fully sandboxed. Hell Windows runs the OS as a guest of Hyper-V much like how Qubes works in most cases. You check the black market and Windows by far is the biggest prize.
Hyper-V has also made massive strides. Even 10 years ago they started work on the formal verification getting to ~20%. Public escapes on Hyper-V you really can’t find. One was found my MS internally and the other was not attacking Hyper-V, but attacking RDP. When you have things like Windows Sandbox and WDAG making the best security available pretty convenient. Windows also has an actual response team to handle issues. They are not perfect, but check syzkaller upstream.
Like I said I use Linux and I love Linux. I don’t like Windows 10, but it is disingenuous to say they do a worse job than Linux. They do a much much better job. Low market share is not a security feature.
DMA is a very relevant example of the flawed approach conventional systems have. The IOMMU system on Librem was poorly cited in what way? He showed how broken it is compared to a robust system. IOMMU systems on Google Pixels for example have been shown to be nearly iPhone level when you consider what white hats have been limited to even with solid exploits.
He does. The Flatpak model is extremely broken. His Linux article is missing some flaws too like the in the wild abuses of the system that is still unpatched after months and the devs closed the issue. Check GitHub issue #3637 There are many more flaws, but I don’t know of anything exploited in the wild. (I can’t add more than 2 links)
“The points from the Linux article apply to Linux phones fully and there is not yet a single Linux phone with a sane security model. They do not have security features such as full system MAC policies, verified boot, hardened kernels, strong app sandboxing etc. that modern Android phones do.”
-madaidan
If I am buying a secure phone today does it matter what it has right now? The 2021 iPhone is getting memory tagging extensions. iPhones are known to require far more exploits to be chained together to get through all the security features such as double kernels, tpf0 and hardware features like PAC, PPL, and KTRR too name a few. Not to mention the APFS snapshotting. Killing well over 90% of memory corruption bugs will result in 1 in a billion chance of getting a 10 exploit chain to work. It broke my calculator trying to calculate that chance. The 2021 iPhone will not be practical to target even with unlimited resources. If I compare a 2019 iPhone to a 2019 Librem 5 that is fair. If I compare a 2021 iPhone to a 2020 Librem 5 that is not fair. Sources: https://invidious.snopyta.org/watch?v=lLEcbXidK2ohttps://invidious.snopyta.org/watch?v=31azOpD7DmI I could also point to the new iOS 14 not even needing you to share file access to give your media to an app. You can take twitter and give it read only access(and it will think you have no files and be none the wiser) or I can give it only the images I want. That isn’t out until later this month or the next. Librem 5b or Librem 5c could use a custom Redox style OS with Qubes style isolation running on the latest Qualcomm SOC with memory tagging/memory coloring and use Google’s upcoming Open Titan Project built with RISC open hardware to match the local privacy and security features. Unfortunately we live in 2020 with the iPhone 11 and Librem 5. If security from exploitation or malicious programs is the only thing that matters to me then I will have to pick the iPhone 11 every time. We will see what the next years bring.
Madaidan recommends a Pixel 3+ with GrapheneOS right now on his website for the best privacy and security by design. I see why. The man is a security researcher for Whonix(which is a great project), but it relies on Firefox and Linux both of which he calls out for glaring security issues. Check his Linux and Firefox articles. If attacking the building blocks of your own projects as sorely lacking compared to the competition is not transparency I don’t know what is. In fairness he is a large proponent of using Tor Browser if you check his Browser Tracking Article.
I’ve been using LineageOS + F-droid on my mobile devices since 2015. However, these are not solutions for normal people. Just explaining how to install F-Droid to my girlfriend over the phone proved to be very complicated and it took me 15 minutes to walk her through the steps of enabling sideloading in settings, then downloading F-Droid and installing it, then disabling sideloading again so she wouldn’t install anything else that way. On the other hand, I have no problem explaining to her how to install the app that I helped create which is hosted on the Play Store.
Millions of people do get tricked every day by Android malware into giving permissions to apps that they shouldn’t. Most people automatically give an app all the permissions that it asks for. In my experience submitting new apps to the Play Store and Apple Store, Apple takes the time to actually evaluate apps to catch the bad ones, whereas Google was just using automated tools to detect malware, which is one of the reasons why iPhone users deal with much less malware.
Like the Apple Store, Linux repos like the PureOS Store will be picky about what is allowed in. In addition, the PureOS Store will have a badge system to inform the user if there is a potential privacy issue.
This is what madaidan’s article lacked. He didn’t properly document his claims, so we couldn’t check the sources, and evaluate the validity of his arguments.
As for that particular issue, I can understand why the devs closed it, because some applications do need full access to the HOME directory. With Bubblewrap, the HOME directory can be made read-only or no access at all, and the app can be limited just a single subdirectory for storing data. This is an issue of how Bubblewrap is configured for the individual app. It is likely that apps in the PureOS Store will have a secure Bubblewrap configuration that limits access in the HOME directory.
Personally, I think Firejail is better than Bubblewrap, because Firejail has better defaults to set most directories to be read-only whereas Bubblewrap requires more work in the configuration.
I agree, but here is what madaidan wrote:
There is also a lot of misinformation about how the modem being on a separate chip means it’s isolated. This is completely untrue. Just look at how FireWire for example can be used for DMA yet it’s completely separate from the rest of the hardware. Whether the modem is on a separate chip or not is irrelevant to if it’s isolated.
Madaidan uses the example of a DMA exploit to prove that separate chips doesn’t guarantee isolation, but he never acknowledges that Purism designed the Librem 5 to only use serial bus protocols (USB 2.0/3.0, SDIO 2.0, I2C and I2S) that do not allow DMA. If he wants to prove his point, he needs to provide an example of an exploit using a serial protocol that doesn’t allow DMA, or at least acknowledge that his example isn’t relevant.
Madaidan argues that the IOMMU in the Snapdragon is more secure than using the USB bus to connect the cellular modem to the SoC, because USB in Linux isn’t secure, but his link to his other article doesn’t provide any evidence that USB in Linux is insecure. The only thing the article points out is that Linux is written in a memory-unsafe language. When I questioned him on Reddit about this, he didn’t provide any other evidence to back up his claim, besides the fact that Linux is written in C.
I see that he just now changed his article to acknowledge that the Librem 5 has an OpenPGP smartcard, but he rejects that it is possible to use this to implement a secure keystore:
Madaidan also made this same claim when arguing with me on Reddit, but he presented no reason why an OpenPGP card is less secure than Android’s hardware backed keystore. He just asserted it without providing a reason why.
Then you are very statistically lucky. Here is what AV-Test finds:
Understandable. transparencyreport.google (dot) com/android-security/overview 0.085% on a billion + device ecosystem is a lot of potentially harmful applications. A good 50% is fleeceware and ad fraud, but still not in the users best interest.
Sure, but you can protect hidden files or even just profile or bashrc and flatpak configs. You won’t break stuff.
Firejail definitely has more attack surface. Bubblewrap is quite well designed. My issues with Flatpak are unrelated to Bubblewrap which is far safer.
Firewire is a great example of separate chips being a security and privacy concern as it inherently is a weak argument. That is likely saying X project is more secure than Y project since X project has less CVEs. A meaningless stat due to reporting rates being all over the place. https://lwn.net/Articles/801157/ Internal auditing by a good team will inflate this number. Most famously would be Qualcomm.
Separate chips don’t guarantee isolation. USB is a tremendous amount of attack surface. Look at the importance of USB based attacks in tools like Cellebrite or GrayKey. Especially when running on a kernel like Linux with a substantial about of attack surface and known bugs. It is quite the weak approach and says security theater. Grsecurity puts a lot of work into this. https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Physical_Protections
There is an incredible amount of work these security chips are doing. You know that.
Yes, I am very careful with my internet usage. That is closely tied to by interest in anti exploitation. Frankly I still use Linux. It’s security is still an interesting conversation topic.
You’re right, of course, and an email app could build a copy of the address book by just keeping whatever data it is allowed to see. It might be that there is no way to avoid this. It might be that the only way to split the address book (between different messaging apps) is by not having a central storage location for everything, instead letting each app keep its own data - isolated from the other apps.
Still, I think we need to look beyond the all-or-nothing access controls and explore the possibilities and limitations of more fine-grained models.
Maybe an email app could be broken down into well-defined, limited services, making audits easier. A spam filter trying to send email would look strange, but it would be more difficult to spot in an integrated email app. Having “portals” to services could also make auditing easier, e.g. to spot suspicious data gathering.
I don’t think that that is a good outcome for the user - and I don’t think it is necessary. What is needed is the “fine-grained” access controls that you refer to - so that an email app can access the address book by name prefix or email address prefix and retrieve those two fields - but not access irrelevant fields like phone number or street address or notes …
To be honest, that is probably achievable with LDAP, or something like it.
Yes.
If you don’t trust the email app then this could be a problem.
You could frustrate the email app by requiring a minimum length of string for the prefix match and by rate limiting requests for matching.
That was one of the few somewhat valid points that was made.
In no way does that say that the Librem 5 and PureOS specifically are insecure however - as this applies across all Linux distros and Microsoft Windows and MacOS - all kernels written in C.
The power of C is its strength and its weakness.
The software security of a kernel written in C is then determined by the processes around the code - coding standards, code review, automated code checking tools, automated testing tools, bug mitigation, …
For another point of view along similar lines:
As a theoretical point, I think the original point is valid.
From a practical perspective, unless we were prepared to wait a few more years for the phone and raise a few more million dollars, we can’t expect Purism to rewrite the Linux kernel in a safer language. Maybe the author was just disappointed that Purism had not taken a more radical approach to creating a secure phone.
the question is do ALL Librem 5 devices NEED to be configured out-of-the-box with the SAME level of high security ?
maybe there will be a way to PAY for an additional service just for that a-la anti-interdiction-services specifically for those people that want to have the peace of mind …
it would be NICE if the L5 would come v1 with the same level of OS level hardening that the big-boys seem to afford …
