LWN.net Weekly Edition for November 17, 2011

On the Android 4.0 release

It took a while and some questioned whether it would ever happen at all, but, on November 14, Google announced the availability of the source for version 4.0.1 ("ice cream sandwich") of the Android open source project. This news has been received with a fair amount of celebration, but also with a certain amount of criticism. Now might be a good time to think a bit about how Android interacts with the open source community and whether all of our expectations are where they should be.

What is there not to like about this release? One obvious problem is that it was so long in coming; there has not been a major Android release since 2.3 came out in December, 2010. Since then, the Android code (with the exception of the relatively small parts covered by the GPL license) has been developed and kept behind closed doors. Google's reasons for withholding the source have been explained and examined many times; some find them reasonable, while others do not. But it seems clear that the end result - no Android releases for almost a year - was not a good thing.

Complaints have also been heard about Google's refusal to provide tags for the "Honeycomb" release that was shipped on a handful of devices. The official reasoning is that Honeycomb was "a little incomplete" and that Google would rather see people focusing on the 4.0 release. A focus on the current code seems likely to happen naturally; it is hard to imagine that a whole lot of people will be interested in going through the pain of turning an old and "incomplete" version of the source into something that actually runs on a device when something newer is available. But there may well be people who want to reproduce something like the current binary installation on their devices before proceeding to something newer. Removing the tags and forcing those people to dig through the history for an appropriate commit does seem like a bit of gratuitous obnoxiousness.

On the other hand, if Google had really wanted to be difficult, it could have squashed out that history altogether.

People often complain that Android is not a real open source project. Such assertions are hard to argue against. Android's governance is very much controlled by its owning company. Releases of source are routinely withheld, albeit not usually for as long as was the case for 4.0. To gain access to the current source - to build a new product, for example - requires being a Friend of Google and agreeing to its requirements. The code contains certain antifeatures, such as applications that cannot be uninstalled and the inability to use cell-tower-based location services without reporting back to the mothership, that would probably not exist in a truly free project. And so on; Android clearly works differently than most true, community-oriented free software projects.

It is worth pointing such things out so that we are all clear on exactly what the Android project is. It can even make sense to grumble about them occasionally in the hopes that gentle pressure might cause some things to change over time. But there also comes a time to simply accept Android for what it is and make the best of it.

Let us remember that Android represents a gift of a vast amount of code that is truly free software. That code has become the basis for more open projects like CyanogenMod, where people have done some very fun things with it. The advent of Android has coincided with the arrival of a whole range of devices that are far more open than their predecessors. We now carry powerful computers with broadband network connections in our pockets, and we actually have some control over what runs on those computers. Anybody who wants to build a new platform with Android's capabilities has the software available to them, free of charge and free to modify.

Linux was doing well in the embedded world before Android; now it is pushing toward a point of world dominance. Manufacturers design devices with the idea that they will run Linux from the outset, and, increasingly, their work is flowing back into the mainline kernel as well. Android may be far from a traditional Linux distribution, but it's a base that is entirely capable of running real Linux applications for those who want to do so.

If Android had shoved aside a viable "real Linux" platform in the handset and tablet space, there might be at least a small basis for complaint. But it would be hard to argue that platforms like OpenMoko or MeeGo would have succeeded if Android had not come along and hogged the spotlight. For better or for worse, nobody has managed to put together an alternative Linux-based platform that has seen any adoption by the hardware vendors, and that's not Android's fault.

In fact, even now, there would appear to be space for another mobile platform. Admiration for Android is not universal, and manufacturers would love to have another viable option for their products; it should be possible to establish another contender. There are plenty of Linux-based projects trying to become that contender; the GNOME and KDE projects both have their eyes on that market, and Canonical evidently does as well. Whether any of them (or somebody else) can pull together an offering that succeeds there remains to be seen. Let us hope they can; it would be a shame if that space were to be occupied by another fully proprietary system instead.

Meanwhile we do have Android, and Android, for all its faults, is a gift of great value. It often seems that, as a community, we behave most harshly toward those who contribute the most to us. Let's not stop talking about how Android could be a better project from the community's point of view, but let's also not forget to say "thank you" for all that it is. With the 4.0 release, we once again have a whole bunch of code that we can do great things with; that merits a big "thanks!" from us all.

Comments (10 posted)

Safeguarding GNOME.org with an upload lockdown

Some effects of the kernel.org break-in were immediate, but others have rippled out more slowly. One example of the latter is the GNOME project's system administration team taking a hard look at the security of its own infrastructure. The team is drafting a plan to tighten down access to its servers and looking at the development processes of the project — starting with the module upload process.

Olav Vitters sent an email to the GNOME desktop-devel list on November 10 that outlines a plan to preemptively secure the master.gnome.org server against some preventable compromise paths. His root concern was that more than 350 GNOME developers have shell access, which provides a large attack surface even though most (if not all) of those accounts are used only to upload tar packages — a process that could be more securely performed in other ways. Considering the lengthy process that the kernel.org team had to undertake to restore the server after its compromise, the concern is a very real one.

The GNOME project maintains a variety of public-facing services on different machines (Bugzilla, mailing lists, wikis, web sites, etc.), which are managed by one full-time system administrator paid by the GNOME Foundation, and assisted by a small team of volunteers. Vitters is one of those volunteers. His message to the list, which he styled as an IETF-like "request for comments" (RFC), targeted just one service: the FTP server used to distribute GNOME tarballs.

In the current FTP release process, package maintainers upload tarballs to a GNOME project server using SCP, then log in over SSH and execute an "install-module" script. The script calculates the checksum(s) of the newly-uploaded package(s), copies them to the proper location in the public FTP directory, and triggers another script that starts an FTP sync between the GNOME project server and the "real" master FTP server (which is located off-site) and the official mirrors.

Restricted SSH and DOAP

Due to the interactive SSH step, Vitters said, if any of the 350-or-so package maintainers has their personal machine compromised, an attacker could gain shell access to the GNOME project FTP server. That was the path used by the kernel.org attackers, who then presumably used a local privilege escalation to completely compromise the machine. It is very probable that one or more of the GNOME user's machines has been compromised, but that has evidently not led to unauthorized access to the GNOME servers.

Vitters proposed a replacement module-upload plan, in which the initial file transfer would be performed with rrsync (the Perl-based program that restricts rsync to a pre-determined subdirectory) over an SSH tunnel. The user would then call a revised version of the install-module script remotely over SSH, where the SSH daemon on the server was configured to only permit execution of that script, rather than a full shell.

The server-side scripts already in use would also be modified to check the user account that uploaded the new file against a list of approved uploaders for the module, taken from the module's Description of a Project (DOAP) file. DOAP is an RDF format used to define the semantics of a project and its team; GNOME already stores DOAP files for each module in the project's Git repository.

The primary benefit of the plan is that it eliminates the need for the 350+ shell accounts. Even if a module maintainer's home machine is compromised, keeping the server locked down so that remote shell access is unavailable makes it more difficult to wreak large-scale havoc. It would still be possible to replace a package, but the identity check performed against DOAP would, in theory, mean that the attacker could only replace a small subset of packages for the majority of accounts. This is an improvement, because currently anyone with a shell account on the server can upload any package.

Vitters posed several questions for the list, starting with whether or not the proposed process was so much more arduous than the existing system that it would meet with resistance. But he also pointed out potential technical hurdles such as uncertainty over the reliability of rsync, whether rsync could be used to delete files, and the fact that although most GNOME modules have a DOAP file in Git, those GNOME modules that are not tracked using Git do not.

Reaction and feedback

Maciej Marcin Piechotka asked whether scp might be preferable to rsync, and suggested that the Git DOAP files are not secure, because anyone with Git access could upload a new DOAP file — a change less likely to be noticed by others than is the upload of a new tarball. Vitters replied that he considered, but ruled out, scp and sftp for the upload step because both permitted more file operations than rsync alone. In the interest of "just allowing exactly what is needed," he said, rsync was the better fit. "I don't want people to be able to modify anything [other] than uploading a tarball." He confirmed the vulnerability of the DOAP file in Git, and proposed modifying the upload scripts to notify existing maintainers whenever the DOAP file is modified.

Ray Strode then weighed in against restricting uploads to individuals in the DOAP file on the grounds that there are a lot of less-actively-maintained modules, and an unpredictable set of users who periodically need to make releases of them. "I think the lack of fine grained ACLs for this sort of thing is one part of GNOME that work better than projects that try to lock things down more aggressively," he said. Matthias Clasen and Bastien Nocera added that they were two such users, who occasionally update maintenance-mode modules when a change in such a module is mandated by an update to one of their own modules.

Vitters then suggested that the allowed-user-list could include the maintainers of each module plus all members of the release team, since both Clasen and Nocera are on the release team. Clasen and Nocera seemed happy with that adjustment, but Strode did not:

Strode's concern is not easily reconcilable with the overall plan, because it boils down to a philosophical, not a technical question: how locked-down is too locked-down. A lax security policy towards the less-frequently-updated modules simplifies the work for the administrators and allows more people to contribute, but the less-active modules are an easier target for attackers. Inserting malicious code into an actively-developed module is likely to get noticed in short order; by instead inserting it into a nearly-forgotten Makefile that is still pulled in and executed when building GNOME, one accomplishes the same goal with less risk of getting caught.

Alan Cox suggested that the team take a look at the tools used by the kernel.org team, which went through much the same locking-down process in September and October in response to the August break-in.

Lessons from kernel.org

The kernel.org lockdown began with the same concern as Vitters' RFC: eliminating the several-hundred shell accounts used mainly for uploading. Since the break-in, H. Peter Anvin has developed a suite of utilities for kernel.org that implement much the same process that Vitters is pursuing for the GNOME FTP server. Namely, allowing secure uploads, with access control measures limiting what individual users can upload, and without requiring shell access on the receiving machine. Anvin's work is the kernel.org upload tool, or "kup." It includes an upload client called kup and a server-side script called kup-server.

The kup-server script needs to be modified for each user account, to specify the pathnames for allowable uploads, Git trees, lock files, and the user's public keyring. The keyring file is read-only, and is used to verify signatures; kup-server checks that uploads are signed with a trusted OpenPGP key. Establishing the trust between the identities and keys was one of the lengthiest parts of bringing kernel.org back online.

Beyond simply utilizing a custom client instead of rsync, there are other differences, between kup and the GNOME.org proposal. The kup client contains multiple levels of sanity checks, even dry-running the requested commands in order to trap errors. It also supports other file operations in addition to uploads, including deletion, moving/renaming files, and creating links.

In addition, David Woodhouse said that he has set up a two-factor authentication scheme for kernel.org that has not yet been rolled out. It requires that users have both an SSH key and a one-time-password (OTP) generated by Google Authenticator. Google Authenticator includes a PAM module to secure applications, and a collection of OTP generators for various mobile phone OSes.

As of press time, Vitters told the list that he had gotten in touch with Anvin to follow-up about kup, but has not yet announced any alterations to the GNOME FTP proposal based on those conversations. The kernel.org team learned the hard way how much hassle a break-in on an upload server can produce. Although other, somewhat lower-profile projects may not present nearly as enticing an objective for attackers, they can learn from its example, and it is good to see GNOME undertaking a preventative lock-down. One hopes that the project is also taking steps to ensure that its infrastructure is not already compromised as well.

Ultimately a more secure infrastructure may inconvenience package maintainers, system administrators, and developers that (like Strode) prefer a less formal structure, but for a project of any size, what other choice is there? Package uploading and verification requires a security policy; it is too inviting of a target to not lock it down.

Comments (3 posted)

Awesome: A window manager that gets out of the way

Sabayon Linux, the easy-to-use Linux distribution built on top of Gentoo Linux, recently announced three new experimental editions that supplement their previous GNOME, KDE, Xfce, and Core releases. Two of the new experimental editions are equipped with unsurprising desktop environments: LXDE and E17 (Enlightenment). The third desktop choice, however, is surprising: the awesome window manager.

Awesome is no stranger to me: I have been using it for three years as the window manager on my main work computer because it's highly configurable and visually minimalistic, so I can focus on my work without any distractions. It's not so surprising that awesome isn't popular, as it's going up against modern desktop environments like GNOME 3, KDE 4 and Unity. In contrast to those desktop environments, awesome doesn't want to appeal to non-expert users, doesn't offer an Apple-like experience, and doesn't come with all kinds of bells and whistles. This makes it even more interesting that a mainstream distribution like Sabayon chose to include an edition with awesome.

A framework window manager

Awesome is called "a highly configurable, next generation framework window manager for X" by its developers. By "framework window manager" they mean that users actually build their own window manager with awesome: while it's usable with the default configuration, it is meant to be extended and configured by the user. Because of this, awesome is primarily targeted at power users, developers, and anyone who wants to have fine-grained control over their graphical environment. In contrast, if you don't like tweaking your system or if you like out-of-the-box bells and whistles, awesome probably isn't for you.

Awesome has a small code base and memory footprint and is fast. Because it's using the asynchronous XCB library instead of the synchronous Xlib, it also promises less latency than other window managers, at least according to the home page. It prides itself on implementing many Freedesktop standards, such as EWMH (Extended Window Manager Hints) that allows programs to give hints to the window manager about the type of their windows, Desktop Notification to provide popup notifications on the desktop, System Tray to display small icons provided by running applications, and D-Bus for interprocess communication. And it even supports multiple monitors in XRandR, Xinerama, and Zaphod mode. So while it's a minimalist window manager, it doesn't fall short in its features.

Everyday working with awesome

By default, awesome has a simple but already quite usable configuration that will even support multiple monitors. When you start an awesome X session, you'll see a minimalist desktop with a status bar on top of the screen. Awesome can be controlled completely with the keyboard, so you'll have to memorize some keyboard shortcuts to become proficient at it. For instance, Win+Enter opens a new terminal window (Win is the key with the Windows logo, called Mod4 in awesome's documentation and configuration file), Win+j cycles through the windows, Win+h or l resizes a window (but Win+right-click and dragging with the mouse is a bit more convenient), Win+Shift+j or k moves a window (as does Win+left-click and dragging with the mouse). With Win+Shift+c you close the focused window. Starting a program is simple: enter Win+r, after which you see a "Run:" prompt in the status bar and you can type a program name (with tab completion). It pays to read ~/.config/awesome/rc.lua a bit to get to know all these keyboard shortcuts. When you're used to them, awesome lets you really manage your windows in a very efficient way.

By default, awesome behaves like a regular stacking window manager, but it started as a tiling window manager and I still find this mode the most efficient to use. Just click on the icon in the upper right to use the tiled layout. When you open your first window, it covers the whole screen, and subsequently opened windows are tiled automatically alongside the other windows, so the available screen real estate is always covered completely unless you have no windows open. By default, the most recent window is shown at the entire left part of the screen and the other ones are automatically rearranged on the right side. You don't have to juggle with your windows to get the most out of your screen; awesome does the job for you. By the way, there are no title bars attached to the windows by default, although you can change that in the configuration file.

The status bar at the top of the screen shows nine numbers by default at its leftmost part. If you click on one of them, you get a completely empty screen, ready to contain some new windows. Superficially, this looks like the workspace concept in many other desktop environments, but in awesome they are called tags and the relationship is backwards: while a workspace contains windows, in awesome tags belong to a window. This means that a single window can have multiple tags, but you can also view multiple tags together by right-clicking on another tag in the status bar. The nine tags can be reconfigured to have more descriptive names, although you probably should keep them short. For instance, I have tags "read", "talk", "surf", "type", "file", "hear" and "root". All in all, the concept of tags is much more flexible than traditional workspaces.

To the right of the tag list comes the task list, which is the list of windows on the currently visible tag(s). To the right of that, there's the clock, and at the rightmost part of the status bar is the layout box which we already mentioned earlier. If you click on it, the way in which awesome arranges all visible windows changes. You can cycle through all available layouts with left-click (forward) and right-click (backward) or by using Win+Space. There's a spiral layout, a maximized layout (which only shows the focused window), a fullscreen layout (which even covers the status bar), a magnifier layout (which shows the focused window in the middle and the other ones on the background) and a floating layout, which shows all windows free-floating and covering each other, like you're used to from stacking window managers.

You can also toggle the floating/tiled status of the focused window with Win+Ctrl+Space and you can configure awesome to automatically force specific programs (like GIMP) to always float. You can also set the default layout programmatically in the configuration file. For instance, I have set the layout of my left screen to tiled and the layout of my right screen (which stands in portrait mode) to tiled.bottom, which tiles the windows vertically. This kind of personalization is very easy to do in awesome.

Tuning your desktop environment

Awesome is just a window manager, so, by default, a lot of functionality offered by a complete desktop environment will be missing. But most of this functionality can be added to the configuration file or supplemented by external programs. The upside is that you can pick your components: you can for instance choose lightweight alternatives. The downside is that you have to configure a lot of things that come out-of-the-box with a desktop environment such as GNOME or KDE and you have to add many programs to your awesome key bindings or to your ~/.xinitrc before you have a working desktop environment with things like an automounter, a file manager, a network applet or a screen shot program. You can also add widgets to the status bar, e.g. a systray, graphs of the memory or CPU usage, and so on.

If you like the complete desktop environment that GNOME or KDE is offering and you just want to swap their default window manager for awesome, that's also possible. This gives you your familiar desktop environment, but with the much more flexible window management functionality of awesome. Have a look at the wiki on how to set up awesome with GNOME or with KDE.

Some programs have to be tuned to be able to use them well with awesome. For instance, if someone mentions you on IRC when you're using the irssi client, the tag associated with your irssi client can become orange (or whatever color you have configured in your awesome theme) by setting up a couple of things. There are also some problems with Java programs when you use a Java virtual machine older than version 1.7, but most issues can be overcome.

Development

Awesome began in September 2007 as a fork of dwm, an extremely minimalist window manager which can only be customized through editing its source code (all options meant to be user-configurable are contained in a single header file). Debian developer Julien Danjou liked dwm's minimalism, but wanted it to have an external configuration file. In version 3.0, he decided to use the programming language Lua for the configuration file format.

Danjou is still the primary author of awesome, but there are a lot of other contributors, and Uli Schlachter maintains awesome now. After a frantic development speed the first two years, development has slowed down now, with the latest release, 3.4.10, being made on May 16 along with a rather low number of commits in the project's repository. In an email interview, Danjou said that the reason for the slowdown is simple:

Although one could say awesome is finished now, there's an active community of users and the wiki is a goldmine for resources, including some user configuration files, themes, user-contributed widgets, and example screenshots. Awesome is available in the repositories of a lot of Linux distributions (but surprisingly not in Fedora), and also in the BSDs. Some of these distributions have their own wiki pages with a guide and distro-specific information, such as Arch Linux and Gentoo.

Tune it now

Although awesome is not an easy program to learn, the framework window manager invites you to experiment with and tune your desktop environment. For instance, you can modify your rc.lua file and restart awesome for these changes to have effect with a simple Win+Ctrl+r. To get some idea of the possibilities, have a look at all the signals awesome emits, to which you can hook your own handler functions. If you dislike the way how GNOME, KDE, and Unity are evolving and you want a window manager that you can tune to get out of your way, you definitely should take a look at awesome. For a quick glance, try the new Sabayon 7 Awesome edition.

Comments (52 posted)

Page editor: Jonathan Corbet

Inside this week's LWN.net Weekly Edition

• Security: Distribution security response; New vulnerabilities in lightdm, Mozilla products, proftpd, wireshark, ...
• Kernel: Huge pages, slow drives, and long delays; Reverting disk aliases?; Reworking the DMA mapping code.
• Distributions: Fuduntu: A small distribution making it big; Android, Mandriva, openSUSE, ...
• Development: Raw photo manipulation with Darktable; IMAPclient, SciPy, Valgrind, ...
• Announcements: AVM vs. Cybits, W3C privacy workgroup, EFF on Internet innovation, ColorHug...

Next page: Security>>