Skip to content
Snippets Groups Projects

backend-vnc: encryption and authentication

Merged Philipp Zabel requested to merge pH5/weston:vnc-auth into main

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.

Edited by Philipp Zabel

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
    • 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 a weston.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.

    • Author Developer

      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?

    • Author Developer

      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. :slight_smile:

      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.

    • Author Developer

      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. :slight_smile:

      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 via getspnam_r(), and hash the password with crypt_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.

    • Thanks!

      I know there are people who don't want PAM, but I think a PAM-only solution at first would be fine. Needing access to /etc/shadow is something I would not like to carry upstream.

    • Author Developer

      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
    • Please register or sign in to reply
  • Philipp Zabel added 7 commits

    added 7 commits

    Compare with previous version

  • Philipp Zabel added 15 commits

    added 15 commits

    Compare with previous version

  • Philipp Zabel added 33 commits

    added 33 commits

    Compare with previous version

  • Philipp Zabel added 2 commits

    added 2 commits

    • 5eab69bd - libweston: Add user authentication support via PAM
    • 0e091382 - backend-vnc: Add user authentication

    Compare with previous version

  • Philipp Zabel added 2 commits

    added 2 commits

    • 596c2013 - libweston: Add user authentication support via PAM
    • d03f65da - backend-vnc: Add user authentication

    Compare with previous version

  • Philipp Zabel changed the description

    changed the description

  • Pekka Paalanen
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Loading
  • Please register or sign in to reply
    Loading