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.
While there are technically speaking VM solutions for both x86 and ARM platforms, they are also behave differently and are configured different, from my understanding (but I don’t have a lot of experience with virtualization on ARM so I could also be mistaken). I’d prefer an approach that we can easily use both on the Librem 5 and the Librem laptops.
@Kyle_Rankin The one quick solution fit all is exactly what firejail is providing. No VM, All security features are implemented directly in Linux kernel. By contrast, Qubes uses a “Type 1” or “bare-metal” hypervisor called Xen
The same hypervisor mentioned in my post about bromium above.
I think firejail is definitely the simplest/uncomplicated way. Currently maintained.
For purism that means much less work and overhead as you only need to provide the preinstalled binary and let users run their apps through it.
When I’ve tested firejail on the Librem 5, it seems to exit without any error output. Even stracing didn’t enlighten me on why. That said, I’m exploring a few options for sandboxing at the moment. The approach I’m leaning most heavily toward right now would involve a combination of bubblewrap backed by apparmor. Apparmor would be re-using existing profiles for an application so even if bubblewrap rules missed something apparmor had, you’d still end up with protection at least as good as apparmor by itself. I think this is important because you don’t want to risk a security regression by using bubblewrap rules that aren’t as advanced as their corresponding apparmor profile.
I’m an app developer, so that’s my viewpoint. I sincerely dislike the imposed restrictions by android and iOS and I usually prefer developing for the web because of a little bit more freedom.
And these ineffective restrictions only hinders what we can do and pasteurizes the whole array of apps that would be possible to be create and only allows for CRUD apps like instagram and whatsapp that captures some input, send to a server and brings data from a server to be displayed.
What has an appeal to me on starting developing linux apps is that I can do anything, no restrictions, so if I want to create something different from a pasteurized app I will be able to.
Are there other approaches to security that do not rely on plastering the app developer?