There's a difference between saying "bah, it's all insecure, let's just give in to the surveillance", and recognising that there is nothing on the market that actually makes strides toward foolproof security. Remember, a smartphone running the Linux kernel doesn't automatically make it secure just because it's open source.
This is a typical problem with the proprietary apps: they can dictate you how you must run them. Not a fault of Pinephone. By the way, Librem 5 is significantly faster.
Haha, you're right about that. It's the only method of communication with many people and businesses around here. Which puts it roughly in on a par with the old-school phone network, except that has an oligopoly of spyware companies.
>GrapheneOS is heavily focused on security enhancements making exploitation significantly harder:
>grapheneos.org/features
>Those other operating systems [Calyx and Lineage] don't improve resistance against exploitation and won't provide more resistance against an exploit working against AOSP/stock.
>If they specifically target GrapheneOS and put work into adjusting their exploit chains and finding new bugs as necessary, then they could certainly develop an exploit working against GrapheneOS. Costs will be higher and they'll usually need to specifically take it into account.
>Firmware exposed to remote attack surface like the radios (Wi-Fi, Bluetooth, cellular, NFC) and GPU is generally a lot harder to exploit than the OS and those components are isolated. It's much rarer and generally involves using an OS exploit to bypass the component isolation.
>Nearly all of these exploits are memory corruption bugs. GrapheneOS does actually provide hardening for firmware through attack surface reduction including the LTE only mode and other features. It can't directly harden firmware, but it can avoid exposing as much attack surface.
>So, for example, with the GrapheneOS 4G only mode enabled, vulnerabilities in 2G, 3G and 5G are not usable to exploit the cellular radio, only those exposed by 4G.
>The radio firmware also does have substantial hardening and internal sandboxing, but GrapheneOS can't improve it.
>GrapheneOS also fortifies the OS against exploitation by an attacker that has gained code execution on a component like the GPU or radio.
>Main hardening we provide is for the most common path of exploiting an RCE bug in userspace and then exploiting the kernel to escape sandbox.
GrapheneOS runs only on Pixel phones which have great hardware security.
Likely not ; they might be, by chance - but the exploits are often for bugs in places like media parsing libraries (e.g. jpeg decoder), which are not usually modified in those alternatives.
Different compile settings might render an exploit ineffective. But I’d expect any remotely popular Android derivative (e.g. lineage) to be tested by the attacker - and even postmarketOS, which is not Android based, is likely to use some of the same media parsing libraries.
Hardware kill switches are unfortunately pretty much useless. For camera it's okay, but a tape is just as good, for microphone, even the gyrosensors can record voice in some quality. And here is the big thing: there is hardly any threat model where blocking the camera would help when the software stack is a burning pile of C buffer overflows from top to bottom. If you can't trust the software to such a degree, then you might as well just not turn on your device. Seriously, what's up with the linux userspace where goddamn gnome initial setup is a C program?! Like, we were okay with lisp code decades ago in more serious things, and nowadays we actually have memory-safe languages with very close to native performance.
But the biggest problem is the lack of sandboxing, and UNIX permissions are way too crude to be of any use. The attacker at worst can't install a video driver, but can easily add anything to your bashrc, or read the content of your browser's cache, etc.
You are right, but Apple does try to rewrite most things in memory safe languages and have been doing so for quite some time now. So it is not exactly GNU/Linux.
I’m no security researcher so do correct me if I’m wrong but I assume you use firejail which is a suid program - a bug here could cause an escape to even become root. And why would you write a sandbox in a memory safe language…
Yes, you're right to be wary of suid, but primarily against local attacks on my laptop. The suid risk for a remote attacker seems rather less than from remote malware without the sandbox. Opinions may differ.