Advanced users, developers can help with that. It starts by describing the issue reasonably well to raise awareness, to enumerate all attack vectors and proposing solutions.
Other operating systems (Android?, iOS?, …?) don’t seem to have this issue. Why? Why is it an issue for Linux desktop distributions? What has to happen to fix this issue for Linux desktop distributions?
Perhaps a restricted shell (that actually works) that or safe-mode that doesn’t parse ~/.bashrc etc. And/or a desktop environment that has a safe-mode that doesn’t parse ~/.config/autostart etc. or at least has detailed documentation on all of the files/folders that might be vulnerable to persistent malware.
Even if subscribing to a passwordless sudo threat model / viewpoint, not logging in as root has reasons. Not security reasons.
This is for reasons of history, legacy. Even during the times of X11, root login was frowned upon.
In result, some applications such as kate have even hardcoded (non-configurable) code to outright refuse running as root.
At time of writing, when opening a Qubes root console (dom0: qvm-run -u root vmname xfce4-terminal), it is not possible to start GUI applications by default. (Maybe fixable by some xhost commands, but undocumented and non-trivial for most users.)
Since changing all applications that - maybe for the wrong reasons - refuse running as root is infeasible, under this threat model using a non-root user with passwordless sudo would still be better for usability reasons.
Related ticket:
A user to root local privilege escalation (LPE) exploit is out reach for many actors.
For example, there are many Android devices where users are suffering from Administrative Rights Refusal which have never been rooted despite large community interest. This also goes for set-top boxes, iPhones and similar devices.
It’s futile to argue that non-root enforcement cannot improve the security of the system (in case of Qubes, of an App Qube).
Non-root enforcement is the industry standard for Android [1], iOS and any locked down Linux based operating system.
In other words, root exploits are often unavailable for long periods of time for many actors.
Impossible to break? No. More complicated, more expensive? Yes.
This is also arguing kinda “we cannot prevent root local privilege escalation because the kernel is bad, therefore let’s be lazy and don’t even try to secure the user space”. Maybe the Linux kernel is horrible. But then then still, focus is required. Fixing 1 issue at a time. And sudo/permission hardening; making sudo available/unavailable inside a VM as a simple dom0 VM settings checkbox s within reach.
LPE is an issue but there are people working on improving the security of the kernel. They might fail or succeed. Or other people might even one day manage to provide a usable alternative kernel with no or less LPE issues.
We should disallow one issue (kernel LPE issues) to block progress on sudo/permission hardening.
This can be done using /rw/config/rc.local other mechanisms such as a systemd unit that runs a script which only does only perform actions based on the VM name.
I am also very interested in and working on finding these issues, reporting actionable tickets with the goal of getting these issues fixed, and developing Open Source code to fix these issues.
Ideally, there should be no SUID binaries reachable from the user account, as otherwise significant extra attack surface inside the VM is exposed (dynamic linker, libc startup, portions of Linux kernel including ELF loader, etc.)
that has resulted in the creation of SUID Disabler and Permission Hardener, among many other discussions which I am working through, attempting to fully wrap my head around this issue. This is documented here:
I opened a new ticket just recently.
I think we’re getting close to describing all the issues, (We don’t know what we don’t know.)
And as for fixing these issues, we’re also making progress with that. (Except for kernel attack surface.)