Code Excursion

Getting XRDP to Work on Linux

My fellow programmers and I use XRDP, an open source Remote Desktop Protocol application, for remotely connecting to our workstations. Routinely during upgrades XRDP would stop working. Some time later, during a routine security scan, my workstation was assessed to have the CVE-2005-1794 vulnerability. CVE-2005-1794 is about a man in the middle attack being able to spoof public keys. This vulnerability exists on both Linux and Windows. The workstation I am working with is XFCE Fedora Core 23.

Having to redo the configurations a number of times, for myself and others, it seemed prudent to document the procedures. First let us look into getting XRDP to play nice with SELinux. SELinux uses extended file attributes to label files with a “Security Context”. For XRDP to work with SELinux we need to change the context of files xrdp and xrdp-sesman as shown below.

Change files security context

sudo chcon --type=bin_t /usr/sbin/xrdp
sudo chcon --type=bin_t /usr/sbin/xrdp-sesman
sudo systemctl reenable xrdp.service
sudo systemctl start xrdp.service

What happened is we used the change context command to change the type of the files. SELinux then allowing the files to be run. Unfortunately the changes above will likely not last if you reinstall or upgrade XRDP. To make the changes more permanent you would want to modify SELinux configuration to remember the changes.

Add file context configuration to SELinux configuration

sudo semanage fcontext -a -t bin_t "/usr/sbin/xrdp"
sudo semanage fcontext -a -t bin_t "/usr/sbin/xrdp-sesman"
sudo systemctl reenable xrdp.service
sudo systemctl start xrdp.service

Now that SELinux is out of the way, you will want to make sure port 3389 is open in your firewall. On my system I have Firewall and I added port 3389 under “Public” for both the “Runtime” and “Permanent” configurations.

Now lets look into securing XRDP from public key spoofing. We chose to create a self-signed certificate. For our purposes this will be perfectly adequate as only our team will be connecting to the workstations and we know they are trustworthy. First lets get our certificate. You will be prompted to answer a series of questions about the location and name of the server for which it is being created.

Generate a certificate

bash-4.3$ cd /etc/xrdp
bash-4.3$ openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 3650
Generating a 2048 bit RSA private key
..........+++
.......+++
writing new private key to 'key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:US
State or Province Name (full name) []:Kentucky
Locality Name (eg, city) [Default City]:Louisville
Organization Name (eg, company) [Default Company Ltd]:Open Source
Organizational Unit Name (eg, section) []:Blog
Common Name (eg, your name or your server's hostname) []:Workstation
Email Address []:no@email.com

Once that is accomplished change the permissions of of the keys to protect them.

Generate a certificate

bash-4.3$ chmod 400 key.pem
bash-4.3$ chmod 444 cert.pem

Next we modify the /etc/xrdp/xrdp.ini file to enable tls by changing “security_layer=rdp” to “security_layer=tls”. Finally we restart the XRDP service in order for the changes to take effect.

Restart XRDP

bash-4.3$ systemctl restart xrdp

Update:
Due to a security scan hit on XRDP for not activating Network Level Authentication I had to forgo its use in favor of Tiger VNC. XRDP is aware of the issue but at this time we don’t know when a fix will be available.