Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for April 26, 2007Looking back at ELC The CELF Embedded Linux Conference is an interesting event, with a unique mixture of attendees. It is not a developer's conference, but plenty of free software developers could be found there. It's not a business conference, but business people were not in scarce supply either. There was far more representation from countries like Japan and Korea than can be found at many Linux-oriented conferences. All of these people came together to talk about the use and development of Linux in small, special-purpose systems.They have plenty to talk about. Predictions for Linux in the embedded market have always been rosy, and they are getting better all the time. As Motorola's Scott Preece noted in one session, it is now expected that there will be over 200 million Linux-based phones in circulation by 2012. Linux shows up in special-purpose applications on a daily basis - often in unexpected places. Increasingly, Linux is the operating system of choice for small systems. The royalty-free nature of Linux is certainly a reason for its success in the embedded field. If one is selling millions of gadgets, even a small per-unit royalty adds up in a hurry. But cost is not the real motivation here. The ways in which Linux can be modified for specific tasks and the general level of control it gives to vendors are both more important. Also, as Mr. Preece pointed out, there is a ready supply of Linux expertise out there for embedded companies to hire. On the other hand, very few developers go out and learn the Symbian platform on their own. There are advantages to going with a standard system. Given this situation, one would have expected the ELC to be a large event, but it is, instead, surprisingly small. Quite a few embedded systems vendors were present - telephone handset manufacturers were especially well represented - but others were notable in their absence. ELC was not a particularly well-promoted event, which might partially explain its small size. Whatever the reason, it would be nice to see wider participation in the future; this community, like any other, needs to get together occasionally and talk. Participation in the community was an ongoing theme of this conference, from Thomas Gleixner's opening keynote through to the end of the last day. Embedded vendors are famous for going their own way, neglecting to contribute their changes back, and generally pushing the GPL as far as they can. If there is one message which came out of this conference, it might be this: the embedded vendors are aware of their lack of participation and the problems it causes. Many of them - at least, those who came to this event - would like to make the situation better. But they often find themselves in a hard position. Working with the community requires patience, openness, and a willingness to let go of some control. The embedded market, for the most part, does not reward those characteristics. Products come and go after a few months, and, once a product is out the door, and an embedded vendor has little motivation to continue to work with it. So merging product-specific changes back into the projects upon which they were based looks like a cost with little associated benefit. There is little intent to maintain that product into the future, and there will almost certainly be no big software upgrades for it. So the code looks dead. The fact that getting their work into the upstream repositories will help those projects support the next product better is beginning to get through to some companies, but it is a slow process. Getting code into an upstream project - be it the kernel or higher-level software - goes best when that project is engaged from the beginning. A big after-release dump of previously unreviewed code tends to be hard to integrate at best. But the last thing a gadget maker wants to do is to release detailed internal information about its next product months before that product is announced. So late code dumps will likely be a best-case scenario for some time yet to come. Consumer electronics products also tend to be quite static once they are shipped. When Nokia released a major software upgrade for the 770 tablet, it was the first time it had upgraded the software for any product in the field. Openness and modifiability are somewhat strange concepts for this industry. Products like the Nokia tablets and the OpenMoko phone are blazing new trails; many vendors are likely to be watching to see how well these experiments go. Seen in this context, the announcement of the GNOME Mobile & Embedded Initiative fits right in. The GNOME developers, too, are looking to bring embedded vendors into their community and to get them to help make the platform better. They seem to be succeeding: the project claims that there are now more GNOME developers paid to work on embedded applications than on traditional desktop systems. GNOME is already a capable environment for embedded development, allowing developers to use the same software stack on all types of systems. If the project continues to be successful in getting embedded vendors to help build the platform, interesting things are certain to happen. Some vendors have GPLv3 on their minds as well. Many of the libraries being used by embedded systems are licensed under the LGPL; once version 3 comes around, the LGPL will be essentially a patch to the GPL giving some extra permissions. So the LGPL will continue to allow proprietary applications to be used with the libraries. The LGPL does not, however, waive the anti-DRM provisions of GPLv3, meaning that users will have to be able to replace any LGPLv3-licensed libraries on their gadgets. Such replacement could allow application behavior to be changed in interesting ways - and badly mess up any lockdown scheme. How that will play out remains to be seen; embedded vendors may gain a renewed interest in technologies like SELinux or AppArmor to keep embedded applications firmly sandboxed. These issues will certainly be worked out; the incentives to do so are strong. The embedded Linux community is on a roll, and rightly so. Linux has all of the right features and freedoms to be an attractive platform in that arena. If this industry can pull together into a true community - with the users as members too - there will be few limits on what it will be able to achieve.
The GNOME Mobile & Embedded Initiative A few days ago, LWN looked at the discussion surrounding the GNOME project's mystery announcement at the 2007 Embedded Linux Conference. That announcement turns out to be the GNOME Mobile & Embedded Initiative, a determined push to bring about world domination in the embedded area.
In recent times, the shipments of desktop PC's are in decline. On the other hand, laptop shipments are growing, and the shipments of other mobile devices are growing rapidly. There are, says Jeff, more developers paid to work on the GNOME platform for embedded use than for the desktop. Mobile devices, it seems, are the future. This is the situation that the GNOME Mobile & Embedded Initiative was created to take advantage of. There is a long list of companies and projects which have signed on to this effort - see the obligatory collection of quotes for details. Much was made of the fact that the initiative is a cooperative effort including both companies and free projects. The initiative, says Jeff, is about writing code. All of that code will have the full GNOME platform available to it (if it needs it), and will be ABI-compatible with the desktop platform. This "is not toy GNOME," it's the full thing. The platform will carry the GNOME LGPL license, making it available to proprietary applications - royalty-free, of course. And it's shipping today, though the first official release will be with GNOME 2.20 in September. A wide variety of devices is covered by this platform. Examples given at the conference include the Nokia N800 (an Internet tablet device), the One Laptop Per Child XO system, the OpenMoko phone, and, at the novel end of the scale, the upcoming Vernier LabQuest, a handheld data acquisition and display device with a vast list of sensors available to it. The LabQuest was held up as an example of a device which was developed by a company with little software expertise; the Linux and GNOME platform made the whole thing relatively easy. All of these, says Jeff, are "beautiful new ideas" enabled by the open source stack. The initial code from the GMAE initiative is available now. Possible additions in the near future include display frameworks from a number of sources (examples include the OpenMoko framework and the Hildon desktop used on the N800), applications like TinyMail, integration of GeoClue, and more. There's also low-level initiatives like better touchscreen support in GTK, fixing the floating-point usage in Cairo, etc. Beyond that, time will tell; chances are it's going to be interesting.
Do free software projects need marketing teams? The announcement of the GNOME Mobility & Embedded Initiative was generally popular within the GNOME project itself. There was one complaint which could be heard in the right places, however: it seems that this whole initiative was conceived of and agreed to without the involvement of the GNOME marketing team. One might well ask: if the marketing team does not get involved in an agreement like this one, what does the project keep it around for?There's a couple of responses which are worth a read. Dave Neary, a member of this team, had some stark comments:
Here it is again: no-one cares about the marketing team. We produce
nothing. We have not shown ourselves to be useful. So no-one is
going to come and talk to us about anything until that changes.
Jeff Waugh, the driving force behind the embedded initiative, states:
We make things happen by taking the reins, establishing buy-in, and
kicking arse. Not by waiting to receive blessing or permission.
One might well argue that the GNOME marketing team has failed to live up to expectations. Some members of the team are doing so and beginning to think about ways to change that situation. As a result, we might well see a more active team in the future. But there is a question which is worth asking here: to what extent might the comments quoted above apply to any project's marketing team? It might just be that a project which is trying to grow its user and development community has little to gain from the formation of a marketing group. In the corporate environment, a marketing team takes a leading role in identifying potential customers, designing something that those customers might just want to buy, and finding ways to motivate customers to make that purchase. Once a marketing strategy has been worked out and adopted, the rest of the company is expected to work to execute that strategy. In successful companies, marketing tends to lead the way. Most free software projects are not amenable to this sort of leadership. What gets done in free software is what individual developers decide to do - or are told to do by their employers. Paid developers may well be working toward the execution of a marketing plan, but it's their employer's plan, not the project's plan. Free software hackers will be working to make a project better, but they are not marching to the project's drummer. They will not seek approval from a project's marketing team when they decide what to hack on. The same is true of project members who work to create initiatives or alliances in a specific area. GNOME's support of embedded applications comes as a result of work by interested developers and the companies which are operating in that area. It was a natural consequence of the way the embedded market is going; there was no need for a marketing team to foresee, plan for, or mandate a bigger role for GNOME in the embedded marketplace. If a GNOME marketing group were to call for such a role, it would have little effect on GNOME developers working on more traditional desktop applications. Free software projects are not corporations; free software users and developers will not wait for a marketing group to sign off on their plans. Some projects do have marketing organizations which appear to be effective. The push behind the Firefox browser is arguably one of the most prominent examples; the alliances and promotional campaigns which have been arranged have undoubtedly helped to increase adoption of the software. The marketing of packages like MySQL has also been effective. There is a pattern to be seen here: in almost all of the cases where a free software project has had an effective marketing operation, that project is owned and controlled by a single corporation. In such cases, the project's marketing plan is, in fact, a component of the company's plan; it's the company's control of the project which allows its marketing objectives to drive what the project does. In the absence of that sort of control, it's not clear what a free software project's marketing team can achieve. Certainly a marketing group can point out areas of opportunity in the hope that developers will choose to pursue those opportunities. Such pointing-out must be done carefully, though; free software hackers tend to be irritated by those who seem to be trying to tell them what to do. Marketing teams can also fulfill a useful sales role by, for example, organizing booths at trade shows, distributing live CDs, convincing distributors to package the software, etc. But it's not the marketing group which will bring about a project's success; that depends on the code, artwork, music, documentation, support, etc. provided by the project's members. A project is made by its community, not by a marketing plan. It's hard to imagine wanting that to change.
Page editor: Jonathan Corbet Security Two years of RHEL4 risk A recently released report on the security track record of Red Hat Enterprise Linux 4 (RHEL4) sets out to quantify the risks that an administrator would have faced when using the distribution. It takes a comprehensive look at all of the vulnerabilities that were classified as 'critical' in the two years since RHEL4 was released. A measure of pride is evident in the recognition that there were only three critical vulnerabilities in the default server install, a rather nice accomplishment; the study itself is an even better result and it should set the bar for other similar studies in the future. In stark contrast to almost daily studies that purport to 'prove' that Redmond's latest offering is vastly superior to Linux in the security arena, the RHEL study simply looks at the reported vulnerabilities in that distribution and leaves any comparisons for others. The study mainly focuses on the critical vulnerabilities, but it does look at the 'Vulnerability Workload Index' for a server install with all available packages. This index is meant to give a rough measure of the amount of work an administrator would need to do to keep a system free from all vulnerabilities. The most interesting conclusion that can be drawn from the graph is that the overall workload is pretty flat, there are certainly peaks, but it is neither increasing nor decreasing over time. Because the software released with RHEL4 is, of course, getting older and the upstream projects are likely to be releasing newer versions, a case could be made either way regarding increasing stability vs. more security issues found over time and it would appear that the two roughly balance each other. Flaws that get the 'critical' designation are those that can lead to a system compromise in an automatic way without any user action. These are the kinds of bugs that could be exploited by worms to invade and propagate. The critical designation has been stretched to cover web browser bugs that are exploited when a user visits a site with malicious code. The vast majority of critical bugs fall into the latter category and that difference leads to 60 flaws in a system with all packages installed, 50 of which can be traced to Mozilla products or the HelixPlayer plugin. The study goes into the 60 critical flaws in some depth, categorizing them by type and reporting on the so-called 'days of risk' (number of days after a vulnerability report before a fix is available). All critical flaws were fixed within two calendar days and 60% were fixed on the same day. The riskiest packages are also listed using a weighted score based on the number and severity of bugs in that package with various Mozilla projects coming out on top. Interestingly, the kernel dropped from #1 last year to #4 in the current report. The risk to a system is not only a function of the vulnerabilities in the packages it has installed; exploits 'in the wild' also factor into it. The report looks in detail at exploits for 37 vulnerabilities, many of which are, unsurprisingly, either browser or 'user complicit' exploits. Triggering a user complicit exploit requires convincing a user to perform some action with a malicious file; because administrators should be wary of such things or even of running a browser from a privileged account, the impact of those exploits are limited. The seven kernel and six server exploits represent a more dangerous class, with system compromise a distinct possibility. None of the kernel exploits were remote and all were either denial of service or privilege escalation bugs. Each of the server application exploits could lead to compromise of the non-root user that runs the service. It is interesting to note that SELinux and Exec-Shield are specifically mentioned as either eliminating or reducing the impact of eleven of these exploits. Both of these security tools are installed by default with RHEL4 and are targeted at stopping or reducing the effectiveness of just these kinds of attacks. Exec-Shield uses address space randomization and protection against executing code from the stack to avoid executing arbitrary code in the presence of a buffer overflow or similar flaw. The SELinux policy that ships with RHEL4 restricts users and processes to only that set of resources they need for their normal function and that can reduce the kinds of problems an exploited process can cause. While they are no substitute for correctly written code, these technologies are clearly helpful to reduce security threats; with luck other techniques will come along that continue this kind of work. This is the second report on RHEL4 security; the first covers the first year of release. Based on a comment on his original article, the author is planning a four year retrospective on RHEL3 in November which should be interesting as well. The comment indicates only six critical vulnerabilities in the RHEL3 default install in its three and a half years. It is difficult to put a label on the level of 'security risk' that a particular system has, but RHEL4 would seem to have a fairly low risk overall. If one keeps up with the patches and is reasonably cognizant of security practices, the chances for a system compromise are low. This is a real accomplishment by the Red Hat team and should be a feather in the cap for Linux in general. No software is perfect and an operating system or distribution is just a collection of software so vigilance is required. Without examining our track record, it is difficult to gauge progress and this kind of report is an excellent way to track that progress; hopefully other distributions will follow suit.
New vulnerabilities 3proxy: buffer overflow
aircrack-ng: remote execution of arbitrary code
blender: user-assisted remote execution of arbitrary code
clamav: several vulnerabilities
Courier-IMAP: remote execution of arbitrary code
opera: several vulnerabilities
postgresql: privilege escalation
sqlite: buffer overflow
webcalendar: cross-site scripting
Updated vulnerabilities apache: cross-site scripting
Asterisk: two SIP denial of service vulnerabilities
bluez-utils: hidd vulnerability
bugzilla: multiple vulnerabilities
busybox: insecure password generation
cpio: arbitrary code execution
cups: denial of service
Cyrus-SASL: DIGEST-MD5 Pre-Authentication Denial of Service
dokuwiki: cross-site scripting vulnerability
dovecot: index cache file handling error
dovecot: information exposure
evolution: format string error
fail2ban: denial of service
ffmpeg: buffer overflows
file: denial of service
file: arbitrary code execution
firefox: FTP PASV port-scanning
freeradius: memory leak
freeradius: several vulnerabilities
freetype: integer overflows
gcc: file overwrite vulnerability
gd: buffer overflow
gdb: buffer overflow
gdm: improper file permissions
gzip: multiple vulnerabilities
horde-kronolith: local file inclusion
ImageMagick: integer overflows
imlib2: arbitrary code execution
ipsec-tools: denial of service
java: multiple vulnerabilities
kdelibs: cross-site scripting
kernel: denial of service
kernel: multiple vulnerabilities
kernel: denial of service
kernel: multiple vulnerabilities
kernel: denial of service
kernel: denial of service
kernel: denial of service by memory consumption
kernel: denial of service
kernel: denial of service
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Jeff
Waugh]](/images/conf/elc2007/JeffWaugh-sm.jpg)