Short versus long term usage is irrelevant in this specific threat model.
Actually, quite a bit is persistent. See folder: /usr/lib/qubes-bind-dirs.d/
That ticket generally makes sense for defense-in-depth. However…
No. I guess you’re referring to this sentence:
In the Qubes case of using
sys-whonixfor hosting the tinyproxy, compromise of the Gateway means compromise of the user identity.
That’s a bit terse indeed. But the issue tracker is a tool for developers. It’s not a comprehensive threat model description. A compromised sdwdate, tinyproxy cannot connect to clearnet. There are additional security boundaries. These daemons run under dedicated Linux user accounts. The firewall restricts these accounts to be able to connect to localhost (Tor) only.
An additional SUID exploit against a privilege escalation tool (such as sudo) or kernel exploit would be required to accomplish clearnet access.
It’s not elaborated on the Qubes issue tracker for brevity as the decision makers (Qubes team) know this.
services do start in Template unfortunately. Qubes issue:
This is inherited by an unfortunate default by Debian.
sysmaint-boot.target results in starting a minimal amount of services in non-Qubes but this won’t work in Qubes yet. We might be able to use sysmaint-boot.target, where only minimal services are run, in Template, but that’s not clear yet. We might open a Qubes ticket / implement this.
We’ve already developed the passwordless-root command line utility (requires root rights to run, of course), but this isn’t as trivial.
The issue is that passwordless-root makes persistent changes, which would later be inherited by App Qubes. So anything passwordless-root does, would need to be undone at Template shutdown. But a systemd unit that runs at shutdown can be unreliable due in in theory software bugs (in the systemd unit or script). Well, these can be gotten under control. But if there is a power loss, the Template would shutdown without reverting the passwordless root changes.
Allowing account user passwordless root in Template could be implemented using non-persistent overlays or perhaps better using PAM.
Right, but user-sysmaint-split isn’t required for that.
Please elaborate if still applicable.
Quoting myself:
An additional SUID exploit against a privilege escalation tool (such as
sudo) or
This could be improved by making privilege escalation tools accessible only by account user.
user-sysmaint-split/usr/lib/permission-hardener.d/20_user-sysmaint-split.conf at master · Kicksecure/user-sysmaint-split · GitHub currently sets:
/usr/bin/sudo 4750 root sysmaint
This accomplishes No Access to Privilege Escalation Tools for Limited Accounts.
On Whonix-Gateway, a simpler implementation could be:
/usr/bin/sudo 4750 root user