backend-vnc: encryption and authentication
Enable the TLS encryption and password authentication support provided by Neat VNC.
This requires VNC clients to authenticate with the user name and password of the local user weston is running as. The TLS key and certificate have to be provided via command line parameters, same as the RDP backend.
Merge request reports
Activity
added 7 commits
- 6e168e42 - backend-vnc: add VNC support using Neat VNC library
- 49ac8d59 - backend-vnc: add meson subprojects support
- 09ed0b98 - backend-vnc: add meson wrap files for aml and neatvnc
- 6251be38 - man: add a man page for the VNC backend
- 2ee46adb - Merge branch 'backend-vnc'
- a7658257 - backend-vnc: enable TLS support
- 45b3ab59 - backend-vnc: add password support
Toggle commit listadded 7 commits
- 2f0af445 - backend-vnc: add VNC support using Neat VNC library
- 0344b3ca - backend-vnc: add meson subprojects support
- 0eb4caac - backend-vnc: add meson wrap files for aml and neatvnc
- 46bd6e48 - man: add a man page for the VNC backend
- 21c7b518 - Merge branch 'backend-vnc'
- 2cdd27c6 - backend-vnc: enable TLS support
- 4ccba566 - backend-vnc: add password support
Toggle commit listadded VNC Backend label
added 9 commits
-
4ccba566...60c47701 - 3 commits from branch
wayland:main
- 9e592274 - ci: Build and install aml and neatvnc
- 18b4cc06 - backend-vnc: add VNC support using Neat VNC library
- 2ce73edf - man: add a man page for the VNC backend
- bc93674d - Merge branch 'backend-vnc'
- 131df052 - backend-vnc: enable TLS support
- 6ecf3f95 - backend-vnc: add password support
Toggle commit list-
4ccba566...60c47701 - 3 commits from branch
added 4 commits
-
7a3b728f...ad936f1d - 2 commits from branch
wayland:main
- 98fee3b8 - backend-vnc: enable TLS support
- 5bc8ec32 - backend-vnc: add password support
-
7a3b728f...ad936f1d - 2 commits from branch
added 4 commits
-
5bc8ec32...2f0be4b4 - 2 commits from branch
wayland:main
- e3366710 - backend-vnc: enable TLS support
- 12851fa3 - backend-vnc: add password support
-
5bc8ec32...2f0be4b4 - 2 commits from branch
- Resolved by Philipp Zabel
Yeah, I agree this looks strictly an improvement, so we could land this already.
I do have a couple questions. The first one was my comment about making password and TLS mandatory.
The second one is, would it be feasible and good to use the OS user authentication services instead of a
weston.ini
password? If yes, is there any use for aweston.ini
password?If using OS services, then I think TLS must be mandatory.
After all, this login allows to take full control as the user running the compositor.
Not a fan of the cleartext password in weston.ini either. We could store a hash instead. I was not sure whether
weston.ini
is the right place at all.For the desktop use case, matching against the running user sounds like a good option. I wouldn't like that to be mandatory, though. Depending on the shell, the VNC client might not have full control and it could be useful to have the VNC user/password be different from the local user account.
Currently TLS is mandatory as soon as authentication is enabled, to avoid sending cleartext passwords over the network.
I mean there are various tools that ask for the user password, usually like
sudo
in order to elevate privileges, but in this case we don't want privileges, we just want to authenticate. If there is an API Weston could use for that to authenticate the current user, that would be nice.Depending on the shell, the VNC client might not have full control and it could be useful to have the VNC user/password be different from the local user account.
I have difficulty understanding that use case. What use cases do you have in mind?
If you want to restrict a "guest user", then would you not restrict the real user that the compositor runs as? I think that is a lot easier than ensuring that the shell cannot launch unwanted apps and that the wanted apps cannot do anything unwanted.
I guess you could have a VNC mode that is display only and no input accepted. That seems to be the only case I can imagine where the VNC client would have obviously less control than the real user account.
Trying to figure out a good custom credentials store is something I'm not sure we should be in the business of.
Do you actually have a real use case you need the custom credentials for, or is it just a small step towards better security?
I'm afraid "could be useful" is not enough for this if there is any way we could do better.
My main worry is that just like RDP-backend, the VNC-backend is too easy to set up in a very insecure way. I think it would be good if it was secure by default, and only optionally less secure. But it's already merged in a form that takes no authentication at all.
Would people be smart enough to not use their real user account password in
weston.ini
?I have difficulty understanding that use case. What use cases do you have in mind?
I was thinking about a single-user embedded device here, running a single application that displays two full-screen windows, one GUI window for the user on the hardware output, and one service GUI window for a remote support technician on the VNC output (with multi-backend support).
Trying to figure out a good custom credentials store is something I'm not sure we should be in the business of.
Do you actually have a real use case you need the custom credentials for, or is it just a small step towards better security?
You made me write 'this is insecure' into weston-vnc.man and this is my reaction :) So the latter, really.
My main worry is that just like RDP-backend, the VNC-backend is too easy to set up in a very insecure way. I think it would be good if it was secure by default, and only optionally less secure. But it's already merged in a form that takes no authentication at all.
I don't think restricting defaults within a development cycle should be a problem? We'd just have to land on a solution before Weston 12 releases with VNC support.
I don't think restricting defaults within a development cycle should be a problem?
I meant the opposite: we are in hurry to get a good auth mechanism in, because the VNC-backend will be part of the next release.
Could you check how other software like screen lockers authenticate the user for unlocking? Could we use that in Weston? If VNC-backend uses that first, maybe someone else could add the same to RDP-backend as well.
Or is that out of your reach at the moment?
I would really like to skip the "password in weston.ini" option if possible, or maybe add it after a better way if there are still use cases that need it. In that embedded device example you gave, maybe the display server is executed as an admin user account (that may not be as powerful as root) which has a password set. Or maybe a different user could be configured in weston.ini to auth for but still use system accounts.
I meant the opposite: we are in hurry to get a good auth mechanism in, because the VNC-backend will be part of the next release.
Alright,
Could you check how other software like screen lockers authenticate the user for unlocking? Could we use that in Weston? If VNC-backend uses that first, maybe someone else could add the same to RDP-backend as well.
it looks to me like the usual solution is to link against libpam and use
pam_authenticate()
to check username and password. A PAM-less alternative would have to be able to read /etc/shadow, for example viagetspnam_r()
, and hash the password withcrypt_r()
to compare the result. I'll try both.I would really like to skip the "password in weston.ini" option if possible, or maybe add it after a better way if there are still use cases that need it.
Ok. Let's remove user/password configuration and make TLS mandatory for now.
Added mandatory PAM user authentication. Now this is missing a configuration file
/etc/pam.d/weston
, which is a bit arcane to me. I am not sure what this should contain as a sensible cross-distro default. I just used:#%PAM-1.0 auth include password-auth account include password-auth
on Fedora and on Debian:
#%PAM-1.0 @include common-auth @include common-account
to test.
Yeah, the PAM file is a hassle indeed. It's good that you mention it in the man-page now, but would it be possible to give more hints to what it should have? Yes, it's distribution-specific, unfortunately.
Hmm. Wonder if distributions would package their own PAM file for Weston... maybe that needs to be called out somehow, perhaps in release notes - cc @emersion.
It should be possible to install a one-line file with
auth include login
which works on all distros. Distros can always overwrite it if they want to. That's what we've been doing for swaylock:Edited by Simon Ser
added 7 commits
-
12851fa3...5079f0b2 - 5 commits from branch
wayland:main
- c169f47d - backend-vnc: enable TLS support
- 7f9d75f6 - backend-vnc: add password support
-
12851fa3...5079f0b2 - 5 commits from branch
added 15 commits
-
7f9d75f6...2e396302 - 13 commits from branch
wayland:main
- c58a7218 - backend-vnc: enable TLS support
- 6c5b8ef6 - backend-vnc: add password support
-
7f9d75f6...2e396302 - 13 commits from branch
added 33 commits
-
6c5b8ef6...d3b74daa - 30 commits from branch
wayland:main
- e63cf668 - backend-vnc: enable TLS support
- 12e457e3 - libweston: Add user authentication support via PAM
- 3e8aeb26 - backend-vnc: Add user authentication
Toggle commit list-
6c5b8ef6...d3b74daa - 30 commits from branch
- Resolved by Pekka Paalanen