LWN.net Weekly Edition for July 31, 2014

RPM Fusion, wiki defacement, and bug reporting

There are lots of ways to alert a project to a perceived security problem, but defacing its wiki is not high on anyone's preference list. Doing so does have one advantage, however: raising the visibility of the complaint—unfortunate though that may be. So, on the one hand, it is a truly obnoxious act, but on the other it draws attention to a problem that may have been languishing. A recent incident with the RPM Fusion project is a perfect demonstration of that.

RPM Fusion maintains a repository of RPMs for Fedora and Red Hat Enterprise Linux (RHEL). Those RPMs are for packages that Red Hat cannot or will not distribute for various reasons, typically legal issues such as patents. So, things like multimedia codecs, game system emulators, proprietary graphics drivers, and so on will be found in the repository. Three early repositories, Livna, Freshrpms, and Dribble, came together in 2007 to form RPM Fusion.

Users who wish to view internet videos or listen to MP3 files on their Fedora systems are likely to have added RPM Fusion as a source in their /etc/yum.repos.d directory by following the instructions on the RPM Fusion wiki. But those instructions were the target of some defacement on July 26.

A look at the history of the page shows multiple edits from Nikita Churaev (aka lamefun.x0r), interspersed with reverts from Nicolas Chauvet and Jonathan Dieter. The first change was evidently a test to see if a new user could edit the wiki to alter the download links for the packages that "install" RPM Fusion (i.e. place it into the system's Yum repository list). When that was successful, Churaev filed a bug in the project's Bugzilla noting that the initial download (install) of RPM Fusion is insecure. More defacement followed.

The complaints listed in the bug are quite sensible. Anyone can go in and change the wiki links, key IDs, key fingerprints, etc., to lead users to install malware. Even if those malicious edits are noticed and reverted quickly, there is still a window in time where users could be fooled. In addition, anyone can upload a GPG key to the public key servers that purports to be from the RPM Fusion project, so a malicious key that was listed on the wiki could easily be made to pass some basic sanity checks.

One possible malicious scenario would be for an attacker to change the key ID and fingerprints on the wiki to those of keys controlled by the attacker. Then, switching the links to the install packages to malicious versions would lead (some) users to download and install them, which would place the attacker's repository into the Yum configuration. That would allow the attacker to provide a steady stream of malware to the user that was disguised as RPM Fusion packages and all, seemingly, signed with an RPM Fusion key. There are other ugly possibilities too, of course.

One major underlying problem is that the wiki is not accessible over HTTPS, which allows for man-in-the-middle attacks. Clients using SSL/TLS (and checking the validity of the certificate) would be able to ensure that the web page data was coming from the project if that were offered. HTTPS wouldn't, of course, solve the problem of anyone being able to alter the wiki, but a static page or two with the key information that was served up over HTTPS would go a long way toward solving the problems Churaev is reporting.

In fact, an earlier bug filed by Churaev is explicit about that. That bug was filed at the end of 2012 and has seemingly not been touched since. More than a year and a half without any action on the bug appears to have been something of a trigger that led to the wiki defacement (which branched out further, to the wiki front page as well).

Dieter posted to the developers mailing list about the defacement problem. He recommended that the wiki be locked down. But Churaev was not impressed with that response, noting that the defacement problem had happened before, which should have served as a wakeup call. The thread died there, however, after two messages, which should probably be a bit worrisome to those who use RPM Fusion.

As Dieter pointed out in a comment on the most recent bug, though, insulting the project and defacing the wiki are not actually helping to solve the problems Churaev has identified. In fact, that kind of activity is counterproductive:

He went on to list some ideas for ways that Churaev could improve the situation. Others also commented on the bug report, expressing interest in helping to pay for an SSL certificate if that is what is needed. But, again, there was no official response. The bug is open, but so is the wiki. Project leaders are either not paying attention or not taking any visible action. That also should be a bit worrisome to users of the repository.

That's the real crux of the issue, in the end. It would seem that there have been a number of incidents (other defacements, Churaev's original bug report) that should have spurred action on these problems, but hasn't, for whatever reason. There probably isn't too much danger for attentive users, who are knowledgeable about keys, signatures, and the like, but the risk is certainly not zero. For less technical users, who might just follow instructions somewhat blindly, the risk is substantially higher—while still perhaps being fairly low in the grand scheme of things.

But the attitude of the project leaders matters. Even volunteers have some responsibility to secure their public sites, or to at least warn users of the risks. So far, at least, RPM Fusion has seemingly done neither. Those who use its repositories will want to keep that in mind.

It's a little hard to decide what to think of Churaev's role here. The situation is, in some ways, akin to companies that have vulnerabilities reported to them, but fail to take any action. In the past, that has led some to forgo the "responsible disclosure" path and simply to publicly report any bugs found. That is essentially what Churaev has done here—more or less, anyway. Will it lead to changes in the distribution of RPM Fusion's keys (at least)? It's an open question that is now at least more prominent than it had been ...

Comments (16 posted)

Matthew Garrett calls for the private, secure desktop

Various contributors to the GNOME project gather in person multiple times a year for various hackathons and meetings around the globe, but there is still something different about the annual GUADEC conference. Reports from the project's teams, question-and-answer opportunities with board, and the sheer size of the turnout all combine to make it an unofficial assessment-and-strategic-planning event. At GUADEC 2014 in Strasbourg, France, Matthew Garrett took advantage of that opportunity in his keynote talk; issuing a bold challenge to the project to make user safety and security its paramount concern for future releases.

Garrett's keynote was entitled "Why do we desktop?"—and by "we" he meant, specifically, GNOME. First, he asked, "what is the desktop?" It runs on your computer, he said, there is a mouse, and you can click on things and get some things accomplished. But beyond those generic aspects, what people do on "desktop" computers today bears little resemblance to what they did on the first desktop systems a few decades ago. The earliest desktops, he said, were basically multiplexors for running several terminals, and even the first Windows releases centered around running existing DOS programs simultaneously: the emphasis was on providing quick access to multiple streams of information, but users still worked the way they had been working before windowing systems. Plus, he added, they could keep a clock running next to their applications.

Things changed considerably in the 1990s, he continued, as operating system vendors redesigned their desktops to take advantage of Internet access. This was not always a success: he called out Microsoft's Active Desktop effort, in which the desktop itself was supposed to provide integrated Internet access. It frequently crashed and proved confusing, but it was a bold experiment. Vendors and users had both realized that not all of the relevant information had to originate from local applications.

Not much changed for a few years afterward, he said. Desktops got shinier and added translucency; users still wanted to display clocks, and could add multiple clocks to their desktop (sporting exotic themes). Technical changes like hardware-accelerated compositing and special effects became possible. But even then, Linux did not really break into the market in a big way until Google launched its Chromebook and Chromebox projects. At that point, the meaning of desktop changed again: the Chrome OS desktop only exists so that you can open more browser windows, he said. In a sense it replicates the old multiple-terminals model: the desktop is just there to provide access to several browser windows at the same time.

Current reality and adaptation

But "how desktops work" was not the only factor undergoing change over the years, Garrett said. How companies want you to work has also changed—and, largely, not for the better. More and more of our work is bound to our ability to access remote systems. At the same time, people do more of their computing on devices outside of desktops. The big concern, though, is that the commercial operating system vendors see this and have adapted to it for their own advantage.

Microsoft, he said, is adapting by pushing a tightly unified user experience across all of its products. A Windows 8 desktop, Windows tablet, and Windows phone all look exactly the same; on a recent visit to a Microsoft campus, Garrett said, he even noticed that the physical signage on the buildings and the ID badges perfectly reproduced the new Windows style, even down to the aspect ratios.

Apple's response has been different. Mac OS X does not look very different today than it did a decade ago, and it is still distinct from iOS. Instead, Apple is pursuing integrating these disparate platforms by tying them in to the company's platform applications. iTunes is used to manage devices and the desktop alike. The company's App Store works on the iPhone and on a Mac; much of what a user does on a computer can be performed through core Apple applications like iTunes.

Google, too, is trying to integrate its various OS form factors, though it is doing so by tying them all into Google services. That is to say, Chrome OS and Android do not look much alike; the code bases do not use the same components, except for the kernel and a few other individual pieces. But they are all deeply linked into Google services.

The point that often seems to get missed, he said, is that none of these adaptations are actually focused on the needs of the user. The commercial vendors' moves are all geared toward selling more of the company's products—either selling things to the user, or, in the case of Google, selling the user's data to others. They are not designed to increase the user's productivity, he said, much less to preserve the user's privacy.

New world desktops

The trend of desktop designs focusing on revenue rather than user's needs is a problem free software is poised to fix, Garrett said. Furthermore, the world itself is changing in ways that make fixing this problem paramount. As people already know, there are criminals who make a steady living stealing financial information or breaking into systems, locking out the owner, and extorting ransom. And as people have discovered recently, government agencies are actually using desktop software as an avenue to spy on citizens. The concept angers people, he said, as it should. But the commercial OS vendors are ignoring it.

The proper response, Garrett said, is not to try to build "a better desktop" (than the competition); it is to build "a different desktop" that has a different set of priorities. Most of the priorities Garrett enumerated will likely not surprise free-software advocates.

A desktop must be secure, he said; if an attacker compromises LibreOffice, the attacker should not also gain access to all of the user's data. It must also respect and preserve privacy, he said. Integrating communication channels with Tor is good, but not enough. Everyone knows that applications themselves leak personal data, too. Applications should, instead, recognize a "privacy mode" requested by the desktop environment and respect it. They should also make it easy for the user to know that their privacy is being safeguarded. Finally, such a desktop must be open to inspection, so that it is auditable and so that users can see what happens when a flaw is discovered and corrected. "We should be embarrassed when we fail," he said, "then we should fix the flaw and move forward."

If there is to be a desktop that makes these principles its priority, Garrett said, that desktop should be GNOME. GNOME is free from corporate control, he said, which is not even the case for other free software desktop projects. It is also transparent; the designs, discussions, and decisions in the project are open for everyone to see. And GNOME is a diverse project. That makes it capable of serving the needs of users from anywhere in the world.

Garrett pointed out current discussions and work within GNOME that fit his list of priorities: application sandboxing and Wayland, for example, are both vital for security. Other priorities might take new work. GTK+ widgets and window decorations could be made to change their appearance or color in response to privacy-protection features, for instance.

Although the audience was, to be sure, on Garrett's side during the discussion of priorities, he ended his talk by making a more direct challenge to the project, asking who the "GNOME user" should be. The audience replied with a perhaps predictable "everyone," but Garrett pointed out that this goal in fact means addressing some users who are typically left out.

Those ignored users include web developers, for instance. Garrett noted that he recently attended an OpenStack event and saw that the majority of the developers were writing open source Python code on Linux, but doing so over SSH sessions from their Apple laptops. At home, they used those same laptops to watch video and listen to music content on a proprietary operating system. OS X is not helping these people do their work, he said, but just as importantly, GNOME is not serving them the rest of the day, and it should.

Similarly, he said, free software is usually dismissive of gamers who play proprietary games. Steam has solved a lot of the problems with getting and running games on a Linux desktop, he said, but GNOME needs to care about these users, too, even if those users are not aligned with free software's philosophy. "They deserve to be secure, too, and to have as much privacy as we can give them," he said. Their interest in running proprietary software does not make them less deserving of security and privacy.

Ultimately, he concluded, GNOME needs to look at as many users as possible, and serve them. A desktop project that says "you didn't watch the news last week and install all of the security updates released in response to that vulnerability? Too bad; it's your fault" is not serving the user. The project will face challenges if it attempts to push forward on these points, "but if we don't do this, who will?" he asked.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2014.]

Comments (25 posted)

Wayland in GNOME: two progress reports

The X11 replacement protocol Wayland has been in development since 2010. Compared to X11 itself, it is still a relatively new project, but the enthusiasm with which distributions and large software projects announced their intent to support Wayland makes it at least understandable that users would ask how much longer they need to wait before Wayland is made available to them. At GUADEC 2014 in Strasbourg, France, a pair of talks presented the latest status of Wayland support in various GNOME desktop components.

The desktop and GTK+

Jasper St. Pierre presented an overview of GNOME's Wayland support on July 28. St. Pierre's talk started off with an atypical question-and-answer session as he debugged some last-minute problems with his current Wayland session in GNOME's Mutter. One audience member asked when Wayland would be available by default in a Linux distribution; in reply St. Pierre joked "I'll tell you at the end of this talk when it has run without crashing the whole session." More seriously, another audience member asked whether Wayland would support multiple copy/paste buffers; St. Pierre responded that nothing explicitly forbids it, but that in some places the protocol assumes it. Adding multiple buffers would require changing the protocol in ways that the Wayland developers "really don't want to do."

Although many in attendance were already familiar with X11's security problems, St. Pierre illustrated them at the top of his talk by showing a quick-and-dirty GTK+ program he had written that would exploit X11's lack of application isolation—by, among other things, logging keystrokes and drawing into another application's window. These insecurities are at the heart of GNOME's interest in switching to Wayland, he said. His keylogger could record passwords typed even when the GNOME screen-lock was active, he noted. There have been attempts to improve X security through extensions, he said, but they were "so complex to configure that even the SELinux people said 'we're not going to try implementing that.'"

But in addition to improving security by isolating each process's connection to the display server, Wayland offers GNOME real feature benefits, he said, such as automatic scaling of content on high-DPI monitors and real synchronization of redraws. The most common demos of Wayland, he explained, show off oddities like tilting windows to an angle. That understandably means little to users, he said, but to display developers it shows instantaneously that there are important things possible in Wayland that were impossible in X. Wayland will enable smoother redrawing when dragging and resizing windows. The current tearing and lag that users see is really a shortcoming in X, he said, but users often just blame GNOME or Linux in a generic sense.

The current state of GNOME support for Wayland is a mixed affair. The demonstration apps run quite well under GNOME's Mutter window manager, he said, but support for the GTK+ toolkit comes from the Wayland backend for the lower-level GIMP Drawing Kit (GDK) library, which he called "very, very iffy." Most noticeably, he said, is that GDK's Wayland backend is missing clipboard and drag-and-drop support.

Mutter support is also incomplete, as things are still stabilizing. "I just fixed screen recording support last week," he said. The stability of the Wayland version of Mutter also depends on which GPU driver is used, he explained. The Intel drivers are the most complete; the open-source drivers for NVIDIA chips are in between, while the closed-source NVIDIA drivers do not work with Wayland at all. The reason is that NVIDIA does not offer all of the functions that the open drivers require for Wayland; the company's binary X.org drivers are tied directly into X, so only the company can implement Wayland support for them.

Outstanding questions

In response to an audience question, St. Pierre further explained that supporting a new GPU, generally speaking, is not any harder under Wayland than under X. Supporting a new GPU on Linux essentially boils down to supporting mode setting and supporting direct rendering. Wayland support hinges on the direct-rendering aspect, but most of the work required to support a new GPU is the same for Wayland as it is for X.

There is also ongoing work to figure out how best to support taking screenshots of the whole desktop. Users expect the feature, but it has major security implications. If an application can take a screenshot unattended, it can also use that capability to record username/password combinations and other sensitive data. The straightforward solution is to force screenshot capture to require a user to verify the action; that would at least allow the user to detect if an unauthorized screenshot attempt is made.

St. Pierre spent a large portion of the session slot responding to questions. One question dealt with whether Wayland will be faster or more efficient than X11. It will certainly not be faster in the first few releases, St. Pierre said, but the potential is there for a lot of optimization work. For example, he said, a lot of video content is encoded in YUV color and has to be converted to RGB color for X. But many modern graphics chips support YUV natively; skipping that color-space conversion would be a big time-saver. In addition, he said, "performance" is sort of a generic term. A user might not see a noticeable frame-rate increase in Wayland, but would benefit from other performance improvements like lower CPU and memory overhead.

Another audience member asked whether Wayland would require applications to use client-side window decorations (which GNOME 3 implements but other desktops do not). St. Pierre responded that it would not; the subject is a longstanding debate, and no position has been written into the Wayland protocol. Making both options work was mostly a social problem to solve, not an engineering one, he said. If KWin decides it needs specific changes for its server-side window decorations, St. Pierre said, it is far better for him to sit down with maintainer Martin Gräßlin and come up with a handshake protocol than to try and work around the issue in Mutter.

Two other questions raised more difficult application-compatibility concerns. One person asked how Wayland's isolation of a process's window contents would affect graphics applications like GIMP and Pitivi, which often have a color-picker tool that lets the user copy a pixel's RGB value. St. Pierre replied that Wayland would not currently allow that feature. Similarly, in response to another question, he noted that Wayland will cause a lot of trouble for supporting (and reassigning) global keybindings.

When another audience member asked "how do we sell users on this change, if the fact is that GIMP doesn't work anymore but you can drag windows without tearing?" St. Pierre joked that "I installed Wayland and all I got was new bugs" t-shirts would become popular. The truth, he said, was that a lot of bugs will appear because of the switch, and that if that fact is not handled properly, there is a real risk that the most noticeable outcome will be people getting unhappy about the change.

WebKit

St. Pierre covered GNOME's Wayland support at the desktop environment and toolkit level, but Žan Doberšek followed up with a session specifically about Wayland support in the GTK+ version of WebKit, which GNOME uses for its Web browser and as the HTML renderer in several other applications.

In large part, he said, the WebKitGTK+ support for Wayland relies on the same GDK backend support as other applications. But there are also several factors unique to the WebKit case. First, GDK does not support hardware-accelerated video compositing, which WebKit needs for video playback. The solution the project has taken is "inventive," he said. Only specific HTML and CSS features trigger the need for the feature, so they can be treated as a special case. Under X, these compositing operations can be handed off to OpenGL.

But, under Wayland, that same technique is not allowed because it involves handing graphics to a separate process—a major security risk. Instead, WebKitGTK+ has its own nested Wayland compositor that runs inside the main UI process. Making this work required writing an extension to Wayland, but only a small one. It currently works on Intel graphics, but is less well supported elsewhere, because it relies on several specific OpenGL extensions.

The other troublesome factor confronting WebKitGTK+ is how to handle plugins. Opinion is divided, he said. "Personally, I don't want to tackle it because I want plugins to die," he added. The only solution that looks plausible, he said, is if there is reusable work from Mozilla's JavaScript-based, open-source Flash renderer.

The hardware-accelerated compositing work, though, is on track for a future release already. It could land in the WebKitGTK+ 2.6 version, he added, although there has not been a stable candidate released yet. Performance issues still have to be addressed, as does WebGL support.

Overall, there may not be a clear answer to the question of "when will GNOME have Wayland support?" But it is still helpful to see an update on the project's process. The WebKitGTK+ engine is one of the few special cases—most applications will rely on Mutter and GTK+ for their Wayland support—but, on the other hand, accessing the web is one of the most important uses of a modern desktop.

[The author would like to thank the GNOME Foundation for travel assistance to attend GUADEC 2014.]

Comments (53 posted)