Hacker News Reader

Comment by simonh | Hacker News Reader

I'd be interested in seeing an analysis of the hardware, firmware and driver security on this thing. From what I can ascertain the security implementation on some of their phones is horrifying. It brings a different dimension to the reviewer's comment they are a 'known brand among enthusiasts especially in the fields of privacy and information security'.

https://news.ycombinator.com/item?id=30761886

View on HN

Only security thing they point out is USB access for the modem, and you can fix that quite easily with a bunch of udev rules, I guess. Disable device auto-probing on the USB port the modem is connected to, and bind the proper modem/ACM driver to the device manually via udev rule. Then there will be no exposure to "all Linux USB drivers" and you'll avoid modem exposing itself as a keyboard and typing things into your console, or whatever.

It's the same thing you should be doing on the desktop if you fear untrusted USB devices.

Or just use Qubes OS with a dedicated VM for usb devices: https://qubes-os.org.

That will still allow execution of kernel code you may not want executed (even though in a VM), and is thus strictly worse. Especially for the modem, which you need to run and interact with all the time on a phone, this sounds like overkill.

Not sure I understand your comment. Of course kernel code is executed in the guest VM…what’s the problem with that? An adversary would have to break Xen security controls to gain access to your other domains.

VM has to have some communication bridge to the host, for all the features of the modem. That's still quite a lot of attack surface, once guest VM is compromised.

It's better to not expose the needless attack surface rather than just attempting to isolate the attack into a leaky VM.

My understanding is that the paravirtualization provided by Xen is an effective control. The guest shouldn’t have direct access to the hardware device io right?

What is the alternative? If you don’t use a VM you have to expose dom0 directly to device io.

EDIT: ah I see we’re talking about a Linux phone! I agree with your point I’m not sure mobile devices have the resources to isolate every component into a VM. Overkill indeed!

Mobile devices could, if the SOC allowed every device to be isolated with an IOMMU. Apple does this, Nvidia too (though some SoCs are broken) and I think Qualcomm might as well. A lot of the other ARM SoCs seem to have just one or maybe two domains (GPU and everything else), and a non standard IOMMU for even that too.

I’ve looked a few times for an ARM SBC with a nice architecture to play with this stuff, Nvidia seemed to be the only option but they are also unobtanium right now.

>Only security thing they point out is USB access for the modem..

And the pointless supply chain vulnerability, introduced in order to game the FSF certification process, and lying about security features in their competitors, and accusing them of using binary blobs which they actually do as well while doing so with a worse security implementation.

>you can fix that quite easily with a bunch of udev rules, I guess

Exactly, why didn't they? I would understand if some of those were just teething troubles but that phone came out well over a year ago and bear in mind this analysis and criticism comes from within the OSS community trying to help them get this fixed, and hitting a brick wall.

An analysis of those things would be very interesting. At a basic level, I appreciate the neutered ME and the killswitches, which already put the laptop at the front of the pack.

The laptop also uses Heads, which is indeed known among the security experts: https://docs.puri.sm/PureBoot/Heads/User_Manual.html.

> From what I can ascertain the security implementation on some of their phones is horrifying.

Their phones run desktop GNU/Linux. Their security is then the same. It's probably not enough for a phone, if you run a lot of untrusted apps, but it's a start. Also, the app store only consists of FLOSS apps.

The parent is referring to the replacement firmware not the OS and above. This is different from running the same FOSS software on other more closed hardware.

It's a valid concern: On the one hand Purism is gradually achieving their intermediate ideal of providing machines with open firmware for all the hardware; On the other hand, if the real life security of that open firmware is poor, it undermines their underlying principle of privacy - To complicate matters it may not be technically worse than the proprietary blobs it replaced, but it's open for all to see.

In other words, to achieve real world privacy, it's not enough for the firmware to be open, it must also be secure.

I completely agree with that comment you linked, Purism is either deliberately selling snake oil or are completely clueless.

Here's another example of this with them bashing Android/iOS security:

> One of the problems with the security measures implemented in Android and iOS is that they restrict the user as much, if not more, than they restrict an attacker. [1]

When Android actually has pretty decent sandboxing [2] which I've never felt restricted me as a user, and can actually protect you from malware, unlike their recommendation which is just security theater without a sandbox when it comes to malware.

Unless you don't plan on ever installing any apps and personally audit every update yourself (since it's unlikely someone else will audit every single one thoroughly enough), malware and malicious third parties are a much greater threat than Google who is actually pretty transparent about what data they collect and handle it securely and responsibly.

[1] https://puri.sm/posts/snitching-on-phones-that-snitch-on-you...

[2] https://source.android.com/security/app-sandbox

> When Android actually has pretty decent sandboxing [2] which I've never felt restricted me as a user, and can actually protect you from malware, unlike their recommendation which is just security theater without a sandbox when it comes to malware.

Congrats on not hitting it, I guess? Android is absolutely painful if you try to do anything interesting, and it's becoming annoying even for trivial stuff - it was annoying but understandable when they started killing API surface for tasker and termux to use, it was annoying but understandable when they almost broke termux outright, but it moved beyond being understandable when they restricted file access so much that a third-party app can't move files between directories without the OS prompting you to allow the "delete".

> restricted file access so much that a third-party app can't move files between directories without the OS prompting you to allow the "delete"

What use case do you have where you have an app that you want to be able to move files but you don't trust it with the "delete" permission?

I do trust it. The OS, however, "helpfully" insists on "protecting" me and prompts every single time with no way to save the permission.

Which app and Android version is it? I've never had that issue where it prompts me every time without letting me save the permission, although if I recall requesting one time access is different than requesting permanent access for some permissions that an app has to declare, so maybe the app never declared the latter. (I admit, this is sort of silly)

This is https://f-droid.org/en/packages/com.simplemobiletools.galler... on Android 11 (LineageOS 18.1).

And yes, it may be a localized bug, but it's a localized bug that wouldn't occur on a nice normal GNU/Linux desktop without all of this, bringing us back to me agreeing with

>> One of the problems with the security measures implemented in Android and iOS is that they restrict the user as much, if not more, than they restrict an attacker.

In order to argue that, you have to list your goals, what you want to do with your phone, and the goals of an attacker. On Android, other than a few minor inconveniences, I can still achieve everything I want to with my phone, where an attacker will have a difficult time achieving their goal, of presumably stealing some data from another app.

This is compared to PureOS where you may have free reign, but so would an attacker if you install their app on your device. If you used QubesOS I'd argue that restricts the user a similar amount as Android does, not to mention missing out on a number of mobile friendly apps.

That's fair! It's quite likely that at least some of the issue is precisely that I view Android devices as just another form of general-purpose computer, and I expect to be able to run them like any other computer; if I want to download a picture from a browser, recompress and convert it to another format, and then move it to a syncthing folder and sync it off to another machine, I expect the system to make that happen, without getting in my way at every single step. But really, the file moving issue surprised me precisely because I kind of understand that lots of people expect their phone to be terribly limited, but this was a step beyond what made sense even for that usecase.

Reply on news.ycombinator.com