Android, iOS, macOS, and Chrome OS all provide a level of separation between user-installed applications and the operating system. The operating system may provide certain applications to the user, but those applications are not installed by the user and generally cannot be uninstalled or replaced. User-controllable applications are separated from the rest of the system, and generally are sandboxed to prevent them from doing damage if they turn out to be malicious or become compromised.
Debian (and by extension, Kicksecure) doesn’t do this so well. All packages in the repositories are essentially operating system components, with full permissions to do anything the user account the application is launched as allows. Core components like udev and systemd are installed directly alongside productivity apps like image viewers and web browsers. This is a bit messy from the standpoint of system organization, but it also poses a significant security hazard for obvious reasons (XKCD 1200 sums up the issue nicely).
Users should be able to install arbitrary applications as OS components and give them elevated permissions, as they’ve always been able to do on Kicksecure and Whonix. But users should also be able to wall off applications into a sandbox of sorts if they don’t trust those applications or may have to process untrusted data with those applications.
Flatpak and Snap are relatively well-known attempts at bringing sandboxing and application isolation to Linux. Both of these are not exactly awesome solutions, because:
Sandboxing controls under Linux can be somewhat flimsy without putting a great deal of work into doing things like whitelisting syscalls and the like. In some instances, Linux’s sandboxing features actually worsen security (user namespaces in particular allow access to kernel facilities that aren’t usually available to unprivileged users, exposing additional attack surface; this has been the source of numerous CVEs, but user namespaces are also required by applications that do sandboxing internally, like Chromium).
Users can loosen sandboxing very easily with Flatpak, and without too much effort with Snap, defeating the purpose of the sandbox.
Flatpak and Snap sandboxing oftentimes causes application malfunctions due to restricting resources that applications legitimately need access to.
Applications from the Flathub repository and Snap Store can be uploaded by arbitrary users. This is in contrast to the Debian archive, which requires some level of skill and trust for a packager to gain upload access to it, and where policies help to ensure better packaging quality in general. As a result, Flatpaks and Snaps are oftentimes more broken than apt packages, and it is easy to upload malware to the repositories.
Malware actually has been uploaded to the Snap Store and has caused severe damage in the past, with at least one person losing the equivalent of $490,000 after plugging in cryptocurrency recovery data into a malicious Exodus Wallet snap. This particular incident underscores the fact that sandboxing apps isn’t really enough, apps can still be malicious without having to break out of a sandbox at all. This same kind of attack happened on the Snap Store multiple times. This is why getting apps from a trusted repository is a good idea.
What we really want is some sort of virtual machine that is integrated with the host enough to allow apps in the VM to feel native or close to native, but sufficiently walled off so that applications cannot do damage to the host system or escape the VM. This would allow running “user applications” in a very tight yet highly compatible sandbox, and would allow pulling those applications from trusted repositories like the Debian repos. It would also allow users to install applications without having to boot into a sysmaint session.
Chrome OS has something similar to this with Crostini, and Windows has something similar to this with WSLg. Something with a vaguely similar user experience would likely be acceptable, especially if an “app store” frontend of some sort was available so the user didn’t have to use a terminal to install sandboxed applications.
Flatpak is also messy for other reasons. Unfortunately, not high quality packaging with the same standards and quality control as Debian. See: Flatpak
Some potential overlap:
Perhaps sandbox-app-launcher is promising?
It wouldn’t fully separate core system packages from user applications. Debian packaging maintainer scripts would still be trusted. During package installation, malicious or vulnerable Debian packaging maintainer could compromise the system. There are no history precedents in packages.debian.org as far I am aware, but still something worth mitigating.
Perhaps sandbox-app-launcher, if worthwhile, could install packages inside a per-application system chroot?
Yeah… containerization is so flimsy from what I’ve seen though that it seems like a dealbreaker to me. The limitations in nested virtualization scenarios aren’t really that bad since the user is already using virtual machines, they can use multiple VMs for isolation.
Being unable to use virtualized apps and VirtualBox at the same time is a real issue, and one that is very hard to avoid. Maybe it would be possible to allow the applications containers to function as either containers or VMs, so that one could use containerization when necessary, and virtualization when possible.
Incus considers container escape to be a security vulnerability: Security Overview · lxc/incus · GitHub It’s an LXD fork (developed by the original LXD developers), and might be more workable (maybe even more secure?) than bwrap. I believe it’s present in Debian Trixie.
I dont see the need to use virtualbox if we have KVM support. Virtualbox on gnu/linux is bad idea even more on debian.
So i see that this can be avoided by not having virtualbox consideration.
I think better to avoid the possibility to downgrade the model and allow application/s to use containers instead of being virtualized, because containers using the same system kernel will lead to bad results IMO.
We can’t really not consider VirtualBox - it’s the primary supported platform for Kicksecure and Whonix, and the automated installer will install VirtualBox and a Kicksecure appliance by default. It’s the Kicksecure platform. This is probably part of why the restrictions are a dealbreaker because of nested virtualization concerns (it will technically work but it will be painfully slow in many circumstances).
Containers using the same system kernel won’t be a problem if the same OS is being used both on the host and in the container, which we can do. The security concerns of containerization are still there, but if we use a mature containerization platform like Incus rather than trying to roll our own (which is what I think we were doing with sandbox-app-launcher in the past), that might not be so bad.
My first thought looking at this is that user account isolation sounds neat but will probably be difficult to implement. Lots of file ownership changes would be required in order to allow the user to get files into and out of applications. AppArmor doesn’t have a sandboxing feature like SELinux appears to, though it does allow enforcing MAC. Seccomp is unsafe, Android can get away with it because Google can enforce rules about how Android apps are written and we can’t do that with Linux apps. It also sounds like Android is using some sort of chroot variant possibly (or some fancy feature of SELinux) to limit host file visibility, which would further complicate things.
I guess it would be better than nothing though. I’m not sure if it would be easier to implement than using a containerization engine, maybe it would be.
(I don’t like sandboxing approaches in general especially without seccomp, since any LPE vuln in the kernel will allow a sandbox escape, and there have been many LPE vulns in the kernel as I understand it. Virtualization would make that much, much harder.)
These were periodic time choices, meaning in 2013~ there wasnt much of choices for new project growing up, coming 2025 this is can be considered from the past.
Switching to VM per app, this idea can even merge whonix into kicksecure, how? because what is whonix doing is taking OS in VM connecting it through another VM, what can be done on VM per App is that X app in VM can use Y anonymization app/s in VM or even GW in VM.
To have these genius futuristic ideas coming to true without having virtualbox on the other hand = Be it.
One possible argument in favor of the VM-based approach is that we could run “unsafe” apps in sysmaint sessions safely. We went to a great deal of effort to prevent people from launching Firefox in a sysmaint session because of the dangers it poses, but launching a virtual machine sandbox with Firefox in it would be much safer than standard or sandboxed Firefox. The inability to safely use a web browser in a sysmaint session is causing some frustration, and while we did see that coming and decided it was worth it, being able to remove that frustration would be nice.
Since Android is going for a virtualization based approach for some apps and since that’s more secure we might need to do the same.
Perhaps if running on a host operating system, we’ll use per application virtualization.
In case of nested virtualization (if we run already inside a VM), we’ll investigate that more. Provide a user configurable setting in that case perhaps. Or fallback to another solution (run without virtualization) because we’ll suggest to use multiple VMs.
We’ll need a separate ticket to investigate the security impact of nested virtualization. We’ll weigh it against running applications inside a VM without nesting.
That is, if even possible, such as slow performance making this infeasible.
Google dictates how apps must be built, packaged, and behave if they want to be distributed through the Play Store. Google can reject apps that don’t comply with sandboxing or violate permissions. Google Android developers have to use SDK and libraries dictated by Google.
Why we cannot do that on general purpose Linux distributions?
There is no central authority. Anyone can write and distribute a Linux application however they want. No organization (like Google on Android) can enforce mandatory sandboxing or privilege separation. More on organizational background: Linux User Experience versus Commercial Operating Systems
Right, and beyond that the Android operating system is designed in such a way where you fundamentally can’t just “do whatever you want”. The way in which the typical Linux desktop works, if someone needs root access and doesn’t want to prompt for it, they can just install a polkit configuration snippet or similar as part of the installation process, and get that access. With Android, not only can you not do that by policy, you can’t do that by design. Furthermore, we have to work with an already-existing app ecosystem with Kicksecure, whereas Android was free to make their own ecosystem from scratch. They don’t need to retain compatibility with anything if they don’t want to, whereas we do have to do that.