LWN.net Weekly Edition for December 14, 2006

Playing with the OLPC

The One Laptop Per Child project is likely to be familiar to most LWN readers by now. An important milestone on this project's plan for the creation of low-cost educational systems is the production of "BTest-1" systems. The project has manufactured on the order of 1000 laptops and distributed them to testers worldwide as a way of, hopefully, shaking out the remaining hardware issues and making a start on the software side of the equation. Some systems have even been shipped to Microsoft so that some sort of Windows port can be done; this move has upset some OLPC supporters, but when the designers of the laptop said they planned to make a 100% open system, they meant it.

Your editor was lucky enough to receive one of these systems, after having been put through the indignity of seeing everybody else's "I got my laptop" posts first. There has not been a great deal of time to play with it yet, but your editor has had the chance to form some first impressions. The OLPC XO (or whatever it is eventually called) is going to be a nice system.

Back in July, we interviewed Jim Gettys about this system; one of the questions we asked was how they planned to keep adults from stealing the laptops from the children for their own purposes. Jim answered:

First, we intend that the systems be instantly recognizable as kid's systems, not only so that kids like them and value them more and take care of them carefully, but also so that adults with machines in their possession may be asked questions about whether they should have the machine.

Even with this in mind, most people who see an OLPC for the first time are surprised by just how small it is. Understanding sets in for real when one attempts to use the keyboard; the small keys will work for a small child, but, for your fat-fingered editor, it is very much a hunt-and-peck device. There will be very few adults who will be able to type comfortably on this system. With the size of the device and its bright colors, they will also look decidedly silly in the attempt. This machine is clearly for kids.

Another way to make adults look silly is to hand the laptop to one of them and suggest that they open it. Your editor has performed this experiment several times now, and has not yet seen anybody succeed. Most people try pushing on the green square that looks like a latch, but which is, in reality, the hinge. The secret is to lift up the two "ears," which happen to be the wireless network antennas, and open the top toward the handle. Anybody attempting to use a crowbar should be stopped immediately.

The display can rotate 180 degrees and be closed over the keyboard, putting the device into "ebook" mode. There is no touchscreen on the device, so the only controls available in this mode are the eight buttons (four arrows and four which, for now, look like Sony game controller buttons) next to the display.

On the software side, the test system is running a pared-down version of the Fedora Core distribution. The kernel is essentially 2.6.19-rc2 with a fair set of patches (some since merged into the mainline) to support the OLPC hardware. Many of the basic utilities are there, and there is a Python interpreter available. But anybody looking for a C compiler, OpenOffice.org, emacs, Wesnoth, etc. will not find them. The system has little space (512MB of flash storage) and even less memory, so a lot of larger applications will never find space there.

The BTest-1 release notes make it clear that the process of putting together the software is just beginning; the focus, until now, has been on getting the hardware working. So many of the provided "activities" are present only in a preliminary form, and others are not there at all yet. It is not, according to the release notes, time to test the device on children (though your editor's children disagree rather strongly). Certainly the adults are starting to have fun with the system; your editor was gratified by this brief posting on video conferencing on the OLPC using the telepathy package.

Running software on the test system drives home a point the project has been making for some time: much of the software we run now is far too bloated and slow. With a suitable amount of attention to resource use, the OLPC hardware is powerful enough to accomplish a wide variety of tasks - web browsing, document editing, video conferencing, and more. But, with the wrong software, the system will just sit there and thrash. So one of the primary goals for the OLPC software team in the coming months will be to put the system's applications on a diet until they fit comfortably on this small system. This work will benefit us all in the end; some of the work aimed at slimming down the Gecko rendering engine can already be found in Firefox 2.

Beyond that, however, this project is setting up to put millions of Linux-based laptops into the hands of children worldwide. These systems will include mesh networking and cameras; this is a combination which is likely to lead to interesting things to see on video sharing sites - and serious news channels. The laptop will be wide open, with the "view source" functionality built in. There are many people who question this project and whether the countries involved might better spend their resources on clean water, sanitation, and so on. Those are legitimate questions which cannot be simply brushed off. But one should also consider what those kids will be able to do given better access to knowledge, communications, and a platform they can hack to their own ends. It is going to be interesting to watch.

Comments (24 posted)

The next document format battleground

Recent weeks have seen a great deal of debate over Microsoft's OpenXML document format. This format, which is headed for standard status, is a complex beast. Some have questioned whether it will ever be able to create independent implementations of OpenXML which are truly interoperable with each other. Others ask whether it is right for the free software community to even try. To many members of our community, the right path is to encourage the use of OpenDocument, which already has standard status and implementations in free software. Why get onto another document format treadmill when a better solution is already available?

These questions are valid, they deserve full consideration. But they may also, to an extent, be missing the real point. It is entirely possible that the document format battles are done; even if OpenXML is not a perfect standard, it is far more open than its predecessors. While Microsoft is not inclined to make life easy for those who would interoperate with its file formats, the company may well have realized that obscure formats have outlived their usefulness as a way of maintaining desktop domination. This might just be a battle we have won, even if the victory is rather more messy than we would like.

Before we charter an aircraft carrier for our "mission accomplished" party, however, it is worth reflecting on different forms this fight could take in the future. Cory Doctorow gave us a good hint in this InformationWeek article on "information rights management." IRM is a feature touted by Microsoft for a few years now which has the potential to complicate life considerably in the future.

IRM offers some interesting features to people who are worried about the information they put into their documents, presentations, and spreadsheets. With IRM, the document owner can specify exactly who can read a particular file, and under what conditions. Access can have an expiration time attached to it - or it can be revoked at any time. Actions like printing can be restricted. For anybody who feels the need to control information, these features cannot fail to be appealing.

But these features only work if the client plays along, and free software clients have not always distinguished themselves in this area. Or, rather, they have distinguished themselves very well by serving the needs of their users. Even if a programmer implements the "this document can only be printed once" flag, somebody else, perhaps after having lost their one printing opportunity to a particularly nasty paper jam, will hack it out. Clearly, Microsoft must prevent the creation of free applications which can read IRM-protected documents or it will be unable to live up to the promises it has made for that technology.

Microsoft has a couple of weapons at its disposal (beyond pure obscurity) which can be used against any potential free IRM implementation. One is the DMCA, which, in the US (and countries which have implemented similar laws), can be employed against those who bypass access restriction mechanisms. Anybody who posted code that, say, allowed the user to cut and paste text out of an IRM-protected document would likely face an unpleasant reception in the US. They would be in a situation much like that faced by Dmitry Sklyarov, who bypassed similar restrictions in PDF files, a few years ago.

Of course, the Sklyarov case did not necessarily work to Adobe's advantage in the end, and Microsoft might wish to avoid a similar storm of bad publicity. So, as Cory's article points out, Microsoft might pursue a different option: the use of the trusted computing module (TPM) increasingly being built into new computers. With the remote attestation feature of the TPM, it is possible to refuse to pass decryption keys to any system which cannot be shown to be running approved software. This system would be quite tight and hard to defeat - it might just work. And it would no longer matter how "open" the document format is.

The full remote attestation scenario requires the cooperation of the entire system, starting with a "secure" BIOS which initializes the TPM properly. Most systems do not currently operate in this mode, so the realization of this threat will not happen in the immediate future. One should not, however, forget that the TPM has been designed to support just this mode of operation. It does not take all that much paranoia to imagine that these capabilities will not go unused forever. "Trusted computing" has yet to touch most of us, but we ignore it at great risk. Among other things, it could make the current discussion of open document formats entirely moot.

Comments (16 posted)

Steps in the Fedora transition

The recent Fedora Summit reached a number of conclusions about the future of the project. These include the elimination of the distinction between Fedora Core and Fedora Extras and the extension of the support period for Fedora releases to approximately 13 months. Since then, various parts of the project have tried to figure out what is really going to happen. It is beginning to appear that a few things, at least, are coming into focus.

When changes of this magnitude are in store, one's thoughts immediately turn to the most important topic: what will be the project's new name? Quite a few possibilities were discussed, including Fedora Union (not everybody liked the acronym) and Fedora Freedom (which, it seems, brings unwelcome associations with "freedom fries" to a fair number of people). After weeks of discussion, it would appear that people are converging on (...drum roll...) "Fedora." Who would have guessed?

So when will the next ~~Freedom Fries~~ Fedora release be? According to a recently-posted schedule proposal, Fedora 7 will come out on April 24, 2007. That date seems to be driven by the Red Hat Summit, which starts on May 9; the Fedora folks would like to have something to show off at that event. On this schedule, the first test release would be on January 30, just before the next FUDcon, which appears set for February 2 to 4. Assuming the schedule does not slip, it should be possible to hand out Fedora 7 disks to Red Hat Summit attendees.

The only problem is that Fedora schedules have been known to slip at times. This realization has led to a discussion on what went wrong, and how schedule slips might be avoided this time around. There were a number of issues that came up toward the end of the Fedora Core 6 effort, some of which would have been hard to anticipate and avoid. One of the biggest issues, however, was the fact that Xen didn't work. Fedora kernel maintainer Dave Jones has some choice words about Xen, along with a grim prognosis about the potential for future problems. It rather appears that Fedora might be best served by dropping Xen altogether, but that is unlikely to happen in the short term. Red Hat Enterprise Linux needs to have Xen (after all, Novell ships it), and Fedora is where these technologies get much of their early testing.

That said, there seems to be a fair amount of sympathy for the idea of simply dropping features with problems that threaten to delay the release. Hopefully the Fedora developers won't have to make any such choices this time around, but, should something come up, it will be interesting to see how they respond.

Another open question is what happens to the Fedora Legacy project. Nobody has really taken the step of officially shutting it down. Jesse Keating has walked away from it, however, and few people seem to see much reason for keeping it going. There are users who would like to see more than 13 months of security support for Fedora releases, but the subset of those users who are willing to help Fedora Legacy provide that support is quite small.

Meanwhile, the project did (on December 12) put this note onto its web page:

The current model for supporting maintenance distributions is being re-examined. In the meantime, we are unable to extend support to older Fedora Core releases as we had planned. As of now, Fedora Core 4 and earlier distributions are no longer being maintained.

Given that the project only managed one Fedora Core 4 update ever, one could argue that the situation has not changed much. But at least it is now clear. What is less clear is how the various hosting companies which offer Fedora Core 4 servers have kept them secure so far, and what they intend to do now.

Finally, the project still has not come to a final resolution on what to do about RPM. The subject was apparently discussed at the December 12 board meeting, but no communications are, as of this writing, available. With luck, we'll hear from the project on this topic before too long. Infrastructure like RPM is too important to leave in a limbo state for this long.

Comments (4 posted)

Page editor: Jonathan Corbet

Security

Another kernel core dump security issue

December 13, 2006

This article was contributed by Jake Edge.

When a security bug is found in the kernel, a patch is usually available within hours; the kernel developers rightly take these things very seriously. Once the patch is available, the stable team typically releases a new kernel within a week or so and this is one of the big advantages of open source. Once in a while, however, a bug that has been fixed previously can creep back into the source, open or closed, and is known as a 'regression'. This week's 2.6.19.1 kernel release has a fix for something that looks an awful lot like a regression, but technically is not.

Back in July, LWN described a security problem in the then-current 2.6.17 kernel. The issue was that local users could configure their processes to write core dump files in directories that they did not have write permissions for. As the article described, this could be trivially exploited for local privilege escalation; in short, a local root hole.

This bug was fixed by the following patch:

    --- a/kernel/sys.c
    +++ b/kernel/sys.c
    @@ -1983,7 +1983,7 @@ asmlinkage long sys_prctl(int option, un
                            error = current->mm->dumpable;
                            break;
                    case PR_SET_DUMPABLE:
    -                       if (arg2 < 0 || arg2 > 2) {
    +                       if (arg2 < 0 || arg2 > 1) {
                                    error = -EINVAL;
                                    break;
                            }

which prevented processes from setting the dumpable flag to two. That flag governs whether core dumps are produced by the process; the special value of two reflects an ability to dump core with root privileges, quite possibly to directories that the user cannot normally write to. The code did guard against overwriting existing files, for security reasons, but did not consider the implications of allowing user processes to effectively write anywhere.

The code which handles the dumpable flag lives in fs/exec.c in the aptly named do_coredump() function:

    if (mm->dumpable == 2) {        /* Setuid core dump mode */
            flag = O_EXCL;          /* Stop rewrite attacks */
            current->fsuid = 0;     /* Dump root private */
    }

and further down, flag is used as part of the filp_open() call:

    file = filp_open(corename, O_CREAT|2|O_NOFOLLOW|O_LARGEFILE|flag, 0600);

At the end of September, a patch by Andi Kleen was applied to allow core dumps to be piped to a userspace process. This patch had been, according to Andi, "hanging around for a long time" and lacked the flag in the call to filp_open(). The patch made it into 2.6.19-rc1 kernel and from there into 2.6.19.

The impact of the bug is relatively low as a root user would have to set the dumpable flag to two via /proc/sys/fs/suid_dumpable. This would allow user processes to write core dumps anywhere, which is as designed, but also would allow them to overwrite existing files, which is not. It probably is not very common that admins need to configure things that way, but it certainly is not completely outside the realm of possibility either.

As described in the patch, Alexey Dobriyan used a list of warnings gathered from compiling the kernel. The warnings were grepped for 'was set but never used' and the first entry in the list pointed to this problem. The kernel produces enough warnings that problems like this tend to be obscured in a sea of bogus or overly picky warnings.

This particular bug is not technically a regression as there never was a bug that allowed this behavior until it was introduced in the patch. It has been assigned CVE-2006-6304 (as of this writing, it is just a reserved CVE with no information).

It is great to see folks scrutinizing warnings and looking for bugs in the kernel, this is just the kind of thing that the 'many eyes make all bugs shallow' theory is referring to. It would be nice to see a kernel regression test suite that contained test cases for bugs that have previously been fixed as that kind of thing might have caught this bug. It is a difficult problem, however, and keeping up with the number of bug fix patches would be daunting. Perhaps a regression suite that focused on security fixes would be a good place to start.

Comments (9 posted)

New vulnerabilities

clamav: missing sanity checks

Package(s):

clamav

CVE #(s):

CVE-2006-5874

Created:

December 11, 2006

Updated:

December 14, 2006

Description:

Stephen Gran discovered that malformed base64-encoded MIME attachments can lead to denial of service through a null pointer dereference.

Alerts:

Mandriva	MDKSA-2006:230	clamav	2006-12-13
Debian	DSA-1232-1	clamav	2006-12-09

Date(s)	Event	Location
December 27 December 30	23rd Chaos Communication Congress 2006	Berlin, Germany
January 11 January 12	Foundations of Open Media Software	Sydney, Australia
January 15 January 20	linux.conf.au 2007	Sydney, Australia
January 20 January 26	Cell Hack-a-thon	Loveland, CO, USA
January 23 January 26	Open Source Meets Business	Nürnberg, Germany
January 24	European Patent Conference	Brussels, Belgium
January 30 February 1	Solutions Linux Expo	Paris, France
February 1 February 2	LinuxDays Luxembourg	Luxembourg, Luxembourg
February 2	FUDCon Boston 2007	Boston, MA, USA
February 7 February 9	Free Software World Conference 3.0	Badajoz, Spain
February 7 February 9	Xorg Developer's Conference	Santa Clara, CA, USA
February 9	Women In Open Source	Los Angeles, USA
February 9	Open Source Health Care Summit	Los Angeles, USA
February 10 February 11	2007 Southern California Linux Expo	Los Angeles, USA
February 12 February 13	Vancouver PHP Conference	Vancouver, BC, Canada
February 12 February 13	Linux Storage and Filesystem Workshop	San Jose, CA, USA
February 12 February 16	Ruby on Rails Bootcamp Training	Atlanta, USA
February 12 February 15	3GSM World Congress 2007	Barcelona, Spain
February 14 February 15	LinuxWorld OpenSolutions Summit	New York, NY, USA
February 15	TiE Open Source Summit	Pittsburgh, PA, USA
February 16	The Ubucon New York	New York, NY, USA

From:		gralex-AT-free.fr
To:		letters-AT-lwn.net
Subject:		Benefits of software freedom
Date:		Fri, 08 Dec 2006 15:21:48 +0100

LWN.net Weekly Edition for December 14, 2006

Security

New vulnerabilities

clamav: missing sanity checks

enemies-of-carlotta: input sanitizing

gnupg: stack overwrite

kdegraphics: stack overflow

l2tpns: buffer overflow

libmodplug: boundary errors

madwifi-ng: buffer overflow

ruby: denial of service

squirrelmail: multiple cross-site scripting vulnerabilities

Kernel development

Brief items

Kernel development news

Video standards

Inputs

Outputs

Patches and updates

Kernel trees

Architecture-specific

Core kernel code

Development tools

Device drivers

Filesystems and block I/O

Janitorial

Memory management

Virtualization and containers

Miscellaneous

Distributions

News and Editorials

New Releases

Distribution News

New Distributions

Distribution Newsletters

Package updates

Newsletters and articles of interest

Distribution reviews

Development

System Applications

Audio Projects

Database Software

Libraries

Web Site Development

Miscellaneous

Desktop Applications

Audio Applications

Data Visualization

Desktop Environments

Electronics

Financial Applications

Games

GUI Packages

Interoperability

Medical Applications

Music Applications

Office Suites

Web Browsers

Miscellaneous

Languages and Tools

Caml

Haskell

Perl

Python

Tcl/Tk

XML

Build Tools

Test Suites

Version Control

Miscellaneous