"Librem 5 & PureOS ridiculously insecure"

Software PureOS
21

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:

  • Being hard to maintain a cool head about this article after seeing how the debate about this article went on other spaces with personal insults
  • Having to read this article time and time again on different spaces being presented as new and having to post the same arguments again and again.

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)

18 Likes
22

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.

23

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

1 Like
24

"If you need to disable network access, you can use airplane mode. "

LOL

6 Likes
25

Securing the USB system is something that was brought up back in 2018 (by me). There is a project that adds device pairing for USB similar to the way it works for bluetooth, but it has two major drawbacks preventing its widespread adoption. First is it doesn’t protect the BIOS or bootloader, as it hooks into the Linux kernel. Second is few users have PS/2 or serial keyboards, which means you have to register your I/O devices before enabling the whitelisting, or you can’t whitelist your I/O devices.

Still, once I get my hands on an L5, I intend to set it up, and will post here how to do it.

7 Likes
26

Well, if you buy a house the first thing you do is change the locks anyway, that the prior owner/renter may have the key to.

27

I think it would be great if the L5 can get a good review from Bruce Schneier, if anybody.

28

if you have “nothing to hide” the first thing you do in order to prove your innocence to the prior owner/renter is you completely remove all doors/windows (pun intended :joy: ) to your house. that way, no back-doors need to be installed by the prior owner/renter in order to maintain “compliance” … :upside_down_face: :sweat_smile:

29

Two real-world examples that i’m through:

a) Killswitch
Received an exceptionally well made malware-email. Thousands have been disregarded before, but that one directly got my attention. It said something like someone had hacked my computer and observed me for months via camera, mic and the like.
The email was that well made… nevertheless, it took me max 3 seconds to disregard it as fake. My librem 13’s mic/cam-killswitch is always off. So observing me this way for month was plain Impossible. Would it not have been my Librem, it would have cost me much more thoughts and sweat…

b) Android and profiling
I took a reset Android-phone of a mate living 600km away and officially not connected to me in any way. Combined that with a never used secondary sim-card of my mother in law. Avoided WiFi, WhatsApp and the like.
Nevertheless, it took only some days till i was asked by certain apps/webpages wether its me. It took a week till that phone and the logics making use of it and its sensors certainly talked to me as me. They had associated me with my formerly known profile using a totally unknown device and some precautions within just a week.

Those two experiences are enough for me to know, that Purism’s ideas and ways those have been realized were the right choice for me and are well worth to receive my support.

Thank you, Purism

PS: If you care about a solid base first and stabilize it later to be absolutely top-notch, you’ve got me in your boat.

9 Likes
30

No computer is absolutely secure. Forget that, at your peril.

Look at Specter, Meltdown, and a bunch of new similar, hardware attack vectors. Our allusion of security was broken in a heartbeat to billions of CPUs globally.

If you want security, don’t put it on a computer, not on Linux, nor iOS, or any other OS.

I am not buying a Librem 5 for it’s better security, rather I’m buying it because I believe in the ideas behind [FLOSS] (Free/Libre and Open Source Software) (https://www.gnu.org/philosophy/floss-and-foss.en.html).

I run Linux every day and I very much appreciated this article on Linux’s insecurity. It’s a good reminder that there is still much security work ahead. Almost every day, one or more serious Debian security bugs are fixed, as reported by the Debian Security Advisories.

On a personal level, my Thunderbird now won’t open links to my Firefox because of AppArmor. It’s a pain. But I get why we need AppArmor. I can disable AppArmor for now till I find the better way to protect it. It’s a process of locking down better, little at a time.

Security involves the product of two fundamental variables:

  1. The value of what is protected, and
  2. The difficulty in stealing that value.

The point is you don’t need to make things absolutely secure.

All you need to do is to make your own place more secure than your neighbor, i.e. make your own fence higher, and add a dog, and the crooks will likely go next door for the easier time stealing what they want. There is no surety here of course, only reasonable probability.

Looking froward to Evergreen. It’s been a long wait, but worth it.

1 Like
31

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
32

I think: expected cost vs expected return times expected chance of success

would be closer to the mark.

33

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
34

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.

35

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.)

36

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 :slight_smile:

37

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
38

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
39

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
40

Oops! You’re right, the estimated return is multiplied by the expected chance of that return, not the expected cost.

1 Like