To me it is someone blowing their own opinion out of proportion. Some of it is, I guess, a point,but all of it seems trivial and straw man like.
Either way, I’m not moved in the slightest. The way the article is written does seem like a great way to get people to click on links.
Still. The website is secure and uses https… I fixed it already
That roughly matches my assessment. The author looks to be another Rust fanboi…
The biggest single issue is they start by assuming a compromised machine. Guess what? If you have a compromised machine, you have a compromised machine. And? Why bother getting root? What you actually want is almost certainly in .mozilla or similar anyway (bank passwords and the like).
We already had these discussions multiple times in this forum and the “insecurity” problems mentioned are always the same.
The main point here is: If you install OPEN SOURCE apps from the repository your are 99% save because you or other people know how these apps work and what it does in the background. And nothing is more secure than knowing the source code. Security is always related with freedom. If you as user can do every thing on your phone a very good hacker can do that to. But that does not mean that this will happen.
Again if Linux would be that insecure: Why should anyone use it?
The real question here is: Do you want root privileges or not? More privileges more responsibilities!
And Purism can only do what is possible at the moment and if there is no free modem they have to deal with that… And I am not afraid that the NSA is spying at me because if the want they will and they are not dependent on your smartphone. I am afraid of companies like Google or Apple which collect all user data and every activity I do on my phone and with my phone.
My last word to this article is: Complaining is always easier than changing something!
On their website:
OpenBSD is lacking in a lot of ways. Many of its exploit mitigations are half-baked/useless
Yeahhhhhhhhh… go tell that to the security researchers that keep finding vulnerabilities that affect every system except OpenBSD.
My respect of this random stranger on the internet has gone down by a lot.
EDIT: Also, because this is Linux, there will be virtually an infinite amount of updates you can get. Compare that to my last phone that got 1.5 years of features and 0.5 more of security.
While refuting posts that make exaggerated claims like this line-by-line isn’t a valuable use of time, it is worth making some more general statements about security as it pertains to our approach because it applies beyond any individual post from a critic.
People who come to us from an Android, Windows or iOS background often have issues with our approach because it’s so radically different than theirs. We have different constraints than Android, Windows, or iOS. We factor user control as opposed to vendor control heavily in our design and that often means rejecting security features that those communities accept. Those OSes make very secure cages, but unfortunately those cages restrict the user even more than the attacker. That’s largely the point of their approach–security against attack is the marketing story, but the prime motivation behind their measures is to prevent the user from changing settings or installing software the vendor doesn’t approve of (and in the case of iOS, the ability to remotely revoke software). This allows the OS, for instance, to enforce carrier restrictions on whether to allow tethering, install 3rd party applications by default that the user can’t remove, etc.
This approach is why we went with PureBoot instead of UEFI Secure Boot on our laptops, for instance. We wanted the ability to detect tampering but rejected an approach where the user would have to get the blessing of a vendor to boot the OS of their choosing. We chose to solve the problem in a way where the user was in control of their own keys and their own computer.
Our approach is to lay the foundation where the user can trust the system and has the tools to secure it, without depending upon Purism or other vendors as the anchor of all trust. We think the strongest foundation we can build trust on top of is free software and that is why we are pushing initiatives like reproducible builds so much. While it’s not impossible to inject malicious code into free software, and there are certainly examples in the past, it’s definitely much more difficult to do so without detection long-term than when dealing strictly with binaries. Will we consider some of the more advanced sandboxing kernel features for application in the future? Perhaps (and we already plan to do so for userspace apps via bubblewrap+flatpak), but we will always balance that with the desire to allow the user to control their own computer.
Beyond that, it’s silly to dismiss hardware kill switches entirely just by thinking of some scenario where they wouldn’t address a particular threat. They are a tool in the toolbox, and as such can be incredibly powerful when used thoughtfully (and properly) against many different threats. When used in concert with software switches within the OS itself you can get even more fine-grained control and protection from a wider array of threats given even the software switches within the OS are more trustworthy than, say, “location services” software switches in Android.
What you see in PureOS on the Librem 5 today is the foundation, the start, not the end, of our hardening plans. We have to start with a solid foundation before we can build more security controls on top of it.
For what it’s worth, I’m planning on writing up a general-purpose Librem 5 hardening guide before Evergreen ships, to guide people through some of the proper use cases for kill switches as well as how to further lock down the OS on top the hardening we have in place by default.
I love this idea. I will look forward to seeing that guide.
That and making blanket statements like “X is useless”.
Case in point: “Mic kill switch is useless because there is a sophisticated attack using the gyroscope” that could allow speech to be listened to (at low quality and might require sophisticated post-processing to get any useful information out of it).
So straight off the bat, the mic kill switch will completely defeat an attacker who is attempting to listen in using the mic. So it raises the bar for the attacker. That’s a good thing.
Secondly, it assumes that the current version doesn’t and/or no future operating system software version mediates access to the gyroscope. Let’s assume that this is currently an issue (unrestricted access to the gyroscope), it is something that can be addressed in software in the future.
As you say, if the attacker has root access then the attacker can bypass any operating system controls BUT you should be trying really really hard to avoid an attacker having root access. If the attacker already has root access then you have probably already lost.
Thirdly, as you say, it assumes that the attacker is already running random code on your phone in order to perform this attack. Your main goal should be to avoid that situation in the first place.
I’m not sure but web browsers may already be blurring the information available to a script from sensors like the gyro - so that the gyro functions for basic rotation detection but without being able to eavesdrop on speech. Clearly a web browser would be the easiest way to get you to run random code, and the web browser is a good place to restrict access to the gyro over and above what restrictions the operating system imposes.
Other case in point: “Network kill switch is useless”
His point about exfiltration is fair. If an attacker is already running random code on your phone, it can indeed batch up data for exfiltration because surely you will eventually enable the network. (Technically, you might only enable the network when at home where additional infrastructure may detect and thwart the exfiltration but let’s take his point.)
However it completely misses the point about why I might want to use the network kill switch. For example, I don’t like the fact that WiFi is used to track me and identify me as I move about in public spaces. For that use case, the WiFi kill switch works as advertised. I can turn on the WiFi when in public only if I actually intend to use WiFi. Or I can leave turning it on until I get home.
The anti-exfiltration use case is a very narrow view on all the reasons why a person might want to use the WiFi kill switch.
@Nami, you should read this Reddit thread where I argue with madaidan (a Whonix dev) and Daniel Micay (the developer of GrapheneOS) about the points raised in that article.
Some of madaidan’s arguments don’t make much sense, but he and Micay do raise a couple valid points about better kernel security in Android vs Debian. The problem is that they seem to be exclusively focused on kernel hardening, and often fail to address the larger issues beyond the kernel and they refused to acknowledge that Purism may also have ways to do things like secure and verifiable boot. Just because it hasn’t yet been implemented on the Librem 5 doesn’t mean that Purism won’t do it. It is hard to argue about how the OpenPGP card will be used, when it is not yet implemented.
I’m not going to rehash all the arguments that I already made in that thread, but let add some additional points that I didn’t mention:
PS: madaidan uses a pseudonym and some of his code commits are found in GrapheneOS, so I confused him with Daniel Micay. He got really offended that I had confused him with Micay, but he causes this kind of confusion by posting articles on the internet under a pseudonym. As you can see from the thread, I found out that both he and Micay were quite obnoxious, so in the end, I decided that it wasn’t worth arguing with them any further.
According to their logic, the lock on their front door is useless because it can’t stop dynamite. Bet they still use theirs, though, and would refuse to buy a house that couldn’t have one installed.
This is already not true. The gyroscope is a sensor attached via some bus (in laptops, and likely the L5, usually the USB). It gets accessed via the standard file-like device access (/dev/something). Which means you can restrict access to it simply by setting it 700, and then using setfacl to allow access to specific applications. There’s already been a bunch of work on getting desktop users able to exist with everything inside of firejail (kinda lightweight docker). The “standard” config for firejail totally hides /dev (and most everything else) from the jailed application.
As for the wifi kill switches, there’s a much simpler reason to want them. It’s a “do not disturb” mode which maximizes battery life.
and that should be in the constitution for the XXI-st century revision 
i believe the question that we should ALL ask ourselves is :
“how do we create AWARENESS and easily-accessible OPPORTUNITIES (or why not ? a REWARD system) for ALL people that use NETWORKED technology or feel FORCED to use it in order to have access to HUMANITY ? for the purpose of strengthening the weakest links while simultaneously NOT weakening the hardest links in the human gene pool.”
No name, no date, no footnotes – except for some links back to other pages on the same site with all the same defects. Useless.
I always find it interesting to see/hear things from different and unexpected angles. It shines - even if partly flawed - light to areas that may have weaknesses to address. Even if they are possible only in special circumstances, it’s good to be aware for the user to manage them with their behavior (instead of system making the decision for them). And it makes sure @Kyle_Rankin does not run out of things to do (coding or writing)
Now for some “TL DR” stuff…
I think the main thing is - as has been said here a couple of time - that the base assumptions (call it security model for now) are different and in that, the Android/iOS model and the L5 model (I’m not attaching Linux to this since it doesn’t include hardware) are answers to different questions, to different needs and goals. And I’d like to remember that there are other things at play here than “only” security (including privacy in this) as there is the business model and the ecosystem of selling information (an most of it is rather general, although the personal info section is more important). The latter is so ubiquitous that it Android/iOS are more or less just support platforms to enable it (among other things) and make the user feel like they are getting something in return (like security against some things or usability etc.).
I’ve been working on this idea for some time, based partly on complex network theory (and I can only hope I can translate it here), that there is kind of a built in “tug-of-war” in every network service connection where you have the individual user and the system negotiating/struggling to set the limits which each need to achieve and maintain their respective security/safety/privacy. Both want to ensure their continued existence and neither wants to be used in a manner they do not condone. It’s a balancing act that may not have stable equilibrium, as the needs shift slightly constantly (sometimes in obvious ways like when there is a threat or attack). It’s about whose security/safety/privacy is more important and to what level that/those need to be ensured. Individual gives more value to privacy but the system needs information to trust you to let you in and make sure you are behaving acceptably. This can be applied to governments and such social systems as well. Some choices are easy, as individual can choose not to use a system or service, but the real problem lies in the ones which are huge de facto standards - almost mandatory to use if you want to be part of the world around you (or just services that keep you alive) - with which the system(s) can be made to demand a lot. All in the name of security.
But my point is not about that well known model, as it’s about understanding that system(s) and individual(s) have different needs that are in flux and they are rarely (if ever) compatible for long periods - unless one rules over the other dominantly. Once the individual gives something away, it’s control is lost forever, as they can not change and rebuild and patch like the system(s). System(s) as such are not (mostly) evil, they just are. But they can be repurposed to do nasty things and complex systems have a lot of unintended consequences (on top of the intended ones that haven’t always been well thought out) - on both points, I suggest some light reading in the form of “Weapons of Math Destruction”. The scale can be big or small.
Soooo… Having the L5 model is a step towards gaining control in this “tug-of-war” but there are more ways that we are connected to various systems that we do not (yet) have control. That is not a reason not to try to plug these holes in the damn - it’s still less water taken in, even if there still are other holes (the pumps have better chance of keeping us afloat longer - to strain the analogy). The fact that it’s difficult to do it this way and the road is long, is not a reason not to do it. And I don’t believe it’s possible to be without being connected to system(s) - it’s about finding ways to make sure both, individual and system(s owner/admin), can feel safe and secure.
This may seem blindingly obvious and/or I may have missed it but @Kyle_Rankin, has this difference in approaches between closed systems (A and i) and L5 been laid out? It might be an assumption to think that people understand it fully - what it means, what it requires from user behavior, what it doesn’t do etc. - and having that baseline stated clearly might be needed. I know it’s been talked about in bits here and there. Maybe a topic for a blog post and/or FAQ and/or About?
I think for the average customer it is completely unnecessary. In fact it would just scare off people who would have otherwise bought a Librem 5.
Have it in some deep dive material sure, but don’t plaster it on the main page for it. I don’t believe this is unethical either as Purism has every intention of helping their customers position their devices to be secure and private.
I have seen this article pop up from time to time, in xmpp chat rooms, reddit and now here. I just wish the webpage where it is posted had a comment box, so that the article could be debated there, and not having to repeat the same arguments every time it pops up in some online space.
And I saw how horrible (as in personal insults and bashing of people) the debate of this article was in some spaces, like it was already mentioned above.
This is one of those moments in which I take my “Purism hat off”, so do not quote what I am about to say as a response from Purism.
Like said above there is not one Android kernel, there are several and the state of their updates depends on many things. With a GNU/Linux distribution that supports mainline kernel you can get lifelong updates.
This article like already said above, corresponds to a world view (that several people working on Android, Whonix, and a part of the Qubes folks share) on security in which you “need” to protect the user from himself, because he is downloading and installing applications from repositories/websites with millions of not properly vetted applications, and a ton of malware applications to add to the equation. So in essence (in this world view) you need a read only file system, and permit nothing to the user.
That is the Android and windows model.
Like already said above, we try to balance security with the user still having power over it’s machine.
Basing your repositories of Debian like PureOS does, while not a 100% safe silver bullet already does a lot to address those concerns, and establishing thrust.
More and more application and packages in Debian are reproducible builds, that allow to confirm that the binary packages distributed correspond to the published source code that can be audited.
Also it is not everyone that can publish a package to the Debian repositories. To become a Debian Developer it is a very long process to establish, who the person is, the quality of his/her work and intent.
Again, while not a silver bullet this alone makes an application that comes from a Debian repo more trustworthy that from Google play store.
I imagine that Flatpak applications get FLAK in this article because it is the most similar to an Android app model and they base their review of Flatpak appliations in comparison to an Android application.
Yes, the permission model in Flatpak needs improvement, specially being able to allow a user to set the permissions before the app is installed. But in my opinion application permission management is not a silver bullet (either in flatpak or Android and it’s derivatives) as long as applications in name of user experience get designed as swiss army knifes full of features that for all of them to work on properly, they need most permissions for the system. For example a android xmpp chat application being able to make video and pictures directly and sending your location to your friend that is going to meet you and with that your chat application having access to the camera and GPS.
Application permission in this model is not enough to preserve user privacy and needs to be combined with apps that: either do less, or that come from trustworthy sources like from a trusted repository with only open source applications that the code can be audited. This we are trying to address with the PureOS store.
At this moment in Flatpak you have Flatseal which allow to set permissions post install. While not perfect as you set the permissions post install, it is a progress. And software evolves. Flatpak has been evolving.
The part of software evolving brings me to one of the points that irritates me most about this article. It treats PureOS as it currently is, as an already finished product. And that is far from being the case. It is constantly improving.
For example, we wan to work on chain of trust with securing the boot process.
The Android operating system (ASOP) is 12 years old, the system GrapheneOS is based on a distro that has 12 years of being built. PureOS for mobile is at it’s start. While we will not take 12 years to get where we want, to make an analysis of PureOS for mobile as an already finished product instead of trying to figure out: where they want to go, what they want to reach and base on that, seems to me a limited analysis at best.
As for nitpicks about the article itself:
That is supposed to be an article about: “Linux phones”. There are currently around 18 GNU/Linux, distributions for mobile devices with mainline kernel support (or working on it), and they have different models. Some like UBports even use a read only file system, as many people around the Whonix and GrapheneOS advocate (with some parallels to Android). Some have already implemented Full Disk Encryption like postmarketOS. Some are based in Debian (or Ubuntu), others in Fedora, others in Alpine Linux. And all these are evolving quite fast with rapid development.
And yet this article, instead of making an assessment the general state of GNU/Linux distros for mobile with mainline kernel support and their models in comparison to ASOP for example, it focuses on only one PureOS.
Which, for me, means either the author did not researched anything else, or I have to question his reasons.
The whole modem isolation critique in the article, and stating that IOMMU to prevent DMA is the same as physical separation? It links to a page about the linux kernel to say USB stack is not so secure in modem separation without having an explicit reference to it in the linux kernal page.
So USB stack is insecure because “the whole linux kernel is insecure”…
Also links to a page about FireWire and DMA access, when FireWire is unrealted to the USB stack.
The part of the Librem 5 not allowing Firmware updates. To support this claim, the article links to one post we made about the memory training, binary.
1 - That is not the only firmware in the Librem 5 and PureOS.
2 - We intend that in the case we can liberate other pieces of firmware to bring that firmware to users.
3 - The article makes it seem like firmware updates are common and constant in Android (ASOP), just FIY they are not
Again do not take this as a response from Purism, others have already replied better than me. This is just a semi rant post due to:
PS: That article should really have a comment section, that way the arguments would all go in one place and people that read it for the first time would read the arguments there.
(this is not a critique to the Original Poster)
Yes, I noticed that too. It doesn’t make sense. Could be poorly maintained web site (e.g. the page did at one time contain the information but no longer does) or the second article could just be poorly put together.
At a certain point … haters gonna hate.
USB security problems are real, but I do not expect that PureOS can handle them in its infancy at all.
https://blog.invisiblethings.org/2011/05/31/usb-security-challenges.html
"If you need to disable network access, you can use airplane mode. "
LOL