Redesign of authentication architecture

[matt335672]

I've been involved in a few conversations recently which have made it pretty clear that our authentication protocol is difficult to extend in a generalised way to support more modern ways of authenticating.

Purpose of discussion

I'll summarise where we are at the moment, and what the drivers are for change, and then propose a way forward. I don't have all the answers at this stage, so I'd very much like some constructive criticism. In particular:-

• Have I got the scope right?
• There may be a better way to achieve much or all of this. I don't want to embark on a significant chunk of work if it turns out not to get us where we want to be.
• These are just my ideas. They can almost certainly be improved upon.
• What are the next steps? Should I put together some protocol exchange diagrams so the design is clearer?

Scope

This applies to the general case where both xrdp and xrdp-sesman are involved in creating a new session, or connecting to an old session.

At the moment I'm leaving auto session reconnection (see #1443) out-of-scope. I've explained this below.

Current login/reconnection process

• User types in username and password into xrdp login box
• xrdp uses SCP protocol to send username and password to xrdp-sesman.
• xrdp-sesman uses an authentication module (generally PAM) to authenticate and authorize the user. This happens in the main xrdp-sesman process.
• If authentication/authorization is unsuccessful, xrdp is informed of this, and the whole process ends. The connection between xrdp and xrdp-sesman is terminated.
• Otherwise, xrdp-sesman looks for an existing session for the user
• If an existing session is found, the details are communicated to xrdp which then connects to to the session. The connection between xrdp and xrdp-sesman ends.
• If a session is not found, xrdp-sesman forks a sub-process. The sub-process starts a PAM session (if appropriate), and then forks the session manager, X server and chansrv as sub-processes.
• A message is sent to xrdp informing it of the new session details. The connection between xrdp and xrdp-sesman ends.
• The sub-process waits for the session or the X server to end, and then cleans up.
• When the sub-process exits, xrdp-sesman removes the session from its list.

Observations

• PAM has become the de-facto authorization and authentication mechanism used by UN*X systems. Even Slackware has adopted now PAM.
• The existing process is non-interactive. The initial message from xrdp to xrdp-sesman has to contain all of the information for logging in.
• If the authentication blocks for any reason (e.g. missing DC when part of an Active Directory domain), xrdp-sesman becomes unresponsive until this is corrected.
• Because new sessions are created by process which is forked from the main xrdp-sesman process, we can have problems on systemd-enabled systems where D-BUS is used as part of authentication (see No user session created with xrdp and pam_systemd_home account module #1684). These problems do not apply to other ways of logging in to the system (i.e. via openssh or lightdm)
• The non-interactive nature of the process prevents the PAM conversation function from being able to interact with the user. Many 2FA/MFA modules rely on this method of working (see Feature Request: Support PAM based MFA #1959), so for example implementing Yubikey support would need special coding in xrdp.
• We have no permanent connection between xrdp and xrdp-sesman.

Requirements

• xrdp, as a whole system, should support PAM conversations, or (more generally) authentication conversations.
• These conversations should happen in a separate sub-process from the main xrdp-sesman process to prevent an existing conversation from preventing normal xrdp-sesman operation.
• The authentication sub-process must be capable of starting a new PAM session, or re-directing xrdp to connect to an existing session process.

Why is auto session reconnection out-of-scope?

Auto reconnection is described in [MS-RDPBGR] section 1.3.1.5. This requires a permanent connection between xrdp and either xrdp-sesman or the authentication sub-process so that cookie updates can be co-ordinated. In my opinion this will require file descriptors to be passed around, and so will necessitate replacing the existing SCP TCP implementation with something running over Unix Domain Sockets (UDS). We want to do this anyway, but that will be disruptive to the users and isn't necessary to bring into scope here.

Rough design

• The existing SCP V0 clients (xrdp and xrdp-sesrun) need to use libxrdp to communicate with xrdp-sesman rather than implementing their own calls.
• SCP needs enhancement to support authentication exchange messages. At this point, SCP V0 and SCP V1 should be unified. Much of SCP V1 can be removed, as it is implementing features which are tunnelled by the PAM conversation.
• An additional protocol is needed between xrdp-sesman and the authentication sub-process.
• When the authentication sub-process is forked, authentication exchange happens with xrdp via the xrdp file descriptor. The eventual result of this is communicated back up to xrdp-sesman proper via the additional protocol.
• As well as xrdp, the xrdp-sesrun and xrdp-sesadmin processes need updating to implement their side of the PAM conversation using the terminal.

[matt335672]

I've done more sketching out of this with a few data flows in my wiki:-

https://github.com/matt335672/xrdp/wiki/Authentication-architecture-redesign

Does that make it clearer what's being proposed here?

[Samoangtagey]

I am not sure if this belongs to here, but somehow it touches this thing aswell:

As we know, XRDP can't handle "password expired". But also, it can't handle if the user is logging in for the first time (no home directory existing).
If using SSH for example, you would get that dialogue for password expired and also it would automaticly ccreate the home directory.

For the second part: If using directory service (freeIPA in my case) the user doesn't exist as local account, but exists via LDAP.

I am not sure if this is relevant, since the login process is somewhat managed via PAM anyways, right?

[matt335672]

Good point @Samoangtagey. As well as your own use-case I've seen race conditions with ancient xrdp versions using NFS mounted home directories.

I've just had a dig around in the sources and Git. Here's my understanding of how it's supposed to work:-

Home directory creation is handled by pam_mkhomedir.so or pam_oddjob_mkhomedir.so. The latter module is used on SELinux systems (i.e. Fedora/RHEL/CentOS/etc) to create the home directory with the correct SELinux permissions. This is done by passing a synchronous D-BUS request to the oddjobd daemon to do the creation correctly. pam_oddjob_mkhomedir.so should be a drop-in replacement for pam_mkhomedir.so on these systems.

How does this relate to xrdp?

Both of these PAM modules run in the session creation phase of the PAM stack. From sesman, this happens when auth_start_session() is called. This stuff was pretty broken before #704 and #806 were merged, as there were race conditions between the X server and the session itself. After this (i.e. version v0.9.3 and later), as far as I can tell, xrdp is doing the right thing, at least as far as creating sessions is concerned.

So AFAICT, home directory creation should work, provided:-

1. You're using xrdp v0.9.3 or later
2. You've got pam_mkhomedir.so (non-SELinux systems) or pam_oddjob_mkhomedir.so (SELinux systems) correctly configured in the session section of /etc/pam.d/xrdp-sesman
3. If running on an SELinux system, oddjobd needs to be running.

I could well be missing something though, and if I am, now would be a good time to find it so we can make sure it's covered here. Could you investigate your setup and let me know how much my mental picture of what is happening diverges from reality??

[matt335672]

More dataflows are added to https://github.com/matt335672/xrdp/wiki/Authentication-architecture-redesign to cover the xrdp-sesadmin utility.

In a similar way to xrdp-sesrun this utility will need to support the PAM conversation on the terminal. There will be common code for this.

Later, when we move the xrdp <-> sesman connection to UDS, we can make explicit authentication optional for these utilities. The UID+GID of the caller will be simply passed over the socket.

[aquesnel]

Hi @matt335672

Good work documenting this design so far. Can you please clarify a few things for me:

• Can you please define "Session" in the wiki page? It seems like the word "session" is overloaded (xrdp-session, window-manager-session, and pam-session?), and these sessions seem related and different, but I'm not sure.
• Can you please clarify the scope of responsibility of the sdriver process vs sesman vs xrdp?
  • I think the division of responsibility is:
    • sesman: manage the list of xrdp-sessions (initialize the display, provide display connection info, destroy the display)
    • sdriver: perform authentication of a user
    • xrdp: manage client and display connections (parse rdp data/commands and forward the result to the appropriate connection or library)
• Can you please clarify why sdriver needs to be a separate process from xrdp? I don't know PAM at all, so I don't understand why sdriver needs to be a new process vs running as a function/thread in the xrdp process.
• In the proposed design, does the display initialization (start window manager, start X server, start chansrv) get done by sdriver or by sesman?
• Can you please add (or link to) a diagram which includes the end-to-end data flow from the rdp client to xrdp/sesman/sdriver/X/chansrv to clarify how this change will impact the rest of the system?
• Can you please add an example use case for what communication will happen between xrdp and sdriver after xrdp connects to the display? The "new session" data flow diagram shows the xrdp <-> sdriver connection remaining open until the pam session is closed with implied messaged being sent during the "session runs" section.

[aquesnel]

To try and clarify the session lifecycle for myself, I've drawn up an end-to-end connection sequence for the current version of xrdp. Please fill in any of the gaps that I missed.

edit diagram

[matt335672]

Wow - that's really impressive!

Two notes on the diagram. I haven't edited it myself:-

• The only actual error I've found is that the PAM authentication (rather than the session creation/destruction) is currently done in xrdp-sesman before it forks the xrdp-session. Code is here.
• the xrdp process exits when the X server exits or the client exits. When the X server exits, the call to xrdp_wm_check_wait_objs() here returns 1, and this prompts the cleanup.

The authentication/session creation split is the essence of #1684 - the PAM authentication is done by a different process than the PAM session management. I can't find any reason why this shouldn't be allowed in the PAM docs, but it breaks systemd. Also everything else I've looked at (sshd, lightdm) do PAM authentication + session management in the same process, so rather than fighting systemd, I reckon it's better in the long run to go with the crowd.

Does that all make sense? Please come back to me if it doesn't, or you disagree with any of the above.

[matt335672]

I'll briefly address your points above here, then I'll edit the wiki page.

As it happens I think I need to split the authentication and session creation phases up a bit more to address #1739. It's only a minor PR, but I think it's useful to illustrate we've got more flexibility in the new design.

• 'Session' is effectively what the user understands as being a session, in that it's the time from a successful first login up until the user explicitly logs out of the desktop. It's more-or-less the same as the PAM session or a window manager session. Sesman also has this understanding. xrdp may be a little vaguer, as it currently only cares about the existing connection. On systemd-enabled systems, a systemd session is the same as a PAM session.

• Your responsibility list is pretty much there:-

  • sesman: manage the list of xrdp-sessions (select existing sessions, allocate X displays for new sessions)
  • sdriver: xrdp session lifecycle management ((re-)authenticate user, start PAM session, start X server+window manager+chansrv, end PAM session)
  • xrdp: manage client and display connections (parse rdp data/commands and forward the result to the appropriate connection or library). Also contains window manager code for login screen.

• sdriver needs to be a separate process as systemd recognises a single process as being at the head of a systemd-session. Once a process has joined a session it can't join another one. Also, each xrdp session needs some intelligence to manage it.

• The starting of X server, window manager and chansrv is solely the responsibility of sdriver

• I'll take your rather excellent diagram above and modify it to show the end-to-end dataflows.

• At the moment once xrdp has been passed display connection info, there's no need for a connection to sdriver. There will be in the future, as we'll need this for keeping the 'auto reconnect' shared secret updated, and for other things.

As ever, thanks for your well-considered and incisive comments. I'll repost here when I've updated my page. It won't be instant!

[aquesnel]

This makes sense thanks.

[matt335672]

https://github.com/matt335672/xrdp/wiki/Authentication-architecture-redesign has been updated to address review comments from @aquesnel and incorporate separate connection / authentication phases into the SCP dialogues.

[aquesnel]

Hi @matt335672 ,

Thanks for updating the wiki page with the clarifications that I asked for.

We seem to be fumbling with the name of the "xrdp process that is connected to the rdp client", so can we choose a name for this forked process. I suggest one of:

• xrdp-connection-driver
• xrdp-client-driver
• xrdp-cdriver

For this reply I'm going to use the xrdp-cdriver name for this process.

From the Connect session (new session started) diagram there is only 1 command (which is from xrdp-cdriver to sdriver: "connect to session") and then the connection between sdriver and xrdp-cdriver is closed. This means that no other commands can be sent after the "connect to session" command. Also, since in the Connection session (existing session reconnected) diagram the xrdp-cdriver process is only never connected to the sdriver process which is watching the Xserver/chansrv processes of the connected display, which means that this reconnecting xrdp-cdriver can't send any commands to the sdriver after the "connect to session" command. This implies that any other session commands must be sent between the authentication phase and the "connect to session" command.
This seems like it means that any solution to the "Secret key refreshes for auto-reconnect" (see #1443) issue will require that the xrdp-cdriver will update the reconnect secret key in the session object by connecting to sesman directly. (I'm not asking that we bring this issue into scope of this architecture, just that we sanity check that the xrdp-cdriver to sesman connection is reasonable).
Can you please let me know if this interpretation and the consequences are correct?

For the List existing sessions section, I don't know what the pam-sesadmin utility is. Is this the same as xrdp-sesadmin or a new utility?

In the same section, you mention that the "list sessions" command is exclusive to the sesadmin utility, but I think that the "list sessions" command is also useful for rdp user facing use cases like an interactive session selector feature. I suggest that the exclusivity of this command to sesadmin be removed.

In the xrdp done section, can you please confirm that when the xrdp-cdriver disconnects from the sdriver that this only causes the session to be terminated if the disconnection happens before the "connect to session" command is received by the sdriver?

Once again, thanks for the design and the discussion.

[matt335672]

Thanks for that.

There's a lot to get through here. We've got a long weekend here in the UK, so I'll consider the above and come back to you Tuesday or so.

One thing which springs to mind which needs to be considered is security. With the file descriptor passing method, there are no real problems I can currently see(?) as the cdriver authenticates once and that's it. With reconnections, there will be a need to make sure we've opened no holes, particularly as sdriver has to be privileged.

[aquesnel]

Hi @matt335672 ,

I agree that security needs to be prioritized. Unfortunately I do not have any experience with the security model for Unix domain sockets, so I will not make any suggestions in that topic.

My experience with authenticating is over network sockets, and I've seen authentication be performed on every request (because of shared connections on a load balancer) or authentication be performed at the start of each connection. I like this security model of authenticating because it is simple and straight forward.

If you don't feel convinced that making the cdriver-sdriver connection long lived for the first implementation, then please feel free to use the design that you outlined for short lived connections in the first implementation.

Thank,

[matt335672]

I've had quite a think about your suggestions over the weekend. As ever, they've been extremely useful, and I can see a better design coming out of this.

I'll unpick these two things which I may:-

1. The fresh connection from cdriver to sdriver
2. Using UDS for the cdriver to sdriver connection.

Here's a diagram of the new connection scenario using a reconnection:-

Tell me if that's wrong.

At first I couldn't see a great advantage of this - we're moving complexity from the socket passing code to the cdriver. The socket passing code can easily be module-tested, and the cdriver is less easy to test. Then, however, I had a lightbulb moment which was prompted by #800. I haven't mentioned that before in this discussion, for which I apologise. #800 is all about making sesman restartable. At the moment, if we restart sesman with active sessions, relatively bad things can happen.

However, If the sdriver has a separate socket, it's relatively easy for sesman to restart as it can iterate over all the sdriver sockets to reconstruct its pre-shutdown state. Without these sockets, each sdriver has to detect sesman failure and poll for its return. I'm not happy with the existing PR for #800, as it introduces threading into an already complex program. With this model, there's a natural solution which should be easy to code and test.

Another minor advantage of the sdriver UDS socket is it gives us more test/diagnostic points. A disadvantage of course, is that we'd need to write the code to exercise these points.

How about security? The canonical way to secure Unix Domain sockets is to place them in a directory which is subject to normal permission checks. We need these sockets to be created by root, and reachable by root and whichever user xrdp/xdriver is running as. xrdp/cdriver normally runs as root, but Debian has a cunning hack to make xrdp/cdriver run as a non-privileged user called xrdp. In any case, security is not the big problem I thought it might be earlier.

I've already identified that when we move to UDS, we need a separate directory for the sesman socket. The existing socket directory has permissions which are unsuitable for this socket (see CVE-2020-4044). So adding another sub-directory of this directory for the sdriver sockets isn't a big deal.

That brings me to UDS. There's a couple of issues here:-

1. At the moment xrdp/xdriver and sesman can run on separate hosts. I don't think a great many people will be doing this as it breaks chansrv, but in any case, introducing UDS will remove this functionality. v0.9.17 will deprecate it (if the release notes have my note in about this), and I was hoping to remove it for v0.9.18 or later. Maybe this should be called v0.10.1.
2. The separate connection needs UDS. My domain doesn't use UDS initially for a couple of reasons.

I'd prefer not to make the UDS migration until after the initial drop of this software change. On a personal level I've got a chance of some sponsorship for the above, and introducing a dependency on UDS will possibly delay that for too long.

On the other hand, having thought about it, I very much like your suggestion about using a separate UDS for the sdriver control socket.

So I see a tentative plan forming on these lines:-

1. Finish some SCP tidy-up work very soon. This moves all the SCP calls into libscp. Astonishingly this isn't the case at the moment.
2. Implement the initial drop of this change:-
   • Re-implementation of SCP (much simplified, no socket-passing)
   • First implementation of sdriver based on the above. That gives us password changes / 2FA, etc from PAM
3. Move to UDS.
4. Implement permanent cdriver/sdriver connection
5. Implement reconnect + re-connecting over an existing connection
6. (or later) Implement restartability of sesman

I'd very much appreciate your thoughts on this. It's been bubbling about in the back of my mind now for a few days though, so I appreciate there's a lot to take in. Also, I may not have explained some of the above as clearly as I could have done.

[aquesnel]

This makes sense to me, and I think it's a good plan to move forward with.

[matt335672]

Thanks - I very much value your input for this.

@metalefty/@jsorg71 - have you got any comments on this before I start what will be quite a big chunk of work?

[gschwind]

Hello,

I starting to dig into sesman because I gathered a bug and ended here, because I had several thought while looking at sesman.

The first thought I get is that sesman and SCP seems to be superfluous and it can be integrated to xrdp using files or databases such as sqlite.

The other thought I had is that we may redesign the user "workflow" to make it both more consistent and more compatible with how PAM is working. The workflow may be as follow:

• Show a dialog to the user with the list of existing sessions (as windows do in his login screen) and items like "New Xorg session", "New Xvnc session" and so on.
• If the user choose an existing session show PAM conversation to authenticate using the session user name
• If the user choose to create a new session show PAM conversation for a new session and use the pam session creation stack.

If we remove sesman, we can manage the session list using combination of files or/and databases, we just need an extra care for concurrent access to the database and to check if the session still alive.

Replacing sesman by files make xrdp more simplier, imo, and session are independent from a process that may crash or being restarted.

I did not thought deep into security, but if the database is readable/writeable only by the root it should be fine.

Side note: I considering to contribute code.

[matt335672]

Hi @gschwind - thanks for joining the discussion.

I think you're right about sesman becoming largely superfluous. With the changes above, it becomes simply a point-of-contact for session management, and (eventually) just replicates state from the sdriver processes.

There's one thing which the separate design works really well with, and that is security. There's a lot of complicated code in the xrdp process. As I've mentioned above, this has sufficiently bothered the Debian team enough to patch the xrdp process to run as a non-privileged user. sesman needs to run as root to start sessions. But there is a lot-less code involved in this activity.

Running xrdp without privilege is something we'd like to broaden out a bit in the standard product. At the moment I can't see how we could merge xrdp and sesman without forcing xrdp to run as root. As ever, I'm open to suggestions which could make this work though.

[gschwind]

Hi @matt335672

Thank you with your feed back.

I think I understand why we want to keep RDP protocol out of the root user (freerdp) and it look sane even if it make the code more complicated. I will investigate more to have a better understanding of the architecture of xrdp.

Best regards

[jsorg71]

Thanks @matt335672 @aquesnel and others for pushing this ahead. Great stuff here.

We've learned much since we created sesman way back. Both about what xrdp needs and how auth works.
I do agree sesman should be a separate process for those exact reason above. A couple of things I'd like to consider including or at lease try to make easier to add later.

1 - RAIL support in sesman. Basically this just means starting the back-end(Xorg) and chansrv, no window manager. chansrv then starts(forks) any applications as they are part of the rail channel protocol. Although we should have a list of allowed(Published) apps somewhere. Session cleanup is triggered by chansrv exiting. So in this case sesman is not waiting for the window manager to exit, it's waiting for chansrv to exit. chansrv actually registers with Xorg as the window manger when the rail channel opens. Maybe we can have a list of apps to start and have one set as "primary" or "sentinel"? The primary one triggers session cleanup when it exits. RAIL is a really nice way to get xrdp used more in enterprise as the users don't even know they are using xrdp or even Linux.

2 - Multiple types and multiple types of the same back-ends. Currently we have Xorg, Xvnc, X11rdp as set types. One command line parameters config for each and global environment variables config. It would be nice to have something like Xorg-GPU1, Xorg-GPU2 where these have separate command line parameters and environment variables. Also, looking down the read, possible future back-ends could be Wayland, Android or Wine.

Basically my thoughts are about what processes we start and how we manage them.
I was thinking to ask about a move to xrdp 1.0 with the GFX bits but this is a good reason too.
Thanks

[aquesnel]

Hi @jsorg71 ,

I've been working on trying to get RAIL working in xrdp since I agree that it's an awesome feature.

From my understanding of RAIL, it only requires that there be some way of starting a program and ending a session. Since this proposal enables long lived connections and reconnections to the sdriver, I think that this will meet the needs of RAIL. Is there some other requirement that RAIL has in terms of session management?

Thanks

[matt335672]

I agree. I'm out of time today, but I'll try to explore some of the details around this in the next couple of days.

One thing occurs to me right now; If we're using chansrv for this, we will definitely need to improve the reconnections where a session is already active. I've referred to that above as 'client handover'.

[matt335672]

Sorry about the delay - been squishing bugs this week.

From what @jsorg71 says about RAIL support, it could look like this:-

We still need sdriver in this configuration, as:-

• we need a privileged process to manage the session. chansrv can't do this directly, as it's running as the user, so doesn't have privilege to close the PAM session, write accounting records, etc.
• we need something to manage client handovers, etc

Please let me know if I've got anything significant wrong there.

As far as Jay's second point goes about the back-ends I think that's sdriver detail, or am I missing something?

[gschwind]

Hello,

Looking deeper in all of your comments, I have several suggestion that I hope may be useful:

• The sesman can be a daemon start on demand by systemd that store session data to files, may be it's how sshd is actually working now without data store. Thus sesman will not be a permanent running daemon.
• Another approach is the sesman can be changed to a SUID exec that store session data into file to avoid a long running demon, making it more reliable. This may also change all program that communicate to sesman, as they do not have to run sesman to look at the sesman database.
• We can drop the current login scheme that require the user to login and sesman to look up for existing session, by listing current running session belong items to create new session. If the user select an existing session he have to authenticate for this session, otherwise he have to authenticate for creating a new session. This make both easier for the user and for xrdp stack and have a good match with session data stored into database.
• If the session is already running the authentication may take place into the userspace, I'm not sure but if you do not intend to create session you do not need root right to use PAM dialog.

[matt335672]

Thanks for the comments @gschwind. It's really important we have these discussions, and I appreciate you taking the time to put this together.

I've got some responses below. If you don't think I'm fully understanding some of your points, please come back to me.

systemd

As @metalefty says, we can't depend on systemd as that would prevent us from running on platforms which don't have it. We've got a reasonable number of users on FreeBSD (based on the issues which get raised) who would be left out in the cold if we moved to depend on systemd-specific elements. I don't know how many users we have on non systemd-based Linux distros, but there are a few. I've not seen any issues raised against Devuan yet, but I'm currently in a discussion with Alpine developers about xrdp support.

With that said, we can't ignore systemd at all. Most issues here are raised on Debian or Debian derivatives, all of which use systemd as the standard init system. This may change in the longer term - see this general resolution on init systems and systemd from 2019, but for now systemd is here to stay.

So the policy we currently have is to work with systemd, but not to be dependent on it.

systemd support has in-fact largely prompted these discussions - see #1684. We can't properly fix this issue without making sure that authentication and session creation happen in the same process. This does not currently happen, and requires architectural changes to fix.

Choose session before authentication

This certainly makes things simpler, but I don't think it's a good idea from a security perspective myself, as (if I'm understanding you correctly) it allows anyone who knows a username on a system to find out whether that user is logged in (and possibly from where) without authenticating. Offering a choice of sessions after authentication (on non-systemd based systems) would be a nice option though.

Because authentication requires a PAM dialog, it follows that the process which authenticates a user must be prepared to start a session too. In general authentication will require root permissions. For example, the pam_unix.so module needs to be able to read /etc/shadow to check a password is correct. This is a very common option on most systems.

Using a database or similar rather than a process to store xrdp session states

This can work, but I think there's a lot of detail which needs careful consideration when security and concurrent access are considered. These are the complications which would seem to arise from this:-

1. If we don't have a long-running process, and we can't assume systemd activation is available, I think we would potentially have multiple SUID executables accessing the same set of files. That's fine, but it needs to come into the design.
2. The utilities can simply read the data files or database to find out about the user sessions. That's good, and is simpler than what we have now. However, writing directly to these files isn't a great idea - the writes need to be curated. Utilities needing to do something which results in a change to these files will require the utilities to either start sesman, or find the sdriver for the session and contact that instead.
3. Each user on the system needs to be able to access the data related to their own sessions, and not those of other users. This is a necessary limitation for auto session reconnection, as otherwise a malicious user can discover the shared secret another user has and potentially reconnect to their session.

At the moment I can't see a big win here - if we dispense with the long-running process, the complexity doesn't seem to go away - it just moves elsewhere. But I could be missing something.

You mention sshd above. This doesn't need to maintain a session database as it doesn't support reconnections. The master process simply forks on connection to port 22, and the forked process does all the authentication and session management. This is what the sdriver process above is modelled on.

[gschwind]

Hello, I think you mostly understood my points I think.

About systemd, as far as I know the way I thought to use it is very similar than the way inetd is working, that mean we may use inetd for other unix like system.

About session selection, maybe it could be a threat and we can drop the idea.

About file storage, I agree that we need some care about this files, but in my thought this files should only limited to discover existing session. I do not expect them to change over time. They can be stored as per-user basis, maybe like screen is doing ?.

I have to thought more about it, but I do not like the idea that cdriver is directly connected to X server even if it's convenient, I would expect that cdriver connect to sdriver and sdriver communicate to Xserver or what ever we want in future, such as wayland stuff.

Best regards

[matt335672]

Thanks for coming back to me on this, and the interesting conversation.

I must admit to having completely forgotten about inetd! I've not used it personally for many years - my last experiences with it were on Red Hat 6 and Solaris 10. Your comment got me reading up on it, and the current state of the implementations out there.

As ever, there's a lot of detail which makes this difficult. We are keen to move to UNIX domain sockets for (UDS) for internal inter-process communication. The FreeBSD implementation of inetd supports these. It's not enabled by default, but that's a small detail. The biggest issue is that the most popular implementation of inetd on Linux (which we need for non-systemd Linuxes) is xinetd, and this does not support UDS as far as I can tell (most recent manpage is here).

We can take the files idea and run with it to see where we get.

For normal sessions, one option is to move the logic in sesman into the sdriver, and storing the state information in files. sdriver now needs to be SUID, as it's started by xrdp which may not be privileged. That's possible, but not great, as sdriver is complex. Alternatively we can have a simpler SUID process which xrdp starts (i.e. sesman). This can then start sdriver after making some checks.

For the utilities, we can discover existing sessions from the files for the user running them, and contact the sessions directly. Access to the sdriver is controlled by normal UNIX permissions. That's simpler for most situations, but more complex where we might be contacting more than one session (e.g. the existing 'list all sessions').

Is that the lines you're thinking along?

cdriver connects to the X server via an abstraction layer provided by one of the shared libraries (libvnc.so, libxup.so, libxrdpneutrinordp.so). This provides the protocol conversions necessary for the selected backend, and minimises the processes involved in data exchange. Unlike the stuff we're discussing here, this is performance sensitive data.

[gschwind]

Hello,

I think it's going in my direction, and it's fine to me :) but it's not mandatory. Also I'm not a regular maintainer -- thank to them by the the way -- thus you can pick what fit with you :)

If I design it somehow from scratch without care of effort we have to to I will do it as follow:

I will merge together sdriver, chansrv, libvnc.so, libxup.so, libxrdpneutrinordp.so, a sort of "big chansrv" that is able to stream screen changes and inputs belong other stuff needed (rdp protocol?). It will be run as daemon listening to UD socket that xrdp is able to read/write. I will protect the access to that daemon using a token, maybe like xauth/xorg do (I do not know how the chanserv is protected). this token will be generated randomly for each session and stored in file that only the owner is able to read. Belong that file I will also put some files to describe current running sessions, maybe those files can be merged together. This daemon should run from the beginning of the session to his termination and is run as the session user.

On another side we have the xrdp server and the cdriver together run as a regular user such as xrdp. they can connect to the UD socket of each "big chansrv" provided the corresponding generated token. To get the token and the list of currently running session the xrdp/cdriver can use a SUID exec that is expected to authenticate user and read files stored for that user and feedback xrdp/cdriver. Xrdp can connect to the running session directly using gathered token.

The tricky part is to start the "big chansrv" and the session, but for this we can use another SUID exec with the responsibility to authenticate and create the new session, and provide back the token to allow immediate connection.

The SUID exec maybe the same for both case and is somehow the current sesman.

I do not know how much work it is but it is how I would design it.

Thank you also for the discussion :)

[matt335672]

Thanks for your thoughts, @gschwind

A couple of things off the top of my head:-

• Permissions. sdriver needs to be privileged so it can properly close a session which has exited. The rest of your "big chansrv" could run as the logged-in user.
• Supported use-cases. Chansrv is not needed for proxied RDP or VNC connections. In these cases also, the only user is the one that the xrdp process runs as. There is no separate user to work with.

This is also a rather massive change which looks like it would need its own project! I accept that this is what you would do if starting from scratch, but we don't have that luxury. We have an existing user community ranging from single user installations to enterprise installations integrated with Active Directory or similar.

I'm also a bit wary of SUID executables. as these require extra maintenance effort to validate after modification. There are normally very few of these on a modern system. On my development machine:-

# Count world-executable files:-
$ sudo find / -xdev -type f -perm -5 | wc -l
10873
# Count SUID world-executable files:-
$ sudo find / -xdev -type f -perm -4005 | wc -l
16

The security scanner NESSUS flags up SUID executables. We have a few enterprise users who for corporate reasons have to use NESSUS to scan internal systems. Some of these users have very little latitude to interpret results - they're just told to get a clean scan. Here's a gitter conversation which illustrates why we don't want to generate even more problems with NESSUS. I'm not at all saying that users who can't interpret these results are somehow wrong - it's just the way the enterprise world is, and it's up to us to fit in with it.

I think the approach we have to take for now is to keep the existing xrdp / sesman split, and move to the new architecture as described above. This will greatly simplify sesman, as a lot of its current activities will move to the sdriver. At that point we can re-evaluate whether we want to keep a long-running sesman, or move to a distributed arrangement. As I hope I've managed to illustrate above, it's a very complicated situation when you need to factor-in existing users.

[matt335672]

As a general note, the changes proposed in #1077 should be relatively easy to implement in the sdriver after implementation. See also #1302 regarding lastlog.

[metalefty]

Related to #909, #1976 and discussions on file descripor, I tried to add blacklistd support to xrdp years ago but gave up at the time. blacklistd comes from NetBSD to FreeBSD. It is a fail2ban like daemon to reject packets from IP address with failed login attempts.

I implemented it to postifx as FreeBSD local patch. It is quite simple code.
https://github.com/freebsd/freebsd-ports/blob/4d632b65ba25b132abc75e2961cd92f833f68add/mail/postfix/files/extra-patch-blacklistd

if (authentication_failed)
{
     pfilter_notify(1, fd);
}

void
pfilter_notify(int a, int fd)
{
	if (blstate == NULL)
		blstate = blacklist_open();
	if (blstate == NULL)
		return;
	(void)blacklist_r(blstate, a, fd, "smtpd");
	if (a == 0) {
		blacklist_close(blstate);
		blstate = NULL;
	}
}

However, the reason I gave up once is, it requires file desctiptor to get client's IP address to block but sesman doesn't have file desctiptor of client's connection. In addition, xrdp process doesn't know authentication result.

When file descriptor is passed to sesman or authentication result is notified to xrdp process, I can go on blacklistd again.

[matt335672]

Have a look at #1976, which we haven't merged yet.

xrdp passes a string representing the connection to sesman as part of the SCP V0 connection request. The changes is #1976 allow the actual IP to be recovered from this string, so we should be able to implement the above reasonably easily I think.

[metalefty]

Regarding blacklistd, all functions require a file descriptor.
https://www.freebsd.org/cgi/man.cgi?query=libblacklist&sektion=3&manpath=freebsd-release-ports

#1976 looks fair enough doing that in current implementation of sesman.

[matt335672]

Ah sorry. I see now.

Referring to #2004, we should be able to get a better status sent back to xrdp using SCP V2. That's the simplest solution. Once we start passing file descriptors about, we won't easily be able to use JSON on this interface.

[Samoangtagey]

Hey there, been a while since the last message in here. Right now I have the "funny" job to make a first login manually for round about 1300 accounts so they can use xrdp afterwards ... which of course focuses my interest the more on the redesign of the authentication architecture.

Any news on this? I don't know if there is anything I can do to help, but if there is something, please let me know ;-)

[matt335672]

Hi @Samoangtagey

It's happening, but it won't be quick I'm afraid. There's quite a bit to do! I've made a start with #2011, which gets us to a place where we can make the required changes to the SCP protocol. I want to get that step in in the next month or so.

This logging-in you mention sounds somewhat time-consuming. Surely it must be possible to automate some of it?

[Samoangtagey]

Hi @matt335672 , I'll try to explain my situation:

I created 60 VMs with CentOS on a CentOS vhost. So far there have been round about 130 users, which accounts were managed manually and locally. Talking about time consumption ;-) But ... the sessions with XRDP always worked fine.

Recently there finally was the idea to switch to free-IPA as a central user-management. So I only have to manage 130 ldap accounts instead of 1300 local accounts :-) So far so good ... I set up all the users as new accounts into free-IPA and connected the VMs to the domain. Everything is fine. But there is the problem that the user never has the chance to login locally on the VM, the only way is remote with rdp. So ... how to make the first login for each user?

What I am doing now is, I have to create a user in free-ipa and set a password. Then I have to connect with a virt-manager to the VM and login as that new user with gdm. The step with logging in with gdm is important, because this way not only the homedir is created, also all necessary data for desktop environment is created. After this I can tell the user he can login with rdp and everything is working.

This step I have to do for each user on each VM, right now for 1300 times. It's not just an easy "useradd"-skript, at least I don't know how to make one with including the data for desktop environment. If there is any way, I'd be happy to know, because it's REALLY time consuming. Luckily, once done, the user management will be much easier :-)

[matt335672]

One of the main drivers behind the authentication redesign is to allow passwords to be changed. So that should work OK when it's done, as you can set an expired password for the user.

I'm not at all clear why this won't work:-

1. Set up the user in free-IPA with a known password
2. Ask the user to log in to rdp with the known password, and ask them to change the password.

If you've got PAM set up correctly, the homedirs should be created anyway unless you're running an ancient version of xrdp. At least that's my understanding. Does that not happen?

[matt335672]

Hmm. That looks like it should work to me, as password-auth is including the right bits.

Can you cat /etc/pam.d/password-auth for me? I'll try to reproduce it here.

[Samoangtagey]

It's pretty difficult to extract the text out of the terminal, as I myself also work remotely on it. Since it's an auto-generated file, I guess there might be only few edits if any. I'll send a screenshot:

.

[matt335672]

I've managed to reproduce this on a clean CentOS 7 build (without FreeIPA) after enabling home directory creation with sudo authconfig --enablemkhomedir --update

Without installing the xrdp-selinux package along with xrdp I get SELinux errors:-

$ sudo ausearch -m avc -ts recent
----
time->Mon Oct 25 12:12:27 2021
type=PROCTITLE msg=audit(1635160347.944:428): proctitle=2F7573722F7362696E2F6F64646A6F6264002D6E002D70002F7661722F72756E2F6F64646A6F62642E706964002D7400333030
type=SYSCALL msg=audit(1635160347.944:428): arch=c000003e syscall=59 success=no exit=-13 a0=559f659000a0 a1=559f65901b90 a2=559f65910340 a3=7265735f64656e69 items=0 ppid=10715 pid=10795 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="oddjobd" exe="/usr/sbin/oddjobd" subj=system_u:system_r:oddjob_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1635160347.944:428): avc:  denied  { transition } for  pid=10795 comm="oddjobd" path="/usr/libexec/oddjob/mkhomedir" dev="dm-0" ino=51171138 scontext=system_u:system_r:oddjob_t:s0-s0:c0.c1023 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=process permissive=0

The reason is that without xrdp-selinux installed, the process leader isn't able to transition from unconfined_service_t to unconfined_t. As a result the home directory isn't created. With the package installed, all appears to be well.

Can you try sudo yum install -y xrdp-selinux ; sudo systemctl restart xrdp xrdp-sesman and see if that fixes it for you?

[Samoangtagey]

Indeed ... this did it !!! Now it's working :-)
Wow ... you have no idea how happy I am to have this working :-)))
Thanks a lot

[Samoangtagey]

Actually ... I wonder why xrdp-selinux was missing ...
I think the VMs are pretty "old" ... of course always updated, but initially setup years ago. I guess back then xrdp-selinux didn't exist, so when it came up, it of course didn't install just by itself. Since everything was walways running fine, noone noticed it until now.

[matt335672]

See also #736 which can be closed when this is implemented.

[matt335672]

I've updated the architectural plan around what I hope is achievable for a first drop of the software-

https://github.com/matt335672/xrdp/wiki/Authentication-architecture-redesign

Previous versions of the document can be viewed from the history.

It's not a massive change from where we are at the moment with xrdp v0.9.x, so it should be achievable relatively quickly with everything else that is going on.

I'm still thinking about file descriptors, and in particular about this comment above. Originally UDS was out of the picture, but now not only is it available, but the new SCP gives us a natural API for passing file descriptors about by using the simple D-BUS type 'h' (see here) although this has yet to be implemented. More on this quite a bit later however.

[gschwind]

Hello,

I'm using jupyterhub [1] currently and they have a setup that is similar than our setup, and they use only sudo to switch user and all processes does not need to run as root. In particular I use the setup describe in [2]. It may be worth to take a look.

Best regards

[1] https://jupyterhub.readthedocs.io/en/stable/
[2] https://github.com/jupyterhub/jupyterhub/wiki/Using-sudo-to-run-JupyterHub-without-root-privileges

[matt335672]

Thanks - I'll take a look.

This does of course introduce a dependency on sudo. Some distributions (e.g. Alpine Linux 3.16 and later) are moving to doas as an alternative. It may however be possible to use sudo as a compile-time feature if it's available. That would allow distros to specify their own user and sudo configuration to harden the default installation.