Adds an enable_auto_login flag to xrdp.ini

[justledbetter]

This PR adds a flag called enable_auto_login to xrdp.ini that, when set, will automatically start the first session defined in the xrdp.ini / xrdp-sesman.ini files.

If this flag is not set, nothing happens and the code behaves as it always has.

It should really only be useful on a system where:

• There is only one RDP session defined,
• This session uses the username / password fields to login as a defined local user account, and
• The startwm.sh script has been modified to run a single application and then log out.

In my usecase, there's a program I want to make available to LAN users that performs its own post-startup authentication, so that application (running constrained under the user account that's started by Sesman) will handle all user interaction once it is past the RDP startup process.

[matt335672]

Thanks @justledbetter

We've had at least one similar request in the past - see #2836. It's not something we're keen on accepting for the reasons in this comment.

I'd appreciate your thoughts on that.

[justledbetter]

@matt335672 many thanks for the feedback, didn't realize I was implementing something that had already been tried!

I guess my main feedback would be "If it's a bad thing per policy to store a plaintext username/password combo in a config file (which can be configured to be readable only by the xrdp user on most modern systems), why provide the ability to put a username/password in the .ini file?" Wouldn't the correct response to this objection be to remove the username/password fields rather than allowing the administrator (in a carefully controlled situation) to utilize those fields to make their users' lives easier?

The application I'm serving up via Xrdp is entirely self-contained and provides its own internal authentication, there's no escape vector for the end user from the controlled session that I've setup for it. It would be nice to skip the single-session OK prompt, given I've configured everything else to be sufficient.

That being said, if the desire is to provide stronger controls around the storing of plaintext fields in the xrdp.ini file, would it be valuable for me to take a stab at providing an encryption mechanism for that field? It shouldn't be too difficult to build something that can encrypt the password using a system-generated private key and have it decrypted on the fly during session startup, if that's something that would help address these security concerns.

(I guess my only other observation would be, and I apologize for neglecting this, to update the documentation describing this configuration variable to be fundamentally explicit that it requires careful setup and configuration to be secure; and perhaps to also provide some in-xrdp checks to ensure that file permissions are correct before allowing the flag to be set to true. Happy to also make those changes if you're amenable to it!)

Respectfully,
Brian

[matt335672]

Hi Brian,

Thanks for coming back to me. It's a good area to discuss.

If it's a bad thing per policy to store a plaintext username/password combo in a config file (which can be configured to be readable only by the xrdp user on most modern systems), why provide the ability to put a username/password in the .ini file?

It's a good point, particularly for the password. The linked issue sort-of explains what this is for (connecting to a VNC session), but ideally it should be removed in the 21st century. I'm hoping to move in this direction before we are forced to. Some of xrdp is quite old, and dates from a time where this sort of thing wasn't taken as seriously as it needs to be today.

The basic principle we're trying to adhere to now is "connections to xrdp must be authenticated at the point of connection". This is so:-

1. we are as compatible as we can be with ISO 27001/27002 and (in the UK) NCSC guidelines.
2. we minimise the attack surface of the software by authenticating as soon as we can.
3. we're providing "defence in depth" in the event that the network is penetrated in an unforeseen manner.

This authentication can be completely separate from the application-level authentication you are describing - the user need not see it at all. For your case I'd suggest embedding a username and (encrypted) password in the Windows .ini file (assuming you are using Windows) which is used just to get the connection up. The user can then use the in-app authentication you are providing.

We use PAM for authentication at this level, so a system administrator could in theory make this username/password combination as insecure as they want, just as they could for any other networked service authenticating in this way.