search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
541 stars 48 forks source link

Make user password persistent in GUI domain #6740

Open marmarek opened 3 years ago

marmarek commented 3 years ago

The problem you're addressing (if any)

Currently the user password (hash) is copied from dom0 when creating sys-gui-(gpu,vnc). And is stored in /rw/config/rc.local. This means if user changes the password in the GUI domain, the change won't be persistent. Furthermore, the password is not copied into sys-gui (the hybrid solution) - which means it's impossible to unlock the screenlocker there...

Describe the solution you'd like

Some way to persist the password change in the GUI domain. Configure PAM to save the new password hash somewhere into /rw?

Where is the value to a user, and who might that user be?

Ability to (conveniently) manage user password when GUI domain is in use.

Describe alternatives you've considered

Synchronize password from dom0 at each GUI domain startup, and provide a way to set the password in dom0. But this won't scale for multi-user cases.

Additional context

The password is set here: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-gui-gpu-vm.sls#L26 And retrieved from dom0 here: https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/pillar/qvm/sys-gui-gpu.sls

Relevant documentation you've consulted

https://github.com/QubesOS/qubes-doc/pull/1166

Related, non-duplicate issues

https://github.com/QubesOS/qubes-issues/issues/4186

DemiMarie commented 3 years ago

Synchronize password from dom0 at each GUI domain startup, and provide a way to set the password in dom0. But this won't scale for multi-user cases.

We could invoke the passwd command (or similar) in dom0 over qrexec.

marmarek commented 3 years ago

We could invoke the passwd command (or similar) in dom0 over qrexec.

If synchronizing with dom0 password would be desired, then probably yes. But as mentioned there, it isn't the best option.

DemiMarie commented 3 years ago

We could invoke the passwd command (or similar) in dom0 over qrexec.

If synchronizing with dom0 password would be desired, then probably yes. But as mentioned there, it isn't the best option.

That is true, although we could disable the account in dom0 by setting its shell to /usr/sbin/nologin. Also, in the multi-user case, each user will presumably have their own GUI domain, so the system needs to know which one to launch.

marmarek commented 3 years ago

I'm not sure how disabling the user account in dom0 helps here. It isn't about whether it should be possible to login directly into dom0, but rather about whether they should have always the same password.

Note the issue is generic, about any kind of GUI domain - not only the one connected to the local graphics, but also those with remote access (like VNC) - in this case, you can easily have multiple of them at the same time. While there is way more work needed for full multi-user support, even in the simple case you may want different passphrases for different GUI domains.

DemiMarie commented 3 years ago

I'm not sure how disabling the user account in dom0 helps here. It isn't about whether it should be possible to login directly into dom0, but rather about whether they should have always the same password.

In the specific case of local graphics, there may be more than one GUI domain, one for each user. This means that dom0 somehow needs to figure out which GUI domain needs to start.

ddevz commented 2 years ago

In the specific case of local graphics, there may be more than one GUI domain, one for each user. This means that dom0 somehow needs to figure out which GUI domain needs to start.

Currently sys-gui is made as a .desktop file in /usr/share/xsessions/ then shows up in the list of possible sessions you can log into.

Presumably making a "sys-gui-bob" and a "sys-gui-peter" would also create .desktop files for them in that directory and they would then also show up in the list of sessions for dom0 users to log into.

Would there be some way to map dom0 users permissions to which session(s) they should be allowed to log into in "AccountsService"? It looks like files like /var/lib/AccountsService/users/user have a "Session" parameter and a "XSession" parameter, but from what people say those set the default session for that user, not the allowed sessions for that user. (unfortunately AccountsService documentation seems to be quite thin so it's possible there is a "only allowed to log into these sessions" parameter in that file that I can't find documentation for).