4 ms·
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 so
by simonh 5y ago
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 https://news.ycombinator.com/item?id=30761886
- fsflover 5y ago> 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. See also: https://source.puri.sm/Librem5/community-wiki/-/wikis/Frequently-Asked-Questions#43-how-secure-is-the-librem-5-compared-to-an-android-phone https://source.puri.sm/Librem5/community-wiki/-/wikis/Freque....
- tomxor 5y agoThe 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.
- bo1024 5y agoAn 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.
- fsflover 5y agoThe laptop also uses Heads, which is indeed known among the security experts: https://docs.puri.sm/PureBoot/Heads/User_Manual.html https://docs.puri.sm/PureBoot/Heads/User_Manual.html.
- megous 5y agoOnly 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.
- fsflover 5y agoOr just use Qubes OS with a dedicated VM for usb devices: https://qubes-os.org https://qubes-os.org.
- megous 5y agoThat 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.
- rank0 5y agoNot 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.
- megous 5y agoVM 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.
- rank0 5y ago
- Elyra 5y agoI 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/ https://puri.sm/posts/snitching-on-phones-that-snitch-on-you... [2] https://source.android.com/security/app-sandbox https://source.android.com/security/app-sandbox
- yjftsjthsd-h 5y ago> 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".
- Elyra 5y ago> 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?