Leading items

The Grumpy Editor's Moblin review

Despite your editor's affection for electronic toys, he has, thus far, managed to avoid cluttering his desk with a netbook system. Until now. It seemed like it was past time for a closer look at Moblin, and it further seemed that a distribution designed for netbooks should be experienced on one. So, it didn't take long for your editor to come into possession of a Dell "Mini 10v", which ships with the Ubuntu Moblin remix preinstalled. The 10v is a cute little system, but it is, alas, saddled with a free-software-unfriendly Broadcom chipset. Needless to say, the version of Ubuntu shipped on the hardware includes the binary driver needed to make that chipset work.

Much hype has been generated about Moblin's extra-fast booting behavior. A quick check with the stopwatch shows that this system requires 27 seconds from when the BIOS completes its power-on ablutions until the login screen appears. That is a definite improvement over a number of other systems, but it's not quite, yet, the five seconds that the Moblin folks have been aiming for. Suspend and resume are both quite fast; opening the lid yields a working system within 2-3 seconds.

The Moblin experience starts at the "MyZone" screen, containing calendar and "to do" items, icons for a few favorite applications, a set of screens from recently-run applications, and an area meant to contain communications from online friends. When an application is running, all of the "MyZone" stuff goes away, leaving the full screen for whatever the user is working on at the time. Screen space is generally at a premium on netbooks, so Moblin goes out of its way to waste as little of it as possible.

A core feature of the Moblin interface is "zones." These are really just the virtual desktops or workspaces that Linux users have been using since before Linux existed. On a small screen, though, there is little value in having more than one application on-screen at a time, so Moblin usually starts each application in its own zone. Switching between applications normally requires moving between zones.

There is a task bar which can be obtained by moving the pointer to the top of the screen. A quick look at this bar is enough to clarify the things that Moblin's designers think netbook users will want to do. Top-level tasks in Moblin include adjusting one's online social networking status, connecting to people, running a web browser, running a media player, and accessing a "pasteboard." There are icons for battery and networking status, one for moving between zones, and one for "applications" which is the path toward any other programs the user might want to run. Users who buy a netbook to support extensive twitter activity, watch videos, and view the occasional web page will be more than pleased with Moblin. Those wanting to do kernel development are likely to find this environment to be somewhat irritating.

Your editor has been using computers for quite some time; the notion that one can get a program into a system without punching it onto cards first still seems novel at times. To your editor's eyes, the Moblin environment has the feel of a toy. Lots of bright pastel colors assault the eye. Picture thumbnails dance around each other before lining up in pretty little rows. Dialog windows bounce on the screen in ways which risk inducing motion sickness. It's all very cute and joyful and social; Moblin is clearly not aimed at a typical longtime desktop Linux user.

Another choice which makes it clear that your editor is not in the target audience: this is the first distribution encountered in years which does not come with an SSH client. This kind of problem is easily fixed - the entire Ubuntu repository is accessible to people who dig far enough into the menus - but it is a bit of a surprise.

This machine arrived with an Ubuntu 9.04-based system running Moblin 2.0. This distribution, it must be said, has some rough edges. OpenOffice.org comes up with a dialog whose buttons are below the bottom of the window, which, in turn, refuses to let the user resize it (see image to the right). The mail client features color choices which sometimes render text unreadable. There are no bookmarks in the web browser; this browser also thinks that users want their searches to go to Yahoo. Windows vanish abruptly from the screen, losing whatever work may be in progress. Dell's page notes that the system is for early adopters; that certainly seems to be the case.

One should note that 9.04 is not the current version of Ubuntu, and 2.0 is not the current version of Moblin. There is a newer version of the Moblin build, based on the 9.10 release. The download page nicely offers a CD image of this release, seemingly unaware of the fact that a lot of netbooks lack CD drives. Ubuntu has a tool (usb-creator) which will create a bootable USB device from a CD image; too bad that its window is much taller than a typical netbook screen, making the crucial buttons unreachable. Your editor finally got past that little problem and was able to create a bootable Ubuntu 9.10 device.

The result was a very sluggish, very brown, but a generally slicker-looking Moblin installation. The software installation feature has been made more prominent, and the list of available applications has grown. Moblin 2.1 lacks support for the Broadcom wireless adapter found in this device, but that is not really Moblin's fault. The web browser still leaves much to be desired - strange, because Moblin 2.1 has made a number of improvements in that area. One other thing your editor noticed with both Ubuntu versions: the power consumption seems high. Running PowerTop shows a steady state of anywhere between 100 and 350 wakeups/second - not the way to get the most from one's battery. Moblin is supposed to be better than that.

Your editor decided to go straight to the source: the Moblin.org download page, which offers an image which works nicely from a USB stick. Some things have not really improved: it still takes 30 seconds to boot the system (though it should be noted that the use of a USB stick will slow things somewhat). But 30 seconds beats the few minutes that USB-based Ubuntu required, and the system is more responsive thereafter as well. And there are some improvements to be seen in this version of the distribution.

For example, the web browser (a Mozilla derivative) is indeed improved: it now has support for bookmarks, extensions, and a full set of preferences to tweak. This version of Moblin comes with its own package installer backed by Moblin's repository; users can install real applications like Thunderbird or AbiWord, but the package selection is far smaller than found with Ubuntu 9.10. Interestingly, OpenOffice.org is not available for this build - a surprise, given how many people your editor has seen running presentations from netbooks over the last year.

The official Moblin build is indeed more power-efficient, though it still runs at 80-90 wakeups/second, which is too many. All told, Moblin feels a little bit like an unfinished product, still.

In general, your editor is not really sold on the netbook idea. The screen is too small to get much serious work done, and the aspect ratio is wrong for any sort of text-oriented work. The keyboard tends to be just big enough to tempt the user to try to really type on it. And, frankly, Moblin-like software just tends to get in the way of a user who is used to the full Linux desktop experience and who does not spend a lot of time on Twitter. Chances are good that this particular netbook will eventually find itself running a more traditional Linux distribution.

But, as has been noted already, your editor is clearly not the market that these systems are aimed at. Not yet, at least. There are some very interesting changes happening in the area of consumer-level computers, where the traditional desktop idea seems to be slowly falling out of favor. Many experiments are underway to come up with something better; in the free software world these experiments have names like Android, Chromium OS, Litl, Maemo, and Moblin. Free software is trying to break new ground here; this is not a case of following somebody else's taillights. So, while your editor does not see Moblin as his system of choice at the moment, he is most interested in seeing where this project goes in the near future.

Comments (44 posted)

Fedora 12 and unprivileged package installation

Fedora 12 was released on November 17 with the usual pile of new packages and features. By the sounds, it is a solid, well-received release. But one feature—unpublicized, undocumented, and turned on by default—has a number of Fedora users up in arms, leading to a huge thread on fedora-devel, in the bugzilla entry, and here at LWN. In short, the problem was that in the Fedora 12 default installation, regular users sitting at the console could install signed packages from any repository that the administrator has enabled.

Since the release, and all of the publicity and complaints, the maintainers of PackageKit have decided to remove the feature. Out of this controversy, though, are lessons for any project regarding security, transparency, and system defaults. There were no real complaints about the existence of the feature, rather it was the choice to make it the default, coupled with a lack of any notice of the change, that led to the outcry.

Unprivileged package installation

Non-root install is a convenience feature, and one that was supported somewhat differently in earlier Fedoras. From F9 through F11, the same effect could be achieved by using PackageKit to install a package, entering the root password, and checking a box to allow that user to install in the future without needing to enter the root password. The key difference is that in F12, no root password is ever required; the checkbox has been removed and is treated as if it was turned on for all users.

PackageKit goes to some lengths to determine that the user is logged on at the physical console of the machine before allowing non-root installs. It only allows installation of packages, not update or removal, and requires that the packages are signed by a key that has been installed by root. The only repositories that are allowed to be used are those that were previously configured and enabled by a root user.

The use case is for single-user (or all trusted user) systems, where the logged-in user is likely to be the same person as the root user. Some people evidently don't like having to enter the root password, or, worse, having to track down the person with the root password, when they install software. It is part of the effort to simplify the desktop experience, with package installation being considered a "routine" task that many users would like to be able to do without the extra password-entering step. But that has serious security implications.

So, why wasn't the previous behavior just propagated into F12? It turns out that the PolicyKit feature that was used (auth_admin_keep_always) was eliminated between PolicyKit 0.9 and 1.0, because it was considered to be a security problem. Because F12 uses PolicyKit 1.0, it makes it difficult to just revert to the old behavior. Instead, PackageKit maintainer Richard Hughes has decided to change the policy such that the root password will always be required for installing packages on F12. An alternative was proposed by Kevin Kofler that may allow the earlier behavior to return without the PolicyKit support, though it is unclear whether it is being considered.

Security ramifications

It didn't take much thought for various folks to come up with security issues with the new feature. Even for the stated use case, allowing unprivileged package installation has some fairly significant implications. The idea that running on the console somehow makes a process trusted is dubious at best. Firefox is an excellent example of a program that regularly has flaws which may lead to arbitrary code execution. That means that attackers on the web may be able to install packages on F12 systems.

But the proponents of this feature insist that there is no risk to installing trusted packages from trusted repositories. There are a number of problems with that thinking, starting with the fact that there are, without question, "trusted" packages in the Fedora repositories today that have privilege escalation and other security flaws. Trusting a repository does not in any way imply trusting every package in it. Administrators may well have added other repositories to pick up a package or two as well, without considering the fact that they have now opened up their systems to all of the packages contained in that, less trusted, repository.

There is also an incident that some are conveniently forgetting. In August 2008, there was some kind of break-in to the Fedora project servers, including the system used for signing packages. There is no evidence that malicious packages were signed at that time, but it is always a possibility in the future. During the time when Fedora was figuring out what happened, and issuing new signing keys, users were warned not to update their systems. But, if console applications can be subverted to do that installation, one can easily see a path to mass compromise of Fedora systems.

Because of the way this was changed, administrators who upgraded to F12 will find that the privileges of the users on their system have suddenly been elevated. Because PackageKit and PolicyKit are relatively new additions, many administrators may be largely unaware of them and their capabilities. Eliminating PackageKit is one way to avoid the current problem, but other, seemingly unrelated packages are dependent on it; setroubleshoot for example. Because PackageKit and PolicyKit function in ways that are very different from the traditional UNIX security model, it is imperative that Fedora protect its users from unexpected security holes, at least in the default installation.

SELinux hacker James Morris has a summary of the problems that can occur, including such things as denial of service from exhausting the disk space on the system. A user could also install an SELinux policy that is weaker than that installed by the administrator, leading to an overall reduction in the security of the system. Overall, the implications of this change were not fully explored before it was added to F12.

Defense

The main defense of the PackageKit behavior seems to be that any attacker who has physical access to the machine has many ways to subvert it. Hughes listed a number of other actions that a normal user can do in F12, some of which could certainly be considered security issues. Those don't make for a valid reason for the PackageKit changes, though, as Rick L. Vinyard Jr. points out: "Perhaps those should also be discussed and analyzed further, but that doesn't serve as a justification for the matter at hand."

There are multiple scenarios where console access does not imply access to the machine. A monitor, keyboard, and mouse are all that is required for a console, not necessarily access to the power button, USB ports, CD drives, and so forth. So, it is not universally true that console access equates to physical access. In addition, various tools like VNC allow remote users to act as if they were on the console. While VNC itself is detected as a non-local console, x11vnc is not.

Normally, one would expect this kind of change to be noticed in Rawhide—Fedora's development distribution—long before the F12 release. That would have allowed the issue to be discussed and resolved well in advance of unsuspecting users upgrading into the new policy. Unfortunately, the Rawhide packages aren't signed, so PackageKit always requires the root password to install them. So the first time the Fedora community saw this change was after they had upgraded to the "real" F12.

One might also expect a change of this magnitude to appear, perhaps quite prominently, in the F12 release notes, but that was not the case at the time of the release. Since that time, a very eye-catching note was added to the security section of the release notes. That could serve as a warning for users that read, or at least skim, those notes.

The other main line of defense is that this behavior is "just" a default, and can be changed by administrators. While that is true, the process to do so is not obvious. It involves mucking about with PolicyKit files, something that many Fedora users probably know little to nothing about. Hughes thinks that users should learn PolicyKit: "If you're deploying F12, then I really think you should know the basics about PolicyKit." But, when Seth Vidal set out to find out how to disable the feature—documented on his blog—asking Hughes did not lead to the solution: "So, if our engineers don't know the basics, how should our users?"

Overall, Hughes's reaction to the problem has been dismissive, bordering on rude:

Based on the above, one could argue with the "trivially", but, more to the point, one must understand an existing security model before changing it. If one myopically focuses on a single use case, and ignores the problems inherent in even that case, concluding that allowing unprivileged users to do package installation might make sense. But, for overall system security—not to mention the reputation of Fedora as a distribution that keeps security in mind—myopia is not a good strategy.

Hughes often refers to the change only being made for the "desktop spin", but that doesn't really make sense as the feature was added to all of Fedora. Certainly, some spins—server, for example—could change this default, but that seems backward. The core should default to secure choices, and allow spins to relax those requirements if they so desire. As Adam Williamson points out:

Larger issues

Regardless of how they feel about the specific feature in question, Fedora developers would like to avoid being blindsided by these kinds of changes in the future. To that end, Chris Adams started a discussion on security policy oversight: "Any package (whether new or an update) that adds/changes PolicyKit, consolehelper, or PAM configuration, and anything that installs new setuid/setgid executables, should require some additional third-party review." As part of that discussion, Hughes seems to be coming around to the majority view: "At the moment we're asking the server spin to essentially close the door, when maybe we should start with a closed door, and be asking the desktop spin to open it up a little more."

There is concern that a package maintainer can change global behavior for the distribution without any notice. Once the change is made, that maintainer can refuse to change it back, requiring the Fedora Engineering Steering Committee (FESCo) to step in and make a decision. In the case of a security problem, one that the maintainer is unwilling to acknowledge, the delay could be a serious problem. Since the change to PackageKit still has not been released as of this writing, there are numerous systems out there that are being installed or upgraded into less security.

FESCo discussed the issue at its November 20 meeting, and Vidal will be putting together a proposal to require the maintainers of critical packages to disclose any changes that might have this kind of impact. From the discussion of Adams's call for more oversight, a need for an overall framework of what users should and should not be able to do was noted. Fedora engineering manager Tom "spot" Callaway has started gathering a list of things that unprivileged users should not be able to do that would presumably factor into such a policy.

There were also some ancillary, but still important, issues. The responses from Hughes and David Zeuthen ("I'm not interested in this bike-shed or what color it is") in the thread angered quite a few. As the discussions grew, several Fedora leaders tried to tamp down the flames, which also didn't sit well with folks. A suggestion to vote on the bug, rather than continue piling on to the discussion was met with opposition as well, leading Jeff Garzik to note:

At one point Red Hat employees started using hidden comments in the bug to create a virtual "executive session", but folks started noticing the skipped message numbers and wondered what was going on. Williamson stepped in quickly to stop that:

The future

The Fedora project has likely learned quite a bit from this particular controversy, and it seems to be taking the right steps to avoid a repeat in the future. For a distribution that went through a great deal of pain to integrate SELinux features in order to increase the security of the system, it is mind-boggling to many that this non-root install feature was added as the default. There were multiple missteps—making it the default, not highlighting it in the release notes, not testing it in Rawhide, and so on—but those can all be corrected. Hopefully, the outcry and publicity will ensure that the word gets out, so that Fedora users will understand the issue and can make the appropriate changes for their systems.

In the meantime, though, other projects—distributions or software packages—would be well-served by studying this episode. Security is hard, and requires great diligence. It is likely that other projects could have hit this same kind of problem, but, hopefully, with this incident as a guide, will avoid doing so in the future.

Comments (51 posted)

The 2009 Linux and free software timeline - Q1

Here is LWN's twelfth annual timeline of significant events in the Linux and free software world for the year.

2009 offered few surprises to those that have been following Linux and free software for as long as we have. As expected, there were new releases of many of the tools and underlying infrastructure that we use on a daily basis. There were also lawsuits over software patents, arguments over licensing, and various security flaws found and fixed. Distributions were packaged up and released, more phones and other devices with Linux and free software were sold, and so forth. All part of the march to "world domination". We look forward to 2010—and beyond.

This year we will be breaking things up into quarters, and this is our report on January-March 2009. Over the next month or so, we will be putting out timelines of the other three quarters of the year.

---

This is version 0.8 of the 2009 timeline. There are almost certainly some errors or omissions; if you find any, please send them to timeline@lwn.net.

LWN subscribers have paid for the development of this timeline, along with previous timelines and the weekly editions. If you like what you see here, or elsewhere on the site, please consider subscribing to LWN.

For those with a nostalgic bent, our timeline index page has links to the previous eleven timelines and some other retrospective articles going all the way back to 1998.

January

One Laptop Per Child (OLPC) restructures, laying off half the staff and "refocusing" in various ways. (OLPC blog)

Valgrind releases version 3.4.0 of the popular program analysis tool for finding memory and other errors. (review).

Nokia announces the release of Qt under LGPLv2.1 for the upcoming 4.5 release. (announcement).

linux.conf.au is held in Hobart, Tasmania. (LWN coverage, 2, 3, 4, and 5)

Red Hat Enterprise Linux 5.3 is released. (announcement)

Moonlight developers work overtime to make President Obama's inauguration viewable on Linux, because the streams were only made available in Silverlight form. (article)

GCC and FSF announce a GPLv3 exception to allow for GCC plugins; the exception is for the GCC runtime library and will allow free software plugins, while preventing proprietary plugins. This particular incarnation of the exception is not adopted. (announcement)

KNOPPIX 6.0 is released. (announcement, review)

KDE 4.2 is released. (announcement)

AMD releases 3D register reference guide for R6xx/R7xx chips, which will help with the development of free software drivers for devices using those chips. (announcement)

The Linux Foundation kicks off the "We're Linux" video contest. (press release)

February

Zope 3.4 is released after two years of development on the Python-based web application server.(announcement)

Red Hat hires former Mandriva community manager Adam Williamson to drive community involvement in Fedora QA. (introduction)

Miro internet TV version 2.0 is released. (announcement)

RPM version 4.6.0 released; the package manager used by Red Hat, Mandriva, SUSE, and others. (announcement)

Debian 5.0 ("Lenny") is released after "22 months of constant development". (announcement) The release is dedicated to Thiemo Seufer, a community member who died in a car accident.

DragonFly BSD 2.2 is released—now with a production-ready HAMMER filesystem. (announcement)

Kurt Roeckx is appointed as Debian project secretary, after the previous secretary resigned in late 2008. (announcement)

Red Hat moves from Xen to KVM for virtualization in future releases, as expected by many after its acquisition of Qumranet. (press release)

Microsoft launches patent suit against TomTom, for patents on the VFAT filesystem among other things. (LWN coverage)

BASH 4.0 is released.; BASH is the Bourne-Again SHell (announcement)

X server 1.6.0 released. (announcement)

March

The Linux Foundation acquires the Linux.com domain, which they will turn into a community news and collaboration site. (announcement)

MontaVista starts Meld community site for embedded Linux developers. (announcement)

The "ext4 data loss" controversy heats up. (first LWN article)

Firefox 3.1 renamed to 3.5 to better reflect the scope of the changes. (announcement)

The Linux kernel gets a new logo for one release; "Tuz" is a reminder of the plight of the Tasmanian devil. (LWN coverage)

GNOME 2.26 released. (announcement)

Parrot 1.0.0 released; Parrot is a "virtual machine aimed at running all dynamic languages". (announcement, LWN article)

Linux 2.6.29 is released with an experimental Btrfs, squashfs, kernel mode setting for Intel graphics hardware, and more. (announcement, KernelNewbies coverage)

SUSE Linux Enterprise 11 is released in both desktop (SLED) and server (SLES) varieties. (press release)

Rails 2.3 released—aka Ruby on Rails, the Ruby-based web framework. (announcement)

GNOME switches to Git, from Subversion, for version control. (announcement)

Microsoft vs. TomTom comes to an end, via a settlement, but, before that, TomTom joins the Open Invention Network and countersues Microsoft. (Groklaw settlement article)

Fedora issues report on August 2008 intrusion, seven months after it occurs. (report)

Python starts switch to Mercurial for distributed version control. (Guido van Rossum's announcement)

Comments (18 posted)

Page editor: Jonathan Corbet
Next page: Security>>