| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for December 16, 2004The Linux Core Consortium courts Debian The Linux Core Consortium is an effort by Conectiva, Mandrakesoft, Progeny and Turbolinux to create a single, Linux Standard Base-compliant core distribution which each distributor can then use as a base for their products. The idea is to share some of the distribution engineering work and, simultaneously, to create a widely distributed, standard platform which independent software vendors can target for their products. See this LWN article for more information on the LCC.Bruce Perens has recently proposed to the Debian project that it work with the LCC. There are, according to Bruce, a few reasons why Debian would want to do that:
The first is that we should be influencing this group to do things
the Debian way, where that is important. The second is that the
group plans to lower the overhead of hardware and application
vendor certification for all of its participants, and we could
really use that sort of support. The third is that the group would
make certification by LSB and other standards bodies easier for all
of the participants.
Ian Murdock, the founder of the Debian project, has his own reasons for encouraging Debian to join:
How does Debian benefit from LCC? It's a route to the ISV and IHV
certifications that Debian has always lacked, and it is the lack of
these certifications that's preventing Debian from standing
alongside Red Hat and Novell/SuSE in the commercial space despite
comparable (and arguably greater) popularly. The industry simply
doesn't know how to engage us, and LCC provides them with a vehicle
for doing that.
Appealing to vendors of proprietary software has never been high on the Debian Project's list of priorities. Ian claims that vendor support is important, however, if Linux is to remain an open, free platform in the increasingly commercial context in which it operates. Working with the LCC would, essentially, require Debian to help develop, and then distribute, a set of standard binaries used by all LCC-based distributions. All of these distributions would use the same (binary) kernel, the same libraries, and many of the same configuration mechanisms. The use of identical binaries goes beyond the requirements of the LSB, which only requires that the same binary interface (ABI) be available. Ian claims that the LSB approach has proved to be insufficient:
...while there are numerous LSB-certified distros, there are
exactly zero LSB-certified applications. The reason for this is
that "substantially the same" isn't good enough--ISVs want *exactly
the same*, and there's a good reason for that, as evidenced by the
fact that while Debian is technically (very nearly) LSB compliant,
there are still a lot of edge cases like file system and package
namespace differences that fall outside the LSB that vastly
complicate the "certify to an ABI, then support all distros that
implement the ABI as defined by whether or not it passes a test
kit" model.
As one might imagine, there is some resistance within the Debian Project to distributing a set of binaries (including the kernel) provided by an outside organization. It will be a hard sell; from your editor's reading of the debate, the early signs are that the Debian developers aren't buying it. Debian users like to have a great deal of control over their systems, and the LCC looks like a way of giving up some of that control with no immediate benefits in sight.
Porting free software to Windows A recent debate between KDE developers raises an interesting question: Does it help or hurt to port open source applications to closed platforms, such as Windows? One side argues that availability of open source applications on Windows diminishes the chances that users will choose to migrate to Linux or *BSD. The other side argues that open source on Windows can bridge the gap between Linux and Windows, thus making it easier for users to (eventually) migrate. First, there is the question of goals. While Microsoft has a coherent set of goals, the open source community does not. Some projects are dedicated to spreading open source as an end unto itself, others just see open source as the best model for their specific project. If the goal is simply to foster adoption of a specific application, like Firefox or OpenOffice.org, then porting that application to Windows is without question the right strategy. The vast majority of desktop users are on Windows, and it makes little sense to ask users to switch operating systems to use one application. However, if the goal is to spread open source in general, then one has to wonder whether users are likely to migrate to a new operating system if the best applications for that system (or most of them, anyway) are also available on the closed system that they're familiar with. The vast majority of users are motivated by factors other than licensing. This is not the first time the debate has been raised, nor is it likely to be the last. However, this may be a good time to look at the situation. Linux is acknowledged as a mainstream server operating system, but still looked at as a fringe desktop operating system. Desktop applications on Linux are starting to reach parity in ease-of-use and feature sets with their Windows counterparts, thus making it a viable platform for Windows users to migrate to, should they so choose. At the same time, many of those applications are available on Windows, allowing Windows users to adopt open source applications without migrating away from Windows. If this is the final result, then most Linux users would see porting open source applications to Windows as undesirable. As Aaron Seigo writes:
The more software we port to Windows the more we reinforce this application
availability imbalance and strengthen the user's inertia to stay on
Windows. If users had to make a choice between Windows or Linux (or BSD)
when it came to getting access to better applications they would find they
had a motivation to switch. And switch they would.
There is, however, the possibility that users will be more likely to adopt Linux or *BSD if they have a positive experience with some of the open source applications on Windows. Change is scary for many users, and it may be better to provide a means to gradually adjust to open source platforms rather than expecting a user to plunge in headlong and learn to swim right away. It's also worth considering that many Windows users would never be exposed to open source applications if they are not available on Windows. It's one thing to hear wonderful things about OpenOffice.org, Firefox, The Gimp, Apache or KDE, but another thing entirely to actually use those applications and become comfortable with them. For organizations, the gradual approach may be the best way to ensure the adoption of open source. As "pipitas" argues:
Even at the present stage there is a considerable share of IT desicion
makers in enterprises and government bodies who seriously evaluate options
and costs of a switch over. For most, it now looks like "all or nothing,"
and a big jump. A too big one in many cases. So they refrain. So they sign
another 5 year contract with MS...
To chop the task into smaller pieces, to take the direction, but only a few steps for now, to smooth the transition out over a period of time is very difficult. And it costs. Not only do you have to train the users. You also need to re-train the IT teams. So Microsoft is of course playing on the card of Total Cost of Ownership (TOC), with a liiiiiittle bit of (every marketeer's) exageration, but with a tiny bit of valid argument too. They keep winning, albeit often by a small margin. And they even start losing some rounds, lately. Both sides make compelling arguments. There are, no doubt, users and organizations that will adopt a handful of open source applications and stop there. Other users and organizations will adopt Firefox, OpenOffice.org and other open source applications and decide to go further. In the end, however, it's hard to argue for spreading open source by restricting users' choice. Most Linux users resent Microsoft for restricting their choices when using Windows, so it's somewhat hypocritical to suggest that Windows users should have to make an "all or nothing" choice to use Linux or *BSD to benefit from open source. While there's a risk that users will choose to stay on Windows, it's the ability to choose that led most of us to Linux in the first place.
Ubuntu Conference: The Mataró Sessions The Ubuntu Conference was already in full swing by the time I arrived, late last Friday. Canonical employs thirty-seven people, located in twelve countries, and most of them are here in Mataró. For some this is their first chance to meet and talk to fellow developers face to face. The entire conference has been a series of workshops, BOFs and hack sessions all revolving around Ubuntu, LaunchPad and the various components of LaunchPad. A few visitors have joined in here and there, but only the sessions last Saturday were targeted to visitors. Presentations have mostly been in English, although Saturday's sessions were translated into Spanish and Catalan for the benefit of the many Spanish visitors. People drift in and out, but over all attendance averages around fifty people, and at least double that on Saturday.The conference is located at the Hotel NH Ciutat de Mataró, also home for most of the Canonical staff and your LWN editor. A typical day starts out with a buffet breakfast in the hotel dining room. All Canonical staff meet in the main conference room at 9:00 AM before breaking into smaller groups to talk about and hack on the various projects. The hotel provides a pack lunch so people can munch and continue working. By around 8 or 9 PM it's time to head for dinner at one of the many restaurants in Mataró. This is also done in smaller groups as some continue hacking until late and some go looking for different types of food. Mataró is on the Mediterranean coast so the weather is mild. Natives wear coats and scarves and hats, but those of us from more northerly climes find it pleasant with no more light a jacket even late at night. Canonical projects underway here at the conference include Ubuntu and the upcoming Hoary Hedgehog release, the proposed KDE version called Kubuntu and the application suite LaunchPad, with many a late night hack session devoted to one of the LaunchPad applications. For more on LaunchPad and its applications see Ubuntu Conference: The LaunchPad workshop. Briefly, the applications so far are the translation tool Rosetta, package manager Soyuz, version control system Bazaar, and bug tracker Malone. I chatted with Canonical founder Mark Shuttleworth briefly on Wednesday over lunch and asked him how Canonical plans to make money. Ubuntu is free, and LaunchPad will be free to use, but Canonical does aim to make some money in support. Additionally, he hopes to get some government grants to build localized distributions. By using the still incomplete LaunchPad suite it will be easy to create distributions for a wide variety of the world's subcultures. For now he keeps costs low by limiting the number of developers assigned to any particular project and by not having a centralized office, and enjoys Python hacking with his staff of talented developers. He also knows what he's willing to spend to make Canonical self-sustaining and how long that should take (though he did not share details with your editor). If it doesn't happen he'll pull the plug and move on. We're hoping that it does work out and Canonical will manage to survive, not only because Ubuntu is a nice distribution and quite stable on this laptop, but also because if LaunchPad can become the suite that Mark envisions, it could be as revolutionary as Linux itself. For now LaunchPad remains largely vaporware, with the exception of Rosetta, so it is too soon to tell if it can really live up to its potential, but with the team that Mark has put together it stands a good chance. This is Rebecca Sobol reporting from Mataró Spain.
Ubuntu Conference: The LaunchPad workshop Here at the Ubuntu Conference in Mataró Spain, Canonical developers are meeting with each other and with representatives of the Spanish government and other guests to talk about Ubuntu and LaunchPad, an application suite currently in development at Canonical. This article focuses mainly on the workshops that took place on December 11, wherein government representatives and other guests were treated to a view of some of the LaunchPad applications.
Carlos explained that Mataró is located in Catalunya, where Catalan is the local language and the local Linux distribution is Càtix. Other regions in Spain have their own language and culture, and each region wants to preserve that language and culture, and this is reflected in a variety of local Linux distributions customized into the various local languages.
During Alfonso's presentation we learned that the second version of Guadalinex has been released and that thousands of people use Guadalinex in schools, at home and at work. Guadalinex offers technical and non-technical support. Also Guadalinex shares many of the same problems that are faced by developers around Spain and around the world. Here is a short list of areas, as identified by the audience, in which small distributions, particularly those derived from larger distributions, are having problems.
Once the problems were identified it was time to talk about how LaunchPad might provide at least some of the solutions. The three LaunchPad applications closest to release are Rosetta, Malone and Soyuz. We should note here that while LaunchPad tools are designed to be used with open source software, they will not themselves be released as open source, at least not initially. Rosetta: Due for its first release this week, Rosetta may be out by the time you read this. This translation tool provides an easy-to-use web interface for translators, making it easy for a non-technical translator to provide a translation for an application. How does that work? Take any application included in your distribution. The user interface is typically presented in English. To localize the application you could go into the code and change all the strings to the language of choice. Then you'll have to recompile, deal with any introduced errors, and have a version of code that is different from upstream. Worse, the process starts over with each update to the application, even when the application's interface remains the same. Now imagine that you have translators from all over world who use Rosetta's interface to edit a POTemplate (or POT file) for that application. The application needs only to be aware that POT files exist to present the end user with an interface in their chosen language. New translations can be added and existing translations can be improved without any change to the code. Rosetta keeps track of translations and can export new or improved translations back to the original application. Rosetta can also show you your entire distribution to see what has been translated, and what still needs to be translated. Right now Rosetta only works with code, changing the face of the application for the non-English speaking user. Later releases of Rosetta will be able to handle man pages, DocBook and OpenOffice documents, and do spell checking. Those interested in using Rosetta may join the mailing list at rosetta-users@lists.ubuntu.com . Malone: Another piece of LaunchPad is Malone, an extraordinary bug tracking tool. Malone is for developers, not for end users to fill with their bug reports. It will coordinate with other tools such as Bugzilla, tracking bugs both upstream and between distributions. A developer using Malone will be able to see if a bug has been fixed, and where it was fixed so that the fixes can be incorporated into their own distribution. Expect to hear more about Malone in early 2005.
A few of the barriers to collaboration and convergence include government secrecy, lack of communication/language barriers, geography/time zones, different deadlines and priorities, lack of resources, infrastructure, branding, unrealistic requirements, different hardware/architectures, and so on. The idea of LaunchPad is to provide tools that will eliminate as many barriers as possible, so that all Linux distributions can share more and developers can spend less time reinventing the wheel. Soyuz is the package tracker, helping the developer to track the packages in the distribution, upload and build source, track bugs, keep information about the packages and their maintainers and provide a wrapper around the version control system. LaunchPad's version control system is called Bazaar and it's forked from Arch. But that's a story for another article. This is Rebecca Sobol reporting from Mataró Spain.
A couple of LWN notes As has become our tradition, we will not publish the LWN.net Weekly Edition the week of December 30. We'll return to the usual schedule with the January 6, 2005 edition. The daily updates will continue to happen over the holidays.For various reasons, the 2004 Linux Timeline will be released a little later than usual. Rest assured that it is in progress, and that it will be out by the end of the year.
Page editor: Jonathan Corbet Security Anatomy of a kernel vulnerability The Linux kernel has seen a great deal of code auditing work. Even so, longstanding security issues turn up regularly. Consider, for example, the __scm_send() vulnerability recently disclosed by Paul Starzetz. This problem, present in the 2.6.9 kernel, is also present in 2.4; it has been there for some years.This particular vulnerability hits the kernel socket API. Messages sent with the sendmsg() system call can have, embedded within them, control messages which can be used to transfer certain access rights to the recipient of the message. The control message header is defined as:
struct cmsghdr {
__kernel_size_t cmsg_len; /* data byte count, including hdr */
int cmsg_level; /* originating protocol */
int cmsg_type; /* protocol-specific type */
};
These control messages are passed to __scm_send() for checking. One of the first things done with each control message is to look at the length of the message; the 2.6.9 code which performs this check looks like this:
if (cmsg->cmsg_len < sizeof(struct cmsghdr) ||
(unsigned long)(((char*)cmsg - (char*)msg->msg_control)
+ cmsg->cmsg_len) > msg->msg_controllen)
goto error;
The programmer who wrote this code probably thought that all the bases were covered; the control message length was verified to be at least the minimum necessary, but not so large as to overflow the space allocated for control messages in the structure read in from kernel space. The problem is that the cmsg_len field is of type __kernel_size_t, which is an unsigned integer type. If a very large value is stored in cmsg_len, it will cause an overflow in this calculation:
((char*)cmsg - (char*)msg->msg_control) + cmsg->cmsg_len) When this overflow occurs, the resulting sum can be a small number, so cmsg_len does not appear to be overly large to this particular test. At a later point, however, that length will be added to a pointer into the list of control messages. Once again, the addition will cause an integer overflow, with the result that the pointer moves backward. The exploit created by Mr. Starzetz works by creating a message with two embedded control messages. The second one sets cmsg_len to -12. That length gets translated to a very large unsigned number (0xfffffff4 on 32-bit systems); it happens to be just the right value to bump the pointer in __scm_send() backward in the list, where it encounters the same control message structure again. An infinite loops results. Interestingly, this particular vulnerability seems to have been found by another researcher at about the same time. The fix was merged on December 8; the identification of the bug is credited to Georgi Guninski. It is, in any case, fixed, at least for 2.6.10. Some distributors have already made updated kernels available.
Security reports Vulnerability in Slash CVS An advisory has gone out for users of the CVS version of the "Slash" weblog software. It seems a fairly serious vulnerability has been found in that code; details will be released shortly. The Slash hackers are recommending that people running sites upgrade to the current CVS version at their first opportunity.
New vulnerabilities atari800: buffer overflows
file: stack overflow
kernel: IGMP and scm_send vulnerabilities
ncpfs: buffer overflow
PHProjekt: configuration modification
vim: modeline problems
Updated vulnerabilities a2ps: input validation error
apache: arbitrary code execution
aspell: bounds checking problem
cdrecord: failure to drop privilege
ncompress: Buffer overflow
cyrus-sasl: remote buffer overflow
dhcp: format string vulnerability
Filename disclosure vulnerability in fam
flim: insecure file creation
Foomatic: Arbitrary command execution in foomatic-rip
FreeRADIUS: denial of service
gaim: buffer overflow in MSN protocol
Gallery: cross-site scripting vulnerability
gtk2, gdk-pixbuf: buffer overflows
gettext: Insecure temporary file handling
ghostscript: symlink vulnerabilities
glibc: Information leak with LD_DEBUG
glibc: tempfile vulnerability in catchsegv script
gnome-vfs: backend script vulnerabilities
groff: insecure temporary directory
gtkhtml: malformed messages cause crash
gzip: insecure temporary files
hpsockd: missing input sanitizing
ImageMagick: EXIF buffer overflow
imlib: buffer overflows in image decoding
imlib2: buffer overflows
iproute: local denial of service
iptables: missing initialization
kernel: vulnerabilities in the smb file system
kernel-utils: setuid vulnerability
libgd2: buffer overflows in PNG handling
libpng: multiple vulnerabilities
libxml2: multiple buffer overflows
libxpm4: stack and integer overflows
logcheck: symlink vulnerability
lvm10: creates insecure temporary directory
Midnight Commander: extfs vfs vulnerability
mikmod: buffer overflow
mirrorselect: insecure temporary file creation
mozilla products: arbitrary code execution and other vulnerabilities
mpg123: buffer overflow bug
mpg321: format string vulnerability
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
