The X Window System strives for security
by Andy Oram
In one sense, the venerable X Window System has achieved a kind of
security I did not expect it to have: not security in the technical
sense, but security in its role as part of the future of computing.
Just a couple years ago, it appeared that X was joining the hoards of
legacy protocols that would hang on awkwardly in backwaters while the
rest of the world moved forward (at least, some people claim it is
forward) to Windows and OS X.
But then Linux on the desktop became a topic of everyday conversation.
And while Linux on the desktop is just beginning to take hold, it's
showing signs of staying. The X Window System has a secure place in
end-user computing. (And I'm not even considering here the potential
for X on embedded devices.)
OK, let's get serious now and talk about technical security. This was
the subject to which Wednesday afternoon was devoted at the intimate,
informal X Developer's Conference taking place this week in Cambridge,
Massachusetts. Since the ideas tossed around were speculative and
uncoordinated, I will heavily embellish what I heard with my own
interpretations. And that means I take responsibility for any
technical inaccuracies that appear in this weblog.
Security is normally something one worries about with files and
daemons. When an X server and client communicate over a network, of
course, one might be concerned with encrypting the communications to
protect passwords and other data entered. But subverting a window on
your screen doesn't seem to pose a threat on the level of altering the
/etc/password file or grabbing hold of a Sendmail hub server.
Still, security is enough to worry many potential users of Linux. For
instance, as Eamon Walsh of the SELinux team said, "There are weird
things you can do with the X server." For instance, clients can do
what's called a "server grab," which essentially locks the mouse,
keyboard, and every other element controlled by the server for as long
as the client desires. If the client desires to keep it indefinitely,
the only way to kill the client is to find a different physical
terminal or remote system to log into.
It would also be nice, as one attendee at the conference suggested, to
allow someone to view a document labeled Top Secret without allowing
her to cut and paste material from it into another window. This is a
subtle problem involving permissions between two programs and X
Needless to say, as a relatively old protocol from the 1980s, X was
not designed for security from the bottom up. Jim McQuillan, creator
Linux Terminal Server Project,
listed several ways one could achieve secure X communications:
X over SSH (what his customers tend to use)
NFS 4 (the most recent version, which has security built in)
Clearly these each operate at a different level. They also require
different types and amounts of configuration.
I caught som of the presentation by Eamon Walsh of the SELinux team on
"Fine-Grained Access Control for X." Whereas the most popular ways of
controlling access for X (SSH and Kerberos) work at the session level,
an SELinux extension for X could protect particular windows.
Authentication information could be passed when the user logs in for
the X session. Then, for each window, authentication information could
be stored along with authorization information taken from SELinux
Walsh is working on a set of hooks in X called XACE. Like Linux
Security Modules, XACE will allow an administrator to plug in the
SELinux extension or others that come along. The SELinux teams' work
was welcomed by conference attendees, but the large amount of
configuration was questioned (particularly the proper choice of
policies, which tend to get very big and complicated in SELinux).
It's tempting to take the encryption and authentication features from
SSH and build them into X, tailoring them for its particular
needs. But because there is no stand-alone SSH library, extracting its
essence in this manner would mean forking the project, with all the
bad consequences that normally entails.
This was part of an extensive presentation on possibilities for X
security given by Ted Ts'o. Ts'o is well-known for his work on the
Linux kernel, but also led the Kerberos development team at MIT and
put Kerberos support into X.
Ts'o built on McQuillan's talk by suggesting that there were many ways
to successfully achieve security in X, and that the key was to
determine the requirements of a particular environment.
For instance, SSH is great for a dozen or so users over a network. But
it has problems scaling. For one thing, each user has his own SSH
session with the remote server. Second, X over SSH requires an extra
trip through the kernel, with the resultant potential for extra delays
due to scheduling. Third, each SSH session requires configuration on
both remote host and local client system; as the number of systems
grows, the number of configurations grows geometrically. Imagine
cleaning up old configuration lines as employees or students leave the
Kerberos provides a centralized and therefore more scalable solution,
but it takes much more effort to install and configure than SSH. So
it's appropriate for large sites.
I got the impression, during these talks, that several fundamental
aspects of security make it difficult to achieve with X.
First, X is a highly distributed protocol. Each connection between
each application (client) and server is independent.
In contrast, security tends to thrive on centralization. Think of
passports, drivers licenses, and credit cards, all issued by
centralized authorities with varying guards against forgery. Think of
certificate authorities, the centralized solution to proving
identity. Think also of PAM, the common basis for introducing
different types of security into the Linux kernel.
The attendees at the X conference spent quite a lot of time looking at
PAM. There was also a brief consideration, which flew by in about
thirty seconds, for centralizing access by all clients so that
security between the clients and server could be handled locally.
After the centralization/decentralization issue, one comes across the
bewildering choice of layers. For instance, SSH operates at the
application layer. It seems to me that this is why it's relatively
inefficient for the purposes of securing X. In contrast, IPSEC
operates deep at a nicely buried layer, but that means that its
information is unavailable to X. (Ts'o said that X cannot currently
tell whether IPSEC security is in effect, much less extract the
signature used to sign an IPSEC session.)
Aside from security, another of the discussions I had the privilege to
listen in on concerned a possible move to the OpenGL 3D interface. Jon
Smirl, a product marketer in the open source area, claimed that OpenGL
was valuable even for applications that did not do 3D graphics; the
acceleration provided would benefit all graphic displays. He pointed
out that a growing number of graphics cards offer the OpenGL interface
and perform a growing amount of 3D in hardware (the move being
encouraged by the growing bandwidth available between CPUs and
graphics processors). X needs to settle on OpenGL to achieve
OpenGL, however, is only a part of the strategy Smirl said that Linux
and the open source community needed to compete with Microsoft. He and
others backed up a widely-circulated warning, given by Miguel de Icaza
in a recent
concerning the convenient mark-up language developed by Microsoft
under the name XAML.
XAML, sometimes superficially called "the Microsoft XUL," is a
linchpin in Microsoft's Longhorn strategy to eliminate the difference
between local application development and Web development. As a
technical development, the strategy intrigues Smirl, and he called it
the next big evolution in end-user computing after GUIs and the
Internet. However, many fear that if Microsoft succeeds in pushing
XAML out so that it becomes part of large numbers of Web pages, the
Internet will turn into a Microsoft walled garden--and that will be
the end of competition.
After Smirl explained why it was important to support the newest in 3D
hardware and software, a developer of Sun's
desktop interface and two developers from HP's
project showed what could be done with these capabilities.
Concerning Looking Glass, I'll just say that once you view a demo and
take a step into this graphical interface, you won't glance backward.
Croquet is both an advanced 3D interface and a networking
collaboration tool. Its motivation was explained on an impressively
deep level by developer David P. Reed, a pioneer in TCP/IP who is
well-known for co-authoring a
on the "end-to-end" concept in networking. Reed said that current
applications were still assuming written for the lowest common
denominator in network bandwidth, but that it was time to write for
cable modems or better.
That said, Croquet requires only a a few tens of kilobits in bandwidth
most of the time to achieve real-time collaboration with richly
textured 3D objects. It achieves this efficiency partly through
classic P2P processing, letting each system do rendering and any other
possible calculations on its own. Large, short bursts of bandwidth are
required for occasional complex messages, such as the creation of new
objects. Since a quickly emerging new generation of PDAs will have 3D
acceleration, environments such as Croquet could become widespread.
The X Developer's Conference overall was a very pleasant, serious,
working event with about thirty attendees. It was organized by X
founder Jim Gettys and held at a gorgeous location at Hewlett Packard,
his current employer, on the top floors of a building in East
Cambridge. Somehow it seems appropriate to have beautiful views right
outside the hall when you're discussing graphics. It was also an honor
to be just one block from MIT, where X--along with Kerberos and so
many other worthy free software technologies--was invented. Some of us
also remember that the conference is two blocks from the offices of
the Open Software Foundation, the distributors of the Motif toolkit
that at one time was considered the cat's meow for X
development. (Yes, it really was.)
What will make X ready for the modern graphical era?