create user admin by default and add user admin to group sudo by default

[adrelanos]

The problem you're addressing (if any)

When removing the qubes-core-agent-passwordless-root package (to develop towards strong root/user isolation), the suggested way to gain administrative rights in Qubes is to run in dom0 something like qvm-run -u root vmname xfce4-terminal. This is problematic.

Why not use root?

• root cannot open graphical applications such as graphical text editors (for configuration file editing).
  ** Maybe X11 can be hacked with a ton of environment variables to workaround this. Maybe even Wayland. But it's non-standard and an uphill battle.
  ** Some applications such as kate have even hardcoded (non-configurable) code to outright refuse running as root.
• In App Qubes, root does not have a persistent bash command history because its /root/.histfile is stored in Qubes root image.
  ** As a result, lengthy commands such as http_proxy=http://127.0.0.1:8082 https_proxy=http://127.0.0.1:8082 flatpak update are lost from the history and need to be re-typed (or copied from somewhere) every time.
• root has no bash completion by default, which requires even more typing.
• Only the action that really requires administrative ("root") rights should use these. Everything else, should be done by a non-root account, even if an administrator with sudo access.
• Conventional wisdom "do not login as root".
• Best security practice. Once/if centralized logging is supported (logvm(s) #830) it's best to use sudo to have an audit trail.

The solution you'd like

Create user admin by default and add user admin to group sudo by default.

The value to a user, and who that user might be

Fixes all issues mentioned above under "Why not use root?"

Completion criteria checklist

[marmarek]

• root cannot open graphical applications such as graphical text editors (for configuration file editing).
  ** Maybe X11 can be hacked with a ton of environment variables to workaround this. Maybe even Wayland. But it's non-standard and an uphill battle.
  ** Some applications such as kate have even hardcoded (non-configurable) code to outright refuse running as root.

This isn't "root cannot open", it's "any user other than user cannot open", because X server is running as user. So, using admin user doesn't really help here. If anything, it makes it even more complicated, because root can access X11 socket just fine (but may need some extra env variables and maybe xhost setting), while another non-root user will be prevented even from that by file permissions. Same applies to dbus session bus and few others.
And BTW, most issues with graphical applications as root are not due to actual X access, but all the other stuff like dbus services, xdg portals etc. Separate user would need them separate for any kind of user separation, but those running as another user than the graphical session would not work in many cases.

And also, if you remove qubes-core-agent-passwordless-root, you probably want separate user/root accounts. But running graphical applications on the same X display defeats this separation, as any process running as user could now interact with your admin/root's application too (like, inject keys into terminal or so). It will be a bit better with Wayland in VM (at some point in the future), but still not great.

For more in-depth analysis see #2695 (comment)

A more practical approach is #9512 (or rather #2695 as a more specialized mechanism) and use sudo to call applications (with either confirming each time, or switching the setting for the time you need it). Normally sudo should preserve relevant env variables for the application to run. A graphical application running via sudo can still be manipulated by a normal user process, but that applies to other options proposed here too. On the other hand, using sudo for specific commands avoids other issues like lack of command completion, or lost history. And avoids running too many things as root. BTW for graphical editors, you can run them via sudoedit (for example EDITOR=kate sudoedit /etc/...) - this way the actual editor is running as normal user without issues, but still can edit root-only file.

[adrelanos]

• root cannot open graphical applications such as graphical text editors (for configuration file editing).
  ** Maybe X11 can be hacked with a ton of environment variables to workaround this. Maybe even Wayland. But it's non-standard and an uphill battle.
  ** Some applications such as kate have even hardcoded (non-configurable) code to outright refuse running as root.

This isn't "root cannot open", it's "any user other than user cannot open", because X server is running as user. So, using admin user doesn't really help here. If anything, it makes it even more complicated, because root can access X11 socket just fine (but may need some extra env variables and maybe xhost setting), while another non-root user will be prevented even from that by file permissions. Same applies to dbus session bus and few others. And BTW, most issues with graphical applications as root are not due to actual X access, but all the other stuff like dbus services, xdg portals etc. Separate user would need them separate for any kind of user separation, but those running as another user than the graphical session would not work in many cases.

Right. So all of these services X11 (or Wayland in the future), dbus, xdg-portals should be duplicated under a different user name (in this case "admin) too separately. This is how it's done in other Linux distributions.

And also, if you remove qubes-core-agent-passwordless-root, you probably want separate user/root accounts. But running graphical applications on the same X display defeats this separation, as any process running as user could now interact with your admin/root's application too (like, inject keys into terminal or so). It will be a bit better with Wayland in VM (at some point in the future), but still not great.

Right.

• Let's forget about X11, assume Wayland will arrive one day in Qubes.
• No longer hardcode user user. Duplicate services (Wayland, XDG, ...) for each user (similar to how other Linux distributions do it)?

For more in-depth analysis see #2695 (comment)

I have been reading that and other comments many times with great interest and I think all of these points can be addressed.

For example, quote:

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.)

In response, SUID Disabler and Permission Hardener has been implemented.

A more practical approach is #9512 (or rather #2695 as a more specialized mechanism) and use sudo to call applications (with either confirming each time, or switching the setting for the time you need it). Normally sudo should preserve relevant env variables for the application to run. A graphical application running via sudo can still be manipulated by a normal user process, but that applies to other options proposed here too. On the other hand, using sudo for specific commands avoids other issues like lack of command completion, or lost history. And avoids running too many things as root.

A graphical application running via sudo can still be manipulated by a normal user process,

Right. That's why ideally in the future, at least security conscious users, will avoid user user to run sudo su. The only exception maybe should be some /etc/sudoers.d NOPASSWD exceptions. That's why I recommend the user versus admin separation.

but that applies to other options proposed here too.

I've researched and documented Strong Linux User Account Isolation in detail. If user admin was completely separate (X11/Wayland; XDG, ...) and user user wouldn't be a member of group sudo, what's are the remaining vulnerabilities and can we mitigate these? Ticket?

It's doable. Other (unfortunately less user-freedom motivated) operating systems such as Android, iOS managed to implement a pretty solid Administrative Rights Refusal (non-root enforcement). Strong user/admin separation can be implemented in Freedom Software Linux distributions too, while still allowing secure admin/sudo access (user freedom).

BTW for graphical editors, you can run them via sudoedit (for example EDITOR=kate sudoedit /etc/...) - this way the actual editor is running as normal user without issues, but still can edit root-only file.

Right.

(For now, when using qvm-run -u root vmname xfce4-terminal, sudoedit does not work either since there is no X11/Wayland access from root user.)

(In Kicksecure documentation, using sudoedit is recommended.)

root will be an issue nontheless:

Some applications such as kate have even hardcoded (non-configurable) code to outright refuse running as root.