phones are the most sensitive devices we own, and should have the tightest security. We’ve see android fail in its compartmentalization many times, to say nothing of its built in limitations.
as a result, malware sneaks into the android play store so often, its become an exercise of bored tech writers to troll them by doing it intentionally so they write some click bait about it.
Since your playing apple with this this phone (designing the both the hardware and software) and have experience with qubes, why not go in that direction? or, at least something like that under the hood. the design of xen on arm is cleaner than it is on x86. but, failing that, you could at least have containers emulating a full os so users can partition things and try apps, or even open a pdf or movie, without less chance of compromise.
Running Xen on ARM is quite efficient. The only thing you really need is a lot of memory. The CPU is not an obstacle. However, having non-free drivers is a problem is such a case, especially closed source GPU drivers. But lucky for the free and libre software community Qualcomms Adreno graphics cards are supported by the freedreno driver. NXP’s Vivante graphics cards would be another option. Vivante graphics cards are supported by the etnaviv open source driver.
ARM Mali GPU’s are a terrible choice, they are completely closed source and non-free. This will not change in the near future.
The main problem however in developing such a solution is, that it takes a long time and it is costly.
This could be an interesting capability but the interface would need an awful lot of work. Qubes is designed for desktop use.
I have a Blackphone currently which uses the Spaces app on an android-based system to do some extra separate of data access to various apps. It works more like a container or jail than a virtual machine. Some capabilities like calls or GPS can be locked off but it inherits base system updates and apps. There are more fiddly bits I’m not mentioning but that gives you a rough idea. And it’s easy to swap back and forth between them, which can double as a start/stop of that container.
I think if any full VM or container solution were implemented it would have to be about as easy to swap back and forth. The user interface is going to make or break anything like that much more than any technical considerations.
Until proven otherwise, I presume QubesOS must have a huge overhead beyond RAM usage. So out of sheer curiosity (I don’t have the answer nor the time and skill to find it at the moment), has anyone done some serious power consumption and battery life benchmarks on QubesOS vs a non VM-containers-based OS like PureOS/Debian/Fedora/etc.? Applications launch times, too.
I was also concerned about battery life, but given how much better batteries are now, i wasnt sure that was still an issue.
the more practical solution in terms of battery life and development costs, is containers. probably lxc, with a move to xen later on. but can containers use the iommu? can you pass the gsm to its container, the wifi to its, etc? there may be other ways to protect against malicious devices, but qubes already did the work here too. even without all that, a fatter host system, this would all still be a win.
qubes made their libraries adaptable to different back ends, so those could be used with a more appropriate gui. it may be overkill for simple containers.
to address the interface issue brought up above, os x uses four finger swipe to switch virtual desktops and full screen guest vms. this, or maybe a 3 finger swipe for people with less fingers. the android conventions could work within individual vms. a more qubes like model where apps get their own windows, bordered to tell you which vm they’re on would be great, but would likely be more engineering work and more confusing for users. instead, i think it would be better to have a border color around the whole display, or maybe just one border for “full screen” apps, so they cant ever fully violate that. think this part should be brainstormed a bit.
after thinking about it, i realized there are, among the nice to have, two more practical things im after.
one is a sandbox for opening files, like images, movies, or the scary ones, PDF! (insert dramatic music here)
the other is persistent sandboxes for web browsing. so, the browser should not be able to write outside its own little space, in either memory or storage, though the user of course, should be able to easily. and, the browser instances should not even be aware of each other. by persistent, you could have one, for example for your work, and it would keep all its settings, downloaded files and whatever else. for your work another for shopping, etc.
this way, you can get to any site you want, without worry about malware unless the attacker happens to have a working attack on the browser, sandbox, and phone.
this is seperate from an app having specific permissions, though that should be a thing at the same time. id love to see something like an overall file manager, and apps only being able to write to their own space, or shared ones you designate. or maybe something like os-x where an app can call finder and the user is allowed to feed that app whatever they want. enforcing this with a namespace would be that much less attack surface.
if these phones are running pureos, is the above already possible?
Yeah, I think developing Qubes to work on a phone would be an immense effort. In addition to the fact that current phone hardware just wouldn’t quite support it, you’d also have an immense amount of UI to code. Qubes is currently very architecture-specific (x86_64) and UI-specific (XFCE or i3, maybe KDE; GNOME doesn’t even work yet).
I would really like to see the Purism phone run CopperheadOS, however. It seems to currently be the best-of-breed secure phone OS. It’s a hardened, libre version of Android: https://copperhead.co/android/
Its the compartmentalization and integration that i want. i only said qubes to quickly get the idea out of where i was going with it. i agree that qubes itself would be too much overhead.
android is pretty close to this already, but that final push would be a lot of work. pureos could probably be adapted more easily.
copperhead os is a better version of android, but doesn’t have the level of compartmentalization mentioned above. i like the idea of it. but, i think it should be folded into the aosp instead of being a fork.
I really think the Librem 5 should be able to “sandbox” all and every app in the system, and that the “sandbox” should apply to the internet access from the app as well. I mean, if I’m using an app from a third party, I really want to deny internet access to it, unless it’s an app that really requires the network.
If I cannot deny internet access selectively to all apps except the ones I trust, then a hardware switch for internet is of little use.
PureOS being a linux on which you have full access, you can use iptables to filter access to the network for applications, without the need of sandboxing.
What you had in mind might be a user friendly interface for iptables?
Maybe. What I’d want is that when you install apps, the internet access is disabled by default. And then, when you run the app, you got some popup like on iOS, telling you “The application ACME-Camera wants to access the Internet. Do you grant permission?”. Then of course, you should be able to change this setting later, for example some GUI where you have a list of apps with granted or denied Internet access and you can change it at any time.
Also, a more fine grained control could be very useful for some apps. For example, maybe it could be very useful to limit the sites or IPs that a given app can access (for example, you want that a maps application accesses the maps server and only that server). But that could be done in an “advanced Internet settings” option for each app. Most of the times you won’t need such fine-grained control, only an all-or-none Internet access for each app.
I’m a long-time, full-time Qubes user myself and I too have thought about how cool it would be to have Qubes in a phone form-factor, but putting all of the UI issues aside (XFCE is not phone-form-factor-friendly), it’s not going to be possible. Unfortunately Qubes is x86-only, so even if the phone had the horsepower and extra RAM to run it, there’s no build for the CPU architecture.
What we are aiming for instead is for the Librem 5 to get PureOS closer to Qubes-like functionality through technologies like flatpak and bubblewrap. As we get good sandboxing rules and templates in place for applications on the Librem 5, the adaptive design of these applications means we should be able to make desktop PureOS more Qubes-like as well.
For instance, I’d love to have a disposable browser in the Librem 5 (and desktop PureOS) that behaves like the disposable VMs in Qubes. The browser is one of the bigger security and privacy threats on a computer and it would be nice to not only isolate it in a disposable sandbox to protect from attacks, but also make it disposable so there’s no persistent data for websites to capture.
Possibly, but ideally I’d like to stick with one solution that we’d use for everything, so we can more easily reuse code/configuration. Bubblewrap seems to be the popular choice for flatpak.
I believe that you can create a firejail profile for any program you want. Parrot os (a kali-like security os) uses it quite a bit, if not for everything.