The TCP socket implementation of sesman has a number of limitations,
namely that it is affected by firewalls, and also that determining the
user on the other end requires a full authentication process.
The advantage of the TCP socket is that sesman and xrdp can be run on
separate machines. This is however not supported by the xorgxrdp
backend (shared memory), and is insecure, in that passwords are sent
in-the-clear, and the connection is susceptible to MitM attacks. This
architecture has been deprecated in release notes since xrdp v0.9.17,
and although it will continue to be supported in any further releases
in the x0.9.x series, it will not be supported in the next major
version.
This is required for PAM systems that depend on group membership being
available during PAM processing. This is used by pam_group on FreeBSD
and pam_group on Linux-PAM, although the functionality of both is
different.
There are a number of ways the existing transport connect logic in
trans_connect could be improved for POSIX compatibility, and also
slightly tidied up:-
1) The same socket is re-used for multiple connect attempts following
failure which isn't behaviour defined by POSIX.1-2017 (although it
works on Linux).
2) An asynchronous connect is started, and then after a short
delay connect() is called again on the same socket. POSIX.1-2017
is clear that in this situation EALREADY is returned before the
connection is established, but is silent on the behaviour expected
when the connection is established. Returning success is an option,
but so is returning EISCONN. The current code assumes the connect()
call will succeed.
3) The code contains two virtually identical, quite complex loops for
TCP and UNIX sockets, differing only in the calls to create a socket
and connect it.
4) trans_connect() contains looping and retry logic, but this isn't
seen as sufficient by the chansrv connect code in xrdp/xrdp_mm.c and
the Xorg connect code in xup/xup.c. Both of these implement their own
looping and retry logic on top of the logic in trans_connect(),
resulting in slightly unpredictable behaviour with regard to
timeouts.
5) A socket number can technically be zero, but in a couple of places
this isn't allowed for.
This PR attempts to correct the implementation of trans_connect(),
and also to simplify the areas it is called from.
As part of the PR, the signature of the server_is_term member of the
xrdp module interface is changed to match the signature expected by the
is_term member of a struct trans. This allows for trans_connect()
in xrdp modules to directly access g_is_term() within the main xrdp
executable. At the moment this functionality is only used by the xup
module.
- Eliminate duplicaiton for display_size_description
- monitorCount needs to be uint32_t
- width/height -> session_width/session_height
- Update CLIENT_INFO_CURRENT_VERSION
- Also some misc unit test updates.
- Minor log updates.
There are two places where monitor descriptions are passed through the
RDP protocol:
- TS_UD_CS_MONITOR ([MS-RDPBCGR] 2.2.1.3.6 Client Monitor Data)
- DISPLAYCONTROL_PDU_TYPE_MONITOR_LAYOUT ([MS-RDPEDISP] 2.2.2.2)
The processing logic for both of them is similar enough that they should be unified.
Also update to define the constants for the maximum and minimum desktop width/height for monitors and total area.
Also a large number of clarifications for the constants and protocol
requirements.
Note that this is also the first step to making resizing work with the extension GFX channel as well as an important
foundational step to enable HiDPI compatibility.
Also some misc logging updates.
- Based on https://github.com/jsorg71/xrdp/tree/dynamic_monitor
- Tested with xorgxrdp
- Tested with vnc
- Only works with single monitor.
- Update documentation to clarify the difference between MSTSC and
Microsoft Remote Desktop.
- Does not include compatibility with /gfx at this time, which is still
in testing.
- Updates to include ms-rdpedisp.h header for the 2.2.2 specification of
the protocol.
- Adds new dynamic_monitor_layout struct that shares the number of
monitors with xrdp_client_info.h
- Does not allow for BPP changes because the RDP protocol doesn't
support it.
- Option to disable feature as NeutrinoRDP doesn't support it (It was
based on FreeRDP 1.0.1 which didn't yet have this feature.)
- Add CLIENT_MONITOR_DATA_MAXIMUM_MONITORS constant and reference
spec definition.
Depends on https://github.com/neutrinolabs/xorgxrdp/pull/183
* Added s_rem(s) for getting the remaining bytes in a stream
* Added s_rem_out() macro
* Fixed 15bpp pointer error checking
* Combined the 512 and 2048 bit certificate sending code paths
* Other detailed comments and logging added following MS-RDPBCGR
This commit adds:
* replace multiple logging macros with LOG and LOG_DEVEL
* logging configuration for chanserv
* logging configuration for console output
* logging configuration for per file or method log level filtering for
debug builds
* file, line, and method name in log message for debug builds
If a server is multihomed (i.e. mutiple domains) the
users are identified by their domain name. This change
allows to concat the domain name to the username with
a specific separator.
This feature allows to embed a token in the username field. Tokens
are separated from the username by the ASCII field separator character
0x1F (unicode 0x001F).
The MS specs determine that the character buffer lenngths
for usernames, domains, passwords, alternate shells, etc
can be up to 512 characters including the mandatory null
terminator.
Constants from MS documents (MS-RDPBCGR etc) moved out of
common/xrdp_constants.h into includes named after the documents.
Similar includes moved from sesman/chansrv to the common area.
Actually, TLSv1.3 will be enabled without this change if xrdp is compiled
with OpenSSL or alternatives which support TLSv1.3. This commit makes to
enable or disable TLSv1.3 explicitly. Also, this commit adds a log
"TLSv1.3 enabled by config, but not supported by system OpenSSL". if
xrdp installation doesn't support TLSv1.3. It should be user-friendly.
If you run xrdp with a Unix Domain Socket (UDS) for the port specified in
/etc/xrdp/xrdp.ini then the first connection succeeds but subsequent
connections fail. In fact the UDS is deleted from the filesystem as soon
as the first connection is established.
Test case:
1. Edit /etc/xrdp/xrdp.ini to set "port=/var/run/xrdp-local.socket".
2. Restart xrdp.
3. Run the following. When rdesktop starts up and the logon dialog is
displayed, press "Cancel".
sudo socat TCP-LISTEN:12345 UNIX-CONNECT:/var/run/xrdp-local.socket &
rdesktop localhost:12345
4. Run the following:
sudo socat TCP-LISTEN:12346 UNIX-CONNECT:/var/run/xrdp-local.socket &
rdesktop localhost:12346
Expected behaviour: rdesktop starts up and displays the logon dialog.
Observed behaviour: rdesktop exits with "ERROR: Connection closed" and
socat exits with "No such file or directory.
This is because in the child process after forking, xrdp_listen_fork()
calls trans_delete() which deletes the UDS. Simply commenting out the
g_file_delete() and g_free() fixes this, but that isn't a proper solution
because trans_delete() is called from elsewhere where the UDS might no
longer be wanted.
Fix by adding a function trans_delete_from_child() that frees and clears
listen_filename before calling trans_delete(), and call the new function
from xrdp_listen_fork().
(Workaround: set "fork=false" in /etc/xrdp/xrdp.ini, because
trans_delete() is then not called.)
In common/arch.h, the endianness detection considers all powerpc
architectures as big endian. Since that is not true for ppc64el, I
added a verification that checks other preprocessor macros, only for
ppc cases.
Signed-off-by: Fernando Seiti Furusato <ferseiti@gmail.com>
make it possible to use regular (non EC) EDH ciphers. To make this
possible a Diffie-Hellman parameter must be passed to the openssl
library. There are a few options possible as described in the manuals at
[1] and [2]. Simplest approach is to generate a DH parameter using
openssl dhparam -C <lenght> and include the code into the application.
The lenght used for this commit is 2236 bits long, which is the longest
possible without risking backward incompatibilities with old systems as
stated in [1]. Newer systems should use ECDH anyway, so it makes sense
to keep this method as compatible with older system as possible.
Paramters longer than 2048 should still be secure enough at the time of
writing.
[1] https://wiki.openssl.org/index.php/Diffie-Hellman_parameters
[2] https://wiki.openssl.org/index.php/Manual:SSL_CTX_set_tmp_dh_callback(3)
because if xrdp is running 'fork=yes' mode, the log message
'shutting down log subsystem...' is logged everytime when the child
process is exitting. In other words, everytime when clients are
disconnecting. This is a little bit too vebose.
classify constants into these 5 types
* constants for xrdp
* constants come from ITU-T Recommendations
* constants come from Remote Desktop Protocol
* constants come from other MS products
* unclassified yet
