A significant proportion of Xpra's development was sponsored by the security industry to provide a shield for users securely running applications that require network access - the xpra clients are only exposed to a tightly controlled and secure network flux, completely removed from the underlying protocols that those applications normally use to interact with the user.
As a result, the architecture, features and options are often
directly related to the mechanisms that this fine grained control
requires.
These defenses can be applied to a client protecting itself from a
potentially hostile application or server and also in the opposite
direction to confine users to the environment assigned to them.
A default xpra installation should be quite secure by default, but there
are trade-offs to be made.
The way xpra is structured into independent python sub-modules allows
it to partition off each subsystem.
When features are disabled, they are not just unused, they are not
even loaded into memory in the first place. Those subsystem
interfaces cannot be abused since they don't even exist in that process
space - very much like when features are not installed on the system at
all.
For details, see dynamic client
connection class and completely skip
server base classes
The same principle applies to codecs and all swappable
components.
Moreover, the use of pure Python code for the vast majority of the data
handling completely prevents whole classes of vulnerabilities. The parts
of the code that do require high performance (data mangling,
(de)compression, etc) use heavily optimized libraries (see
audio and encodings below) - which are all
optional.
Most of the features below have explicit command line switches which
can be used to completely disable the subsystem, to start with the
feature turned off or to restrict the feature in its scope or
impact.
If a client or server turns off a subsystem then the remote end cannot
enable the feature. Some switches only affect the on / off state of the
feature instead, which does allow for the feature to be enabled through
a user action once the connection is established.
These toggles may also be accessible through the server's control
channel and dbus interface.
Obviously, from a security perspective, the safest clipboard is one
that is disabled (--clipboard=no
) but that is not always an
acceptable compromise for end users, in which case limiting the
--clipboard-direction
may be enough. Beyond this, there are
many other tunables in the clipboard
subsystem and its various OS specific implementations. This can be
used to restrict the rate and size of the data transferred, filter out
certain types of contents, select which clipboards can be accessed (for
platforms that support more than one clipboard type), the type of data
exchanged, etc.. Pictures transferred using the clipboard from server to
client are sanitized (re-encoded) and watermarked.
Very much like the clipboard, the safest way to handle audio is to
not forward it at all.
If audio forwarding has to be enabled, not all codecs are equal from a
security point of view.
Using a codec without a container reduces the complexity somewhat, but
using a raw audio format like wav
is the safest option
since there is no parsing involved. The downside is that this is an
uncompressed format, though xpra does offer the option to compress
wav
using lz4
. That said, mp3
is
now over 30 years old and the libraries parsing it are very mature.
Other codecs have had a few issues in more recent times (ie: faac and faad2
security issues
xpra runs the audio processing in a separate process which does not have
access to the display.
Xpra supports a large number of picture and video codecs as well as
raw uncompressed pixel data.
Each encoding option has different strengths and weaknesses. The raw
options rgb
and mmap
are obviously the safest
since they do not require any parsing, but they can require humongous
amounts of bandwidth (ie: tens of Gbps for a 4K window).
Older picture encodings like png
and jpeg
are
probably the safests due to their maturity. Video encodings as well as
newer picture encodings (often derived from the new generation of video
compression techniques, like webp
and avif
)
are probably less safe due to their level of complexity - see also
hardware access below.
Printer forwarding presents security challenges for both the server and the client:
This feature has potential for abuse in both directions which is why
there are many options to restrict what can be done with it.
File transfers can be disabled completely which is obviously the safest
option. The default settings allow file transfers but a user
confirmation is requested before accepting a file or opening it. The
file size and number of concurrent file transfers can also be
configured.
These features provide tighter desktop integration which can be seen
as a security risk and can be turned off completely.
However, the improved usability usually makes this an acceptable trade
off and these features are enabled by default.
Although this feature is never turned on by default, it is
available.
There are obvious privacy concerns here and it may be desirable to turn
off the feature completely.
DBus
"D-Bus is a message bus system, a simple way for applications to
talk to one another. In addition to interprocess communication,
D-Bus helps coordinate process lifecycle."
This makes dbus
both a very useful desktop environment
component and a wide attack target.
The limited --dbus-proxy
calls can safely be turned off and
the --dbus-control
channel should be turned off if
unused.
Any subsystem that accesses hardware directly is an inherent security
risk.
This includes: the NVENC encoder (see also
proxy server system integration), hardware OpenGL server and client acceleration, printer access and
some authentication modules.
Some features are harder to implement correctly in seamless mode because of the inherent
complexity of handling windows client side and synchronizing their
state. (ie: window resizing vs
readonly mode)
By definition, shadow mode gives access to the full desktop, without any
kind of restriction - for better or worse.
For these reasons, it may be worth considering desktop mode instead.
Xpra supports natively many different types of network connections
(tcp
, ssl
, ws
, wss
,
vnc
, ssh
, vsock
,
quic
, etc) and most of these can be encrypted and multiplexed through
a single port.
The safest option will depend on the type of xpra client connecting -
but generally speaking, ssl
, quic
and
ssh
are considered the safest as they provide host
verification and encryption in one protocol.
Each connection can also combine any number of authentication
modules.
Debugging tools and diagnostics can sometimes be at odds with good
security practices. When that happens, we usually err on the side of
caution but not always when it affects usability: http scripts
information disclosure
The extensive debug logging capabilities
normally obfuscate sensitive information like passwords and keys, but it
may still be possible to glean enough data to be present a real risk. A
good preventative measure is to disable remote logging and turn off the
server's control channel (#3573).
The xpra shell is a very powerful debugging feature which allows full
access to all the data structures held in the client and server. It is
disabled by default.
Servers should be using authentication, so typically this means that
malicious clients have had their authentication credentials compromised
or perhaps the whole clients is compromised.
Clients should be using SSL certificates or SSH host keys to verify the
identity of a server. A malicious server would be one that has been
compromised or which is running a compromised application (ie: a
browser).
As per the list above, if the specific subsystem is not disabled, a malicious actor may be able to:
Some specific options have a direct impact on the security of the system:
start-new-commands
this is precisely a remote command
execution and should be disabled if the client is not trustedterminate-children
should be used to prevent child
commands from lingering - most commands are killed when their connection
to the display is terminated, but some may surviveexit-with-children
to terminate servers when
applications are closedexit-with-client
to terminate when clients exitidle-timeout
to prevent unused client sessions from
consuming server resourcesserver-idle-timeout
to prevent unused servers from
consuming resourcesstart-via-proxy
causes the sessions to be registered
with the system's login service, which usually has the effect of moving
them to their own session control groupsystemd-run
runs the server in a transient systemd
scope unitproxy-start-sessions=yes|no
should be disabled if only
existing sessions should be accessed via the proxy serverdaemon
, chdir
, pidfile
,
log-dir
and log-file
: the server's filesystem
contextremote-xpra
the command executed from client SSH
connectionssource=SOURCE
and env=ENV
: anything that
modifies the server's environment variables can potentially be used to
subvert the server processsource-start=SOURCE_START
,
start-env=START_ENV
: as above, but for commands started by
the servermdns
will advertise sessions on local networksreadonly
sessions are unable to receive any keyboard or
pointer inputsharing
and lock
control if and when
sessions are transferred between clientsborder
, min-size
, max-size
,
modal-windows
: to distinguish and constrain remote
windowschallenge-handlers
to restrict the type of
authentication mechanisms the client will use (ie: prevent password
prompts)uinput
virtual devices should be avoided as they can be
used to inject input events into a system at a lower levelBy default, xpra is built using strict compilation options and any
warning will cause the build to fail (-Werror
).
Whenever needed or required (libraries missing in a specific
distribution or variant thereof), the xpra project provides up to date
versions of key libraries on many platforms:
https://github.com/Xpra-org/xpra/tree/master/packaging/ and not just
xpra. That said, binaries..
The distribution of binary bundles applies to MS Windows, MacOS
builds and also on Linux when using formats like appimage
,
flatpak
, snap
(these formats are not currently
supported, in part because of this particular problem) or - to a lesser
extent - with container builds.
The issue here is that by bundling all these libraries into one
container format (ie: EXE
or DMG
), it becomes
impossible to propagate library updates in a timely manner.
This means that it may take weeks or months before the patch for a
zero-day exploit is deployed.
Sadly, this is not a theoretical issue: pdfium 0-day, putty
vulnerability, tortoisesvn
unpatched security fix and many many more. The MS Windows libraries
are maintained by MSYS2, the MacOS
libraries are maintained using our fork of gtk-osx-build
Because of the way xpra intercepts and injects pointer and keyboard events - and the API it uses to perform these tasks, it is regularly misidentified as malware: f-secure and bitdefender false-positive, Microsoft AI
The builtin web server ships with fairly restrictive http headers and
content security policy, even blocking some valid
use cases by default - though we could go even
further.
For security issues related to the html5 client, please refer to xpra-html5 project
issues
On Linux systems that support it, xpra includes an SELinux policy to properly confine its server process whilst still giving it access to the paths and sockets it needs to function: https://github.com/Xpra-org/xpra/tree/master/fs/share/selinux
The xpra server and client(s) can both be embedded with or integrated
into other sotware components, this completely changes the security
profile of the solution.
For example:
Using containers or virtual machines is a very popular way of deploying xpra, both offer a strong extra security layer which can also be used to restrict access to system resources - though this limited access to the underlying hardware also restricts hardware acceleration options.
It is difficult to keep track of all the security related issues that
have affected the project over the years. Some have been assigned CVEs,
most have not.
Likewise, it is quite hard to keep track of all the bugs affecting the
libraries xpra is built on. But here are some examples: Rencode Denial Of
Service - rencode
segfault, brotli
integer overflow. (see also the "binaries" paragraph above which has
more platform specific examples)
By and large, the biggest concern is the complete lack of security
updates from downstream
distributions - even when faced with serious system
crashes.