Desktop Linux is insecure
bjornpagen.com
bjornpagen.com
The problem is nobody cares. Linux users don't care, and even the users of sandboxed OSes don't care. I'm more irritated by macOS constantly popping up with "iTerm2 wants to access your Documents folder" than comforted. Some distros implemented e.g. AppArmor to generally positive reviews, but Ubuntu's transition to Snaps has been seen very very negatively.
Wayland "features" some protections too - apps can't access the global clipboard, or move themselves, screen-record, whatever. And nobody likes it! Because the inconvenience far outweighs the benefits.
Overwhelmingly I think the "problem" is that Linux users don't really want, or need, this protection macOS/ChromeOS offers.
An aside: Windows has sandboxing? Where?
UAC is an operating-system-level system that heuristically detects when an executable is acting as an installer, and prompts the user with a Yes/No prompt (you can see screenshots online). This even works if you're running a terminal command. Terminal command needs administrator access? You get a blocking, modal dialog from the system that forces you to click Yes or No. That's very powerful.
Polkit is a component for controlling system-wide privileges in Unix-like operating systems, the manpage is less than 2 pages.
The problem is that apps can't request these permissions either, while they are absolutely critical for a select for apps so that a desktop environment can be used for actual work. It's just "use wlroots and figure it out yourself or tough luck"
Open Broadcasting Software works fine too.
Things are somewhat usable now thanks to this, but far from ideal.
...which is abstracted behind desktop portals, so applications like OBS or Firefox don't need to care.
Heck, glibc by default still allows LD_PRELOAD pretty much everywhere, and most distros have available SUID binaries you can hijack, so it's useless sandboxing anyways.
Setting aside the absurd amount of self invented config file formats for it (which have so many pitfalls for endusers) I think that firejail is the only viable alternative as a seccomp sandbox.
Flatpak's sandbox approach is as useless as AppArmor's approach, nobody can use it because the people that design it seemingly never use it in production apart from their www user test cases. If you try to sandbox a complicated program like Firefox with its hundreds of rendering processes, well, good luck...we'll talk two days later on how much progress you made just creating the config files.
I got so pissed by all of it that I started to learn eBPF to build a better sandbox, which I am trying to combine with a smart firewalling approach. But honestly, it's a ton of work, and the lack of profiles for everything makes it really hard to get to production.
You literally need to implement something like a "learning mode" that test runs a program, just to figure out what you want to allow or deny. This approach kinda worked for me, but I am now literally writing a DNS filter because resolv.conf as a concept is pretty much useless as well.
Once you start building something like this you see yourself 2 years later implementing all kinds of network services which in themselves are attack surfaces already...so you start to question whether it is really all worth it. Even hooking something as "simple" as DNS resolver API calls becomes a task that is a shitload of work until completed.
Common misconception, but no, glibc doesn't allow LD_PRELOAD on suid binaries.
Root is the one thing that's well-protected on linux, you cannot get root without the aid of a user giving it to you. Similarly, separation between users is also rather secure, but no desktop user is going to run each application under their own user.
I'll just leave this here then. [1]
> bypass local security restrictions in misconfigured systems.
"misconfigured" is a key here. Sure, people do occasionally make mistakes or bad decisions and introduce security vulnerabilities.. but that happens less often than you think.
gtfobins is pretty useless in regular server/desktop installs, at least for user permissions elevations. If user-to-root escalation is discovered with common config settings, it gets assigned a CVE and fixed, not listed at random websites.
It's not exactly expected that a local GIMP desktop install would provide reverse shell capability, yet here we are (https://gtfobins.github.io/gtfobins/gimp/)
https://devblogs.microsoft.com/oldnewthing/20230103-00/?p=10...
gimp is no more dangerous that any other scriptable app, like emacs, vs code, web browser, etc..
In my personal opinion, Debian/Ubuntu are the worst when it comes to security and maintenance. There are thousands of issues and CVEs marked as Fixed or Ignored on their security tracker which were not actually fixed but had a tag similar to the meaning of "code diverged too much from upstream".
A lot of PoCs that you can find on ExploitDB still work today, after 5+ years later, on an updated system. Especially the ones that are disputed CVEs where companies like SAP ain't give no damn about security issues (they have a dispute rate of exactly 100%, how can that be?).
Blaming misconfiguration up onto the End-User is not what I would do here, because it's the distribution that labels themselves as being secure/stable/whatever. If users use the default packages with no changes to configurations, I expect the distribution to provide sane and secure defaults.
If you argue that a "misconfiguration" is what makes a system vulnerable, then good luck finding a system that is not vulnerable - because there will be none.
Coming back to glibc and its messup when it comes to environment variables and parsing and linking issues: That was one of the reasons Alpine started its muscl library.
I mean, glibc is so ridiculous that you could get root privilege escalation via using the "ping" command up until around 3 years ago when distributions finally started to remove the SUID flag on the binary and instead use the network capability flags.
The latest example which comes to mind CVE-2023-22809, sudoedit bug. Out infosec department made a whole bunch of noise about it, forcing the upgrade all over the place. But this requires (1) interactive user (because sudoedit makes no sense otherwise) with no root sudo access (2) restricted sudoedit access. I am pretty sure our whole org had no machines with such config. First of all, in the era of VMs and cloud machines, the interactive users are admins, they are very likely to have full sudo. And if there is a task unprivileged user must do, it would be a web app or CI runner or a chat automation, not sudo-less ssh session. Second, if such user did exist (unlikely) and had a need to edit a non-owned file (even more unlikely), who would grant them direct "sudoedit" access? It would be a script which takes input file, validates, logs changes, and only then installs the new version.
I'd agree with you on one point: proprietary Linux software is often of horrible quality and I would not trust it. I never worked with SAP, but we have a proprietary remote desktop access app, and it's horrible design, with dozens of suid binaries, and insane authentication methods. I would not be surprised if it has a vulnerability or five.
As for the rest of your arguments, I believe you are simply wrong.
"If users use the default packages with no changes to configurations", the latest Ubuntu with all the patches will be secure. It is not hard to find a system which is not vulnerable - just regular Ubuntu LTS system, say default install + browser + emacs + some compilers, will be secure today (except for unpatched vulnerabilities, of which there are none at this moment; and unknown zero-days which no one can do anything about). glibc had its share or vulnerabilities in the past, but none in the last 10 years. The system defaults are generally secure (but not always sane :) )
If you disagree, please mention specific exploits/CVEs. As a part of my work, I spend lots of effort on keeping stuff secure, but the whole CVE/security scanner things are pretty much a huge disappointment.
Just coming across this comment, I would disagree with your assessment.
Most distros use systemd, systemd has a dependency on d-bus and to do many of the features their userbase expects, it relies on d-bus activation which reparent's processes under the systemd user in most cases via the dbus-helper which suid's. This process also breaks common admin utilities like tops and ps (they don't show up except under very specific views, like tree view). Importantly, these distros often do not have MAC configured with a safe baseline if at all.
To put it mildly auditing d-bus and activations of this sort is ridiculously obtuse from an administrative perspective. Then there's all the dated software which no one touches or views such as gsd-* that cause a fail-whale when disabled.
The way exploits work most times is by using a chain of exploits. You chain 1 piece to the next, to the next, until you get to a bug that gets you what you want and the attacker then hits paydirt. This is basic cyber-sec 101, I don't see why you would discount exploits just because you don't know how they can get to that point to use it. We work with a porous attack surface everyday.
Most distro's have system defaults which don't even include a basic endpoint stateful firewall. I would hardly call these distros secure (which is most of them). End users are not expected to have specialties in Cybersec, Information Technology or System's Engineering just to set up a out of box system that's secure by default, this is the responsibility of the distro publisher.
What does any of this have to do with LD_PRELOAD?
Wasn't that limit basically just a string match?
I.e. when you're allowed to do sudo abinary the whitelist will accept whatever is behind that string? So from what I recall, simply adding a new directory to the start of your path will let you execute your own script instead, giving you blanket root permission. Same with chroot on absolute paths, right?
In general, sudo is pretty good with single command grants as long as you use this on the scripts made for the purpose (like shell scripts which take no or a single fixed argument). But granting arbitrary arguments permission to a random system binary is a bad idea, something like --log-output might become an escalation.
(And unfortunately the default PATH means to of you want to sudo-exe c binaries from your user's bin, you need full path. I hit this all the time.)
Since Windows 8, WinRT applications are sandboxed.
It also has group policies and Win32 API that are used by the likes of Chrome for process sandboxing.
Deployments via MSIX packages also have a kind of lightweight sandoxing, as it builds upon WinRT, but on the classical Win32 side.
Now Microsoft is looking into bringing that everywhere, Windows 11 current preview already ships the first steps of full Win32 sandoxing being applied to classical applications, and on the roadmap application signing, with revocation of developer certificates, is already announced that is being worked on.
If you're a normal person, and get apps from your browser or any other store, yeah, no sandboxes there.
You can also install WinRT/UWP applications via MSIX, and they keep the sandboxing no matter what.
Their time will come and is exactly what is part of Win32 sandboxing currently in preview on Windows 11.
Long term roadmap UWP sandboxing model will be enforced on Win32 as well.
When you click the "Do you want to install a rootkit" button, yes it does.
But you can create a separate user and leave default one as Administrator. In system policies you can activate a rule where you don't allow users to become Administrator through UAC. And you can install steam as user without the service.
Users do get annoyed, but on the other hand: I am willing to bet, if you check statistics, that 99% of browser (and most other apps) users access folders Pictures and Downloads (and maybe Documents) only, ever. As for urls, every tab must be another sandbox-in-sandbox and by far most of them never need the access to Pictures or Downloads or anything else. So you can surely ask without annoyance. Now a site using assets from another domain are mostly ads, so just block it all and allow manual unblock per domain.
> There are a whole bible of strategies that ChromeOS implements to keep Chrome in it’s own little world. Among the strategies involve cgroups, namespacing, seccomp, etc… This technologies basically do what Docker does, but without the overhead of a virtualized Linux kernel
> Also, Linux desktop software has a very all-or-nothing approach to permissions. Root, or user.
[1] https://man7.org/linux/man-pages/man7/capabilities.7.html
On Linux I use my distro's curated repository (ex to install cozy, an ebook reader, or yt-dlp), I don't care that it has access to the rest of my system, the bonus point is that I can have access to its source code. On Android, the first app I see has "In-app purchases" and will probably spy on me. Yes... I agree I guess, on Android (therefore ChromeOS) app stores I definitelly want sandboxing because it's a very adversarial relationship between the users and the apps.
Unfortunatelly that means you need to get into sandboxes, throw stuff in VMs and all the other things that will make performance and efficiency suck.
I miss the time where my computer ran only software I controlled and it wasn't a free for all where everyone wants to run random code (Javascript from websites is a big one here). All the Specter/Rowhammer stuff is only because you're sometimes running untrusted code. Why do people need to be running untrusted code all the time? /me goes back in the cave
Let's just accept the fact that Linux comes from a place of "if you run a program you are responsible for what it does". This is contrary to modern users expectations of "just because I run a program it shouldnt be able to siphon all my data", largely driven by mobile apps and their ecosystem.
If I autocomplete an ls command on my Mac's terminal it will warn me that iTerm is trying to access the specified folder. There is nothing like that on popular distros. The whole security landscape needs to be re-thought.
Maybe someone who knows more than me can talk about bring features from more restricted Linux variants to a more broad audience.
Safety in this case is not provided by physical distance between homes but by curation of software done by nonprofit groups and selection of nearly only open source software with easy building of packages and tracking of changes in the source.
> Did you compile them yourselves? Did you compile the compiler?
There's no such thing as perfect security, and I think you know that. If you think your compiler may be compromised, there's stuff you could do, you just have to evaluate where the paranoia starts and stop before then.
Let's not pretend that just because there's a sandbox at a higher level of the stack and some kind of user ability to accept/deny operations that things are secure.
Do you trust trust? (And no differential compilation isn't an actual solution.)
Are you actually reading all the code before you run it? Are you re-reading it for each update? If not, then what's the point of bragging about having access to the source?
The point of sandboxing is that it's impractical to reliably audit, on a continuous basis, the massive volume of software that the average person runs. It's more economical to apply the least-privileged principle, and only give apps access to the things they need to function.
Not every user needs to read everything. We can read pieces of what we use and trust others to also read pieces of what they use. We can also place some amount of trust that there's a body of people that have read code before we started using it, and that it's only the new changes that need the more review. People can also use reputation to make safety in review more economical.
Sandboxing is not bad, but it's not the only way that security can be achieved. Having a good social infrastructure also helps.
I still believe that having the code available for review is important, but I don't think it's a reliable means of saving people from insecure or malicious software.
Just having the code available, in and of itself, is probably not. However, the presence of the source is not the only thing you have to provide reliance. For Archlinux, for example, different package repos have different requirements and provide different levels of safety. You can put more trust in packages in core than you can those in extra, and you can trust those in extra more than you can those in the AUR. Anyone can push packages to the AUR, and so can they to other package repos like those of different languages (rubygems, hackage, etc.). Different languages will have different communities and you can get a feel for how trustworthy they are as a whole, based on their requirements, etc. This is like the difference in safety in different cities. You can check the author and get some kind of idea as to how much reputation they're holding. You can also check the package maintainer and get some kind of idea as to how much reputation they're holding. You can check how many other people trust that software, and if there's any particular notable ones. You can see how well established and widely-adopted the development process is formulated in the homepage/github/etc. You can also review the source yourself, and even if you're not some security expert, that doesn't mean your review is absolutely worthless. It's got a score. Put a score on every source of trust, add them up, and check with your risk tolerance.
You don't need to do everything. If I decide to walk on a street, I'm not checking the crime statistics there, the internal state of the nearby police department, etc. I'm mostly deciding based on the city/neighborhood I'm in, how populated the street is, the state of the people there at a glance, and that's generally more than enough for most people.
> but I do sometimes wonder how many open source products have never been read by anyone outside of the people who wrote/maintain it, and for those projects where anyone has reviewed the code, how many of them were really qualified to understand what they were seeing?
In case my point was lost in my ramble, you don't have to base your decision on trusting a particular piece of open source software based on how much you trust the whole body of open source software in existence. You can decide to e.g. trust the official repos of a distro based on how that curation works, so trust the packages in it and not the software outside it (e.g. the AUR or random Github repos), and you can decide to trust based on other signs of your choice like that, too.
There have been plenty of malware on perfectly open source and often reviewed repositories.
This is not true of android and ios.
I would challenge the author to explain why is the extra layer of sandboxing a must requirement. Do we know the size of the problem? As in... how many known websites run malicious scripts with real intent to do harm, and how many sites achieve that goal?. Do we know how many users got hacked because the lack of sandboxing in linux when doing typical web browsing?
My view is that the article blows the problem out of proportion. Security relies to a great extent on user behaviour.
User A visits known domains only, and opens emails from known senders only. They only share card and personal details with known and trusted parties. They only install the strictly necessary apps and from known devs only.
User B visits any site regardless of domain. He shares email, phone number and card data at the earliest chance (ie when trying to buy illegal drugs from a clearnet shady store). He installs dozens of apps, often from unknown parties.
Regardless of OS, browser and other context, user A is going to be safe most of the time and it's very rare that they in serious trouble. User B is an accident waiting to happen...
If the above is true, maybe we don't need a technical solution like OS sandboxing. It would be more effective to create a standard for all browsers where the first screen you see is a big message saying: "Welcome to your 3 second online tutorial: Visit known websites where possible. Don't share your real personal details unless strictly necessary. Share details with known and trusted parties only. In case of doubt, don't trust the other party."
Seeing questions like - I was traveling and have a huge bill on internet traffic, I wasn't downloading any movies just watched them online, why you charge me? - gives me personally good portion of understanding that users can't be relied on and need accoring guidance.
User behavior is unreliable. We're moving from passwords to passcodes because of how poorly we're picking and using passwords.
> User A visits known domains only, and opens emails from known senders only. They only share card and personal details with known and trusted parties. They only install the strictly necessary apps and from known devs only.
It's not enough these days. Known senders can be compromised and send spoofed messages. Supposedly trusted parties have data breaches. Supply chain attacks target known devs, like SolarWinds.
> user A is going to be safe most of the time and it's very rare that they in serious trouble.
Security is about adapting to emerging threats. Threats that were rare before become widespread, especially if they work. Based on what I've seen it's already happening.
Sandboxing and capabilities seem like a step in a right direction. In any case, on a machine and an OS that you own and can modify, you could disable it if you desire. Just like you could disable a firewall.
> It would be more effective to create a standard for all browsers where the first screen you see is a big message saying: "Welcome to your 3 second online tutorial [...]"
If all that it took to train users about online safety was a brief pop-up, we wouldn't have security problems. Yet here we are.
It would have the same effectiveness as cookie banners, consent pop-ups, terms-of-service checkboxes, and are-you-over-18 buttons. None for the users, but someone will keep their hands clean.
Unfortunately, Achilles heels of ChromeOS are in the usual places: browser extensions and integrations that can access any web page you view, or do anything they want with your Google account, which can wreak havoc for people with a lot of stuff in there.
Now what I will say for consumer Linux distributions is that it's eminently possible to easily reduce your attack service in a few ways: judicious configuration, and strip down all unnecessary software packages! I was sysadmin for a long time before I realized that I was a glutton for apps and I had a tendency to consume them and hoard them without regard for what I really needed to run on a day-to-day basis. I would install software, try it once, and finding it boring, I abandoned it, but it was all still installed.
So I began perusing my list of installed software and I'd just remove anything that was obviously unnecessary. I'd even remove stuff that I didn't know what it did, just to see if something broke, but things rarely broke! My position was validated!
If you remove unneeded software, you will automatically reduce the number of network services running too. That thing you installed probably started up a server, started listening on local and global addresses, and may have even poked holes in the firewall for itself. Do you need that? Can someone make a lateral move from your pwned router into your desktop machine through your neglected services? Get rid of them.
Linux affords much more latitude to a security-minded administrator than Windows. Windows will not let you turn stuff off without causing breakage or it will just gratuitously come back in an update and be turned back on. The Linux philosophy is beyond that nonsense.
Yes, Linux out of the box, or Linux in the hands of an ordinary end-user, it's insecure. But it has more potential than Windows.
For a while, I pondered whether I could outsource my personal, home IT work to an MSP. But MSPs don't do personal networks, they do B2B. I think Geek Squad is possibly missing a bet here. Not that I would let Geek Squad into my Linux homelab, but it's a thought.
The question is what can I do about this?
A browser sandbox escape would be red-alert news and fixed within hours.
That is totally false. Any good web browser is asking for permission first.
Hilarious though that the author thinks is Nix is “imcomprehensible”. You can even do things like nix shell nixpkgs#proprietary-crap and ditch the application after using it to do one thing.
But also included in the threat model is what you want to protect. Obviously bank passwords, tax information, etc, but I also want to protect my privacy in general, and right now there's no OS that's as privacy preserving as Linux. Furthermore, I don't trust sandboxing implementations in proprietary OSes from protecting my privacy either: they might say they protect my data against malicious apps trying to steal my stuff, but then if the OS itself tracks my location, search history, files, etc, sandboxing doesn't do much good, does it?
This is less true on mobile because people use lots of apps there. And if you have some game implemented by a twelve year old and somebody hacks it and then installs whatever on the phone, that is a big issue. So Google and Apple spent a lot of time fixing that on mobile and then applied the same level of standards to their desktop operating systems. MS has of course over the years had their fair share of issues like that so they've gotten a lot better at this as well.
Server side linux is pretty secure out of the box. Pretty much the whole internet runs on Linux at this point. Mostly servers only run one process that matters; which is whatever they are serving. Or a bunch of dockerized processes in some cases. Which are indeed sand boxed.
Desktop Linux is server side linux with some extra stuff. Not a very homogeneous target to hack because there are lots of different software packages that people use in different combinations and versions. And the baseline security of Linux is of course not horrible like it used to be with Microsoft.
And of course things like snap and flatpak actually do use some sandboxing. So, use that if it makes you feel good. Of course that sandboxing isn't perfect as I'm sure people will be itching to point out. But the problem that addresses is pretty minor to begin with. And there is of course a certain amount of resistance against using either of those with some people.
So, not much of a problem and it's been kind of solved anyway.
For the most part we no longer share computers.
We used to be constantly confronted with poor security practices: someone else accessing a file they shouldn’t, or installing some piece of software that took over a system function as a prank, or just miseducation leading to a critical config problem.
I don’t know who set the wheels in motion first (though I suspect it was game makers) but we now have complete sovereignty over our devices and therefore only really think about security against internet intruders. Imo this leads to a much more abstracted and relaxed security mindset overall (including in the minds of the devs).
Even simple things would go a long way like making it straight forward to install packages from distro repositories in userspace. Every time you install a desktop app via the package system you're rolling the dice by giving the package root access. In fact that should be the default behavior for installing the vast majority of Linux apps. If an app doesn't legitimately need root access for anything we shouldn't grant it to begin with.
Don't get me wrong Linux distros do a great job at maintaining security overall but these projects are massive now and in the age of supply chain attacks and hostile nation-state actors all it will take is one package to slip through to cause a major security incident. The Solarwinds hack was the proverbial canary in the coalmine. If it can happen to them it can happen to anyone. It's not a matter of if now but when.
Systemd:
$ # I use silverblue btw
$ THINGS='Protect|Restrict|Capability|Lock|SystemCallFilter|Private|MemoryDeny|ReadWritePaths'
$ AT='/usr/lib/systemd/system'
$ grep -ilE "^($THINGS)" "$AT"/*.service | wc -l
64
$ grep -ilE '^Exec' "$AT"/*.service | wc -l
292
"and it certainly isn’t as comprehensive as ChromeOS’s minijail." Kinda disagree.
- - -
Lot of words, no citations for those words.
- - -
Worth noting that, even among secure options there are points where there is slack: Android uses a uid/gid per app [auid], but chromeos doesn't [cuid]
[auid]: https://android.googlesource.com/platform/frameworks/base/+/...
[cuid]: https://chromium.googlesource.com/chromiumos/overlays/eclass...
Anyway, that's also something I've been thinking lately after distro hoping for about 6 years... My average Linux install isn't particularly more secure than Windows. I'm mindlessly sudoing my way through stuff all the time. Clearly there is a Linux malware market to be explored.
we need more little snitch like things, including for filesystem access.
we also need the ability to run little snitch in paranoid mode, where the approvals happen on a separate device, sign each message with a key not on the primary device, and the validation is baked deeply and irrevocably into the kernel. smartphone face up on desk left of keyboard would work well for a second device.
linux lsm seems to work[1], and building the kernel is easy locally[2] or on cloud[3].
hopefully we see more and better use of lsm and custom kernels. we all should want our most trusted public key baked irrevocably into the kernel.
personalized linux is the next frontier!
1. https://github.com/nathants/mighty-snitch
2. https://github.com/nathants/mighty-snitch/blob/master/kernel...
3. https://github.com/nathants/mighty-snitch/blob/master/kernel...
It's called QubesOS.
It's, if not an operating system directly, then a meta-operating-system and set of tools to allow you to easily interopreate a range of siloed VMs on top of a stripped Xen hypervisor. You can easily create, destroy, and use VMs, which can either be fully standalone, fully disposable (no disk state persists past the reboot), or, in the usual configuration, have a persistent home directory and template-based ephemeral root directory. Perks of that, you can update the template VM (via some reasonably thought out methods) and update all the software in the derived VMs as well.
I've been using it as my primary desktop OS now for... oh, two years and change, perhaps? It's a bit like a virus, in a way - you install it on some random test machine, get a feel for it, and then install it on more machines, and it just kind of spreads around your network until you realize you've been working in Qubes for some while now and it's fine.
The security model is basically, "Anything in a VM can be assumed to access anything else in that VM." So you silo things off, and if you're doing anything with unknown data (random PDFs, perhaps), you open it in a disposable VM (and there are some neat "render safe" capabilities that will then provide, back in your trusted VM, an image based version of a PDF file minus any bonus capabilities it might have come with). So you silo things. For instance, I do most of my "casual web browsing" in a disposable VM and I reboot that regularly. A full compromise of that browser stack gets you... the other tabs I have open, and perhaps a random file or two I downloaded. It doesn't get you anything of interest, as I also don't log into core accounts in that browser (I have another VM for core web activities that doesn't visit random sites).
The main downside is no GPU acceleration of anything (framebuffer only), but it's somewhat less limiting than I'd assumed, and most of my machines maintain a dual boot of Ubuntu for anything GPU intensive, though I honestly use it a lot less than I'd assumed.
And while it sounds like it would be resource intensive, and it can be, it's worth trying if you have less RAM than you might think. My "daily driver laptop" is a 2C/4T 5th Gen i7, with 16GB RAM. Gutless wonder, and I didn't expect much out of Qubes on it, but it actually works just fine (though I admit I'm not nearly as hard on computers as I used to be in terms of what I expect out of them).
Clipboards are mentioned, and Qubes neatly solves that too, because you have separate keyboard shortcuts to move clipboard contents around - it's not hard to copy/paste between VMs (or move files between them), but "root in a VM" only gets you things pasted into that VM (unless you pop Xen and migrate to dom0, at which point it's rather game over, but... theoretically, that's a harder exploit chain than getting out of a browser).
Also, as far as browser go, disable your Javascript JIT engine. No, I did not say "Disable Javascript." I said, "Disable your Javascript JIT engine." There are ways to do it on most browsers, and in exchange for slightly reduced daily performance and slaughtered Javascript benchmark performance, you remove an awful lot of complex attack surface in the browsers.
My problem with containers and sandboxes is that they rely an awful lot (entirely?) on the Linux kernel not being able to be exploited, and my general assumption for years now is that a local root exploit is worth about $0, because they're reasonably common and easy to find. It's not exactly true, but it's closer to true than not, so I assume any arbitrary code running on my machines, if it so desires, can compromise the kernel. Sandboxing and containers are convenient to prevent well behaved application deployments from interfering with each other, but they're not sufficient against potentially malicious applications. It's a pessimistic view, but the last decade of computer security is pretty clear that the pessimists a decade ago were far, far too optimistic.
Anyway, long post, short summary, "We probably shouldn't have put computers in everything."
You are effectively making Qubes useless. The presence of any software that has access to the EFI partition outside Qubes renders it a highly vulnerable entry point for any form of malware, as it gives direct access to Xen.
Let not the perfect be the enemy of the good.
There’s really no reason why a system upgrade requires root privileges,