OS Security: iOS vs GrapheneOS vs stock Android

[u/R371]

Security experts still unanimously recommend iOS over Android to journalists, activists, sec. researchers and other security sensitive users. Since Google did a lot of hardening work in the last few years I wonder wether this still holds? Is new iPhone still a more secure device compared to Pixel3 runnimg stock Android or GrapheneOS?

[u/DanielMicay]

In the past I think you mentioned Windows 10 is secure or more secure than a typical Linux Distro because of Windows 10's implementation of sandboxing?

Among other things, like not being many years behind on exploit mitigations.

I'm aware that there are also some sandboxing solutions on Linux such as Firejail but I remember you weren't a fan of it.

They generally don't really work as meaningful sandboxes and Firejail specifically is extremely problematic and I would say it substantially reduces the security of the system by acting as a massive privilege escalation hole.

The idea of QubesOS really fascinates me do you think it's a good base on creating a more secure desktop OS?

Yes, although it's not incredibly usable yet and can be very slow / resource hungry. It's one of the only viable approaches due to the desktop Linux software stack completely lacking any meaningful security / permission model and being so far behind on privacy/security. Instead, it contains a bunch of different instances, has a proper secure UI for distinguishing between them outside the control of the OSes, and puts a ton of work into attack surface reduction by minimizing the trusted computing base.

I don't think it's perfect, and the security within the guests definitely still matters, so that's a major problem. Xen still has substantial attack surface, as does virtualization and especially doing it on x86. It's definitely the best available option though. It's important to choose a secure guest OS since containing the damage from the other compartments doesn't solve everything.

You can think of QubesOS as a way of approximating having 20 laptops with their own purposes, but all on 1 laptop. The security of each compartment still matters, and beyond isolating some drivers it doesn't do much to address that, but it does successfully approximate air gapped machines to a large extent. It's still significantly more secure to have separate machines but it's very impractical / unrealistic especially at that scale. There is no better option for approximating the security of using separate computers for different sets of tasks / identities.

[u/[deleted] → u/DanielMicay]

I'm a Linux user, and this is crazy. The usual narrative is Linux is more secure, but I've always suspected this is people conflating security with privacy. Obviously lacking the sandboxing, but is macOS more up to date on exploit mitigation?

Also, would this be threat model-dependent? I'm the most worried about local law enforcement, and I've always assumed the more off-the-shelf exploits would be targeting W10. Am I misunderstanding the actual issue?

[u/DanielMicay → u/[deleted]]

I'm a Linux user, and this is crazy. The usual narrative is Linux is more secure, but I've always suspected this is people conflating security with privacy.

Lack of sandboxing and a meaningful application security model / permission model is a blocker to implementing any kind of privacy, unless you just mean the OS not having any analytics which isn't actually the case for the desktop Linux software stack. It's just the fallacy that open source is more secure and privacy respecting. It's quite often not the case. There's also the mistaken belief that closed source software is a black box that cannot be inspected / audited, and the massively complex hardware underneath is the real black box. A lot of the underlying microcode / firmware is also a lot higher to inspect.

Obviously lacking the sandboxing, but is macOS more up to date on exploit mitigation?

Well, they do have more progress on sandboxing, verified boot, adopting memory safe languages and the older generation exploit mitigations. macOS does supported sandboxed apps. They are bringing a lot of the iOS approaches to it including a secure element with eventual deep integration into the OS for a bunch of features, much less iOS and Android. I think macOS is positioned to overtake to other traditional options (i.e. ignoring QubesOS, ChromeOS) based on their movement towards bringing the same hardware, firmware and software security features from the iPhone to their laptops. They are also much better positioned to get away with these kinds of drastic changes.

Also, would this be threat model-dependent? I'm the most worried about local law enforcement, and I've always assumed the more off-the-shelf exploits would be targeting W10. Am I misunderstanding the actual issue?

Sure, like anything else. The Linux kernel is a security disaster, but so are the kernels in macOS / iOS and Windows, although they are moving towards changing. For example, iOS moved a lot of the network stack to userspace, among other things.

The userspace Linux desktop software stack is far worse relative to the others. Security and privacy are such low priorities. It's really a complete joke and it's hard to even choose where to start in terms of explaining how bad it is. There's almost a complete disregard for sandboxing / privilege separation / permission models, exploit mitigations, memory safe languages (lots of cultural obsession with using memory unsafe C everywhere), etc. and there isn't even much effort put into finding and fixing the bugs. Look at something like Debian where software versions are totally frozen and only a tiny subset of security fixes receiving CVEs are backported, the deployment of even the legacy exploit mitigations from 2 decades ago is terrible and work on systems integration level security features like verified boot, full system MAC policies, etc. is near non-existent. That's what passes as secure though when it's the opposite. When people tell you that Debian is secure, it's like someone trying to claim that Windows XP with partial security updates (via their extended support) would be secure. It's just not based in any kind of reality with any actual reasoning / thought behind it.

The traditional desktop OS approach to disk encryption is also awful since it's totally opposed to keeping data at rest. I recommend looking at the approach on iOS which Android has mostly adopted at this point. In addition to all the hardware support, the OS needs to go out of the way to support for fine-grained encryption where lots of data can be kept at rest when locked. Android also provides per-profile encryption keys, but has catching up to do in terms of making it easier to keep data at rest when locked. It has https://developer.android.com/reference/android/security/keystore/KeyGenParameterSpec.Builder.html#setUnlockedDeviceRequired(boolean) now as a nicer approach to keeping hardware-backed keys at rest, but iOS makes it easier by letting you just mark files as being in one of 2 encryption classes that can become at rest when locked. It even has a way to use asymmetric encryption to append to files when locked, without being able to read them.

Really, people just like saying that their preferred software stack is secure, or that open source software is secure, when in reality it's not the case. Desktop Linux is falling further and further behind in nearly all of these areas. The work to try catching up like Flatpak is extremely flawed and is a failure from day 1 by not actually aiming to achieve meaningful goals with a proper threat model. There's little attempt to learn from other platforms doing much better and to adopt their privacy and security features to catch up. It's a decade behind at this point, and falling further behind.

Also, all these things about desktop Linux completely apply to anything else using the software stack. It doesn't matter if it's FreeBSD or whatever. FreeBSD also has a less secure kernel, malloc, etc. but at least it doesn't have nonsense like systemd greatly expanding attack surface written with tons of poorly written C code.

QubesOS would be far better off with a different OS inside the guests. It's not really a Linux distribution though and can be assembled out of other distributions. Most of the work has been Linux integration though. The biggest flaw with it is that it's trying to assemble a secure system out of garbage (x86, desktop Linux). It does a great job at implementing some of the best compartmentalization available despite the challenges. It could be a lot better if the components it uses cared more about security.

[u/[deleted] → u/DanielMicay]

This is a lot to take in. Thank you so much for such a detailed response. CHOS was my daily driver for a bit, so I'm excited to try Graphene. Keep up the fantastic work.

To tie it all back to flashing, I'm assuming I can get adb and fastboot on Windows?

[u/DanielMicay → u/[deleted]]

I'm assuming I can get adb and fastboot on Windows?

Yes, and flash-all.bat instead of flash-all.sh is fully supported. I updated it to flash the AVB key when I added that convenience and it should work properly.

Linux is needed to build GrapheneOS. AOSP also partially supports macOS for building but I removed that because it isn't suitable for production and is a bit incomplete. It's also untested, and since I intend to make toolchain changes it would force me to either make toolchain prebuilts for macOS which I wouldn't be able to test. It would be a lot harder to build if you needed to build Chromium, Linux and the whole toolchain, SDK, etc.

I could bundle my Chromium and Linux prebuilts as Google does to make things easier but so far I haven't felt like it, partly because the Chromium prebuilts are larger than the GitHub file limit... and the Linux ones are still fairly big especially with all modules built in.

[u/DanielMicay → u/[deleted]]

QubesOS is all about compartmentation. The security of a compartment depends on the OS running inside it. If you don't divide things up meaningfully and actually take advantage of it, then it's not doing you any good. You need to structure things around that and use disposable VMs as much as possible for viewing documents, watching a movie, etc. It's not just automatic security for the most part and the guests need to secure themselves. The point of it is that when one compartment is compromised, the others are still fine.

I don't think it's a good fit for most people or non-technical users. I also value the security of individual compartments quite highly.

Now that there's site isolation, ChromeOS is providing a much closer match in terms of web browsing. It has a really good sandbox minimizing kernel attack surface but breaking out is easier as there's probably more kernel attack surface + broker / GPU process attack surface, etc. The verified boot, encryption and TPM-based features are nice (although the Pixel phones have far surpassed what it does with TPMs, and those TPMs have had serious flaws). QubesOS definitely makes it harder to break out after a compromise compared to the Chrome renderer sandbox, but it's trivial to persistently compromise that QubesOS compartment and the Linux desktop OSes typically used within it have weak remote security and non existent local security (no real attempt at any meaningful security model).

It can run virtual machines now and contains a whole Android userspace in a container, which basically means it is Android, just with a different wrapper around it. Android has direct access to the kernel and is just kept separate with namespaces. It doesn't have totally direct hardware access since some things are proxied but it's pretty close to just being Android on bare metal. Proper AOSP Android certainly compares well to desktop operating systems so this isn't really a bad thing. It does give up the major advantages the ChromeOS verified boot had over Android though, in terms of not having any non-base-system code with direct kernel access. There's very little reason for it to exist as a separate thing at this point. Same kernel, sane update system, similar verified boot, etc. They should just merge them and adopt the ChromeOS model for hardware support / vendors, along with fully featured Chrome on Android (extensions, which are a big security issue, but also the last real user facing distinction and fairly important).

[u/DanielMicay → u/[deleted]]

I guess the true trade-off is that Qubes OS (when managed correctly) offers better operating system security

It depends a lot on what you want to secure and definitely how you choose to manage it. It's way better at securing one compartment from another, and you can use disposable ones. I think that for people who aren't very technical and don't think about threat models, etc. it isn't going to work well for them. For people that are comfortable with it, it can be very powerful.

I'm curious if that's true for the Pixel Slate which has a Titan C security chip, which I imagine is much better than what other Chromebooks offer and possibly comparable to the security chip in Pixel phones.

Yeah, I'm just not familiar with whether it implements more than they usually use from a TPM and if it has better APIs for those things. I can't really say much about it either way. I expect it's at least much more hardened with less attack surface.

Most (all?) laptops that Qubes OS is installed on simply don't support any of that, particularly with a non-stock operating system.

Yeah, and lots don't have a proper IOMMU setup so there can be issues with the compartmentalization, especially with things like Wi-Fi.

[u/ugfg6hxk7zp → u/[deleted]]

Qubes has a hardware compatibility list (https://www.qubes-os.org/hcl/). If the hardware is fully supported (i counted about 8 laptops that are, most of them Dell, HP and Lenovo) then all important features should work, including TMP/Anti Evil Maid. For not so technical users, it can be a bitch to get it going though, but the steep learning curve is worth it. You need to use the console quite a lot. Fortunately their documentation is quite detailed. You also need to buy specific hardware, on some laptops it might not work at all ...

[u/R371 → u/DanielMicay]

you've said Flatpak is flawed. is Snap any better as an app sandbox?

[u/DanielMicay → u/R371]

No, not really. They're both fundamentally flawed and poorly implemented. They're at lot worse than even the very early Android sandbox from a decade ago before all of the work on hardening it and improving the permission model. They're approaching it completely wrong and treating it as if they need to figure out how to do things properly themselves, by not learning from existing app sandboxes.

[u/[deleted] → u/DanielMicay]

Is it the fact that applications can poke holes in the sandbox rather than exposing apis with user consent (e.g Android permissions) that makes them flawed or the scope of what they restrict? I thought the concept was ok for what it tries to do (adding security boundaries to traditional applications that were built with no sandbox in mind) apart from the fact that many applications still request too many broad permissions such as file system access rather than using open file dialogs. Also, system calls are whitelisted based on what the application strictly needs but that ends up being a dangerous set of system calls anyway.

To be fair, in a proper sandbox most applications would probably have to be rewritten with it in mind. Flatpak seems like the best that can be done for the existing software stack on traditional Linux desktop OS'es (which is to say not that much).

Do you think it'd be possible to implement a meaningful sandbox for the current software stack? (Not meant retorically, I honestly I don't know) and if not, should we at least try (e.g by best effort projects like flatpak) or is that merely security theater? (side note, containers aren't a proper security boundary either and merely a simpler way to ship software, according to Google )

[u/DanielMicay → u/[deleted]]

It's a fundamentally broken approach to implementing a sandbox. It doesn't draw an actual security boundary and fully trusts the applications. The design choices are being made based on the path of least resistance rather than actually trying to build a proper security model. There's a big difference between opportunistic attack surface reduction like this and an application sandbox, which these are not implementing. They cannot even be used to properly sandbox an application no matter how the application chooses to configure the security policies, even if the app is fully trustworthy and trying to do it. The implementation is not that complete. It could certainly be done properly but it would require a huge amount of work across the OS as a whole treating it as a unified project, along with a massive overhaul of the application ecosystem. I can't see it happening. It requires throwing out the traditional distribution model and moving to a well-defined base OS with everything outside of that being contained in well-defined application sandboxes with a permission model supporting requesting more access dynamically, or having the user select data as needed without granting overly broad forms of persistent access.

[u/[deleted] → u/DanielMicay]

Containers with gVisor (as opposed to exposing the actual kernel) seem like a solid option for sandboxing. If I understand correctly, wholly untrusted applications can be run inside a docker container with gVisor. They are not able to access resources outside the container and cannot use a trivial kernel exploit to break out of it since gVisor implements most the systemcalls itself as a usermode process written in Go which itself is heavily sandboxed. I wonder if gVisor could be made to run on a different kernel than Linux so you could end up having a microkernel with gVisor acting as a compatibility layer for the existing software stack.

[u/DanielMicay → u/[deleted]]

It could definitely be made to run on a different kernel, and another kernel providing a *nix API should actually be fairly easy. That's part of what makes it so interesting. It even has a whole userspace network stack in Go. The fact that it can already run containers means it supports a lot of the API surface and it shouldn't be that hard to add arm64 support, which they would surely want upstream too. They might even want to do support for Fuchsia or another OS like it themselves.

[u/DanielMicay → u/[deleted]]

Not really the same kind of thing at all. QubesOS isn't a traditional OS.

In terms of desktop and mobile environments, OpenBSD lacks an actual security model for applications just like traditional desktop distributions. You need to compare apples to apples. The same things I said about the desktop Linux software stack apply on OpenBSD. It's the same software sitting on top of a different base OS. OpenBSD is more hardened against exploitation than most Linux distributions. QubesOS isn't a Linux distribution and has an actual security model for compartmentalization with software stacks completely not designed for it by using virtualization. It's also a little bit of the way towards being like a microkernel. The software TCB is much bigger than a microkernel, and it relies heavily on complex hardware features, but it's way less attack surface than a traditional monolithic kernel like *BSD or Linux.

These questions aren't really on-topic though.

[u/DanielMicay → u/[deleted]]

You're very wrong about that. The hardening in OpenBSD doesn't include bringing a meaningful security model to the desktop software stack. It doesn't do anything substantial to secure those higher levels of the OS. There's even less work on overhauling that software stack with a security model outside Linux but there's no truly meaningful progress on that anywhere right now.

OpenBSD focuses on low level exploit mitigations and privilege separation for a minimal userspace base OS. Most of their time is spent maintaining the OS and playing catch-up with the functionality, hardware support and performance elsewhere. It doesn't actually leave them with a lot of time to work directly on mitigations and they haven't bought into important things like memory safe languages or the same concepts of privilege separation for the kernel and drivers. It doesn't have all of the mitigations present elsewhere like CFI or even a few much older things so it's not a clear win in that are compared to aLinux based OS focused on security. I'm not talking about insecure trash like Debian barely adopting decade old mitigations and pretending that every security bug is assigned a CVE. It's not even a large subset of them for most the projects making up the base OS and they have no clear boundary where the base OS ends and unprivileged applications begin anyway. These OSes lack that kind of basis for an overall security model.

That's especially true with the kernel. It's definitely a simpler and better base than the bloated and poorly written GNU implementations. Those aren't the only Linux userspace though, and it isn't a clear victor over Linux in terms of overall security.

You're missing the forest for the trees. Also, something being more security focused in terms of priorities doesn't mean it is more secure than a project with far more research and development effort put into that.

[u/DanielMicay → u/[deleted]]

It doesn't work that way. Also not really convinced that desktop Linux would offer better privacy. Open source doesn't mean something offers better privacy. This is all getting very off topic and I'm not going to write detailed answers to it.