Advertisement
Advanced thin client solution for Linux, based on Open Source. Mix Windows and Linux applications on the same desktop.
Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for December 18, 2003Looking forward to Fedora Core 2 Commercial Linux distributions have provided much of the driving force behind the increasing adoption of free software. These distributions tend to be high-quality products, and most Linux users end up running one of them. One disadvantage of commercial distributions, however, has typically been the relatively closed nature of their development process. It is hard to know where a distribution is going until the next release arrives; consider how surprised many Red Hat users were when the expected Red Hat Linux 8.1 release turned into Red Hat Linux 9 with a number of disruptive changes. This situation is not unique to Red Hat; of the commercial distributions, only Mandrake has really gone out of its way to open up its development process to its users.The evolution of Red Hat Linux into Fedora has changed things. Red Hat may still guide Fedora with a firm hand, but the process is now being carried out in a relatively open manner, with input from the wider community. As a result, it is possible to develop a reasonable idea of what will appear in the Fedora Core 2 (FC2) release, which is now scheduled for April 5, 2004. From the beginning, FC2 was destined to be based on the 2.6 kernel. It will thus likely be the first big-name distribution to be truly committed to 2.6, rather than just offering it as an option. There may be a backup 2.4 kernel available for systems that simply can't run 2.6, but its use will probably be rare. FC2 is not stopping at adopting 2.6, however; this distribution will also be set up to use the NSA Security Enhanced Linux (SELinux) subsystem. SELinux is packaged with 2.6 (as a Linux security module), but actually making use of it is not just a matter of turning it on. SELinux is based on a complex, rule-based mandatory access control mechanism which requires that a whole set of rules and policies be created. To this end, Red Hat has hired Russell Coker, who got his start in this area doing SELinux work for Debian. Russell's SELinux work will show up in FC2, and, after the Fedora users have shaken out the bulk of the problems, in the Enterprise Linux Advanced Server products. FC2 will also include full IPSec support, given that the requisite protocol support exists in 2.6. Not everybody is happy with the choice of IPSec-Tools for configuration and management, however. A big issue on the fedora-devel list was whether GNOME 2.6 would make it into FC2. Nobody spoke against the idea, but Fedora leader Michael Johnson did point out one issue with GNOME and Fedora: how their respective schedules work together. GNOME tries to make releases every six months, while Fedora is trying to go a little faster than that. The result is that, sooner or later, Fedora will miss a major GNOME release and spend a few cycles catching up. Recent discussions suggest, however, that GNOME 2.6 will be in FC2. The FC2 release schedule should allow the developers plenty of time to incorporate the imminent KDE 3.2 release as well. Web browsers are a topic of conversation. It may be hard to remember that, only a few years ago, the only real browser alternative for Linux was the proprietary Netscape 4.x release - and we were glad to have it. There are now so many browsers available for Linux there there is no real hope of including them all. For FC2, it looks like the choices may be Konqueror, Epiphany, and Mozilla. In the future, when Mozilla Firebird stabilizes somewhat, it may replace Mozilla "classic" in Fedora. There have been a fair number of requests to drop sendmail in favor of a more secure mail transfer agent. Postfix would appear to be the preferred replacement. There does not appear to be a whole lot of desire within Red Hat to change the system's MTA, however, so sendmail looks likely to hang around for a while yet. One user requested a natively-compiled version of the Eclipse development environment. That wish appears likely to come true; the FC2 schedule states that a number of Java components, compiled with GCJ, are on the list to be incorporated into the distribution. There is a fair amount of interest in a "bare-bones" installation mode. A minimal install could be used for old and small systems, or as a base platform for a subsequent network install (much as Debian installations can be done). This "bootstrap" install option may well show up in FC2. Some desired packages will be kept out as a result of licensing issues. Thus valgrind, though often requested, is off the list; it apparently suffers from software patent problems. MySQL 4.x is also an interesting problem; with the 4.x release, the license on the MySQL libraries was changed from the LGPL to the GPL. That change makes it harder to write proprietary applications using the libraries, which can be a concern for distributors (UserLinux is coping with similar issues). The MySQL 4.x library license, however, also blocks the use of MySQL with PHP, which has a GPL-incompatible license. A MySQL/PHP adaptor, as a derived product of both systems, cannot be distributed. So MySQL 3.x will likely be in Fedora Core for a while yet. The actual Fedora Core 2 release will doubtless contain some surprises. But it will be, by far, the most open release ever to come out of Red Hat. This visibility into the development process will give Fedora users the opportunity to be better prepared for future releases (a good thing, since quick upgrades will be required to keep getting security patches) and to have some influence on how the distribution is developed. It is too soon to say whether Fedora will be a success, but the new approach to its development is already showing some benefits for its users.
A look at Thunderbird 0.4 Now that Thunderbird has reached its 0.4 milestone, we thought we would take it for a test drive and see how far the new email and newsgroup client has come. The conclusion is that Thunderbird is indeed maturing into quite a nice email client.
Setting up Thunderbird is as simple as uncompressing a tarball in the
directory you'd like Thunderbird to live in. Configuring Thunderbird is
likewise an easy task, and it only takes a minute or two to have the client
One of the more exciting features with Thunderbird is adaptive spam filtering. Users can tag email as "junk" and Thunderbird will try to automatically determine which incoming email is spam in the future. This feature is not on by default, so the user will need to enable the junk folder and features. Thunderbird's adaptive junk mail controls aren't perfect (yet), but after only using Thunderbird for a little more than a week, I found that it was catching on pretty quickly. Thunderbird didn't tag all of the spam I received as junk, but it didn't tag any of my legitimate email as junk after a few days. While some may be annoyed when they see spam slip through Thunderbird's filter, I'm much happier to know that it does very well at avoiding false positives. There is also a junk mail log, so users can follow which messages have been tagged and moved. I would recommend using the Junk folder rather than deleting messages for at least a few weeks. As the developers point out in the release notes, the default interface for Thunderbird has matured since the last release, and is looking very nice. If the default theme isn't quite right, Thunderbird allows the user to choose custom themes instead. Right now there are about twenty themes available for Thunderbird. Installation of themes is easy, though it's still necessary to restart the application once you've installed a new theme. Themes aren't the only thing that's changeable. One of the nicest features of Thunderbird is the ability to add extensions to the application. One of the goals for Thunderbird was to stay "small and unbloated," which is a laudable goal. However, most users will differ on the features which are necessary, and the features that should be considered bloat. Extensions allow users to modify Thunderbird's feature set to their liking; available extensions include a calendar, external application launchers, "splitter grippies," a calculator, an offline operation mode, and numerous others. Installing extensions in Thunderbird is as simple as downloading an extension and running the "Install New Extension" wizard. By default, (unfortunately) Thunderbird's message composer is set to send mail in HTML format rather than plain text, but this behavior is easy to turn off. If a user prefers to send HTML-formatted email, or if certain recipients prefer to receive HTML-formatted email, Thunderbird allows the user to set specific domains that will receive plain-text or HTML email. However, at this point this feature only works if the user has Thunderbird set to compose HTML email by default. It would be nice if this worked both ways, so a user could send grandma HTML emails by default and avoid getting flamed by accidentally sending HTML email to a mailing list. Another welcome feature in Thunderbird is customizable message views. Users are able to view messages according to a wide range of criteria, which makes it very easy to sort through your inbox. For example, the user can choose only to view messages with attachments, or only messages sent by people who are in their address book. Thunderbird includes only a few preset filters, but users can create others of their own. One of the few gripes I have with Thunderbird is that it only allows the user to import mail from Communicator 4.x clients. If the user wishes to switch from Pine, Evolution, Outlook, Eudora, Sylpheed or any number of other mail clients, there is no automated tool with Thunderbird to help with the task. A simple utility to import email stored in mbox format would be a nice addition, and might help Thunderbird add to its user base. It should also be noted that the application isn't entirely stable. It did crash during testing a few times though it didn't lose any messages or important data. Note that I experienced crashes during testing before installing any extensions, so it wasn't the addition of third-party code that caused the problems. The interface is also a bit slow, even on a fast machine. Often, it takes a few additional seconds for dialog boxes to disappear completely and for new windows to appear. Of course, one does not normally expect perfection from such an early release. Overall, however, Thunderbird is a well-designed mail client, and is quite usable for an application that is only a 0.4 release. I expect that as Thunderbird matures, the stability will improve even further and that the speed of the interface will also be improved. Thunderbird should be acceptable for daily use for users who are looking for a different mail client. Though I only tested the Linux version of Thunderbird, there are also builds for Windows and Mac OS X for users of those platforms.
The continuing Linux Gazette saga We first reported on the dispute over the direction and management of the Linux Gazette back in November. Since then, the Linux Gazette has tended to resemble a forked development project; both LinuxGazette.com (at SSC) and LinuxGazette.net (where the departing editors set up shop) remain online. Both have published an Issue #97 for December. Each maintains its own "Answer Gang." And both claim to be the real Linux Gazette. Behind the scenes, however, things have been happening.There have been repeated charges that LinuxGazette.com has been censoring its forums to keep them free of criticism of SSC's actions. SSC, it would seem, has dealt with that issue by eliminating the forums altogether. Most of the forum posts will, evidently, be simply deleted. SSC has sent a letter claiming trademark rights over the name "Linux Gazette" and requesting that ownership of the LinuxGazette.net domain name be forcibly transferred. Over at LinuxGazette.net, they respond that no trademark was ever transferred to SSC when it started running the Linux Gazette, and, in any case, the Linux Gazette is a noncommercial operation. In the U.S., trademarks are for commercial use and cannot be obtained for names which are not used in a commercial setting. Rick Moen, of LinuxGazette.net, took the time to track down John Fisk, who founded the Linux Gazette back in 1995. In his response, Mr. Fisk betrays a clear desire to not get drawn into the current dispute. He also states, however, that he had no intent to transfer any sort of trademark rights to SSC when he let SSC take over operation of the Linux Gazette. In other words, the waters have been well and truly muddied. If the rights to use the "Linux Gazette" name end up being the subject of a legal battle, it is hard to predict what the eventual result would be. One can predict, however, that such a fight would not be good for either Linux Gazette, the people who contribute their articles, or the community as a whole.
It's that time of year For the sixth year in a row, LWN has put together its annual Linux Timeline. We've gone over the events of the last year, sorted out the most significant happenings and quotes, and put them together in a concise, informative, and (we hope) fun form. Have a look and relive the last year in the Linux world - some of which even doesn't involve SCO.The next Weekly Edition will be published on December 24, one day earlier than usual, in anticipation of the Christmas holiday. There will be no Weekly Edition the week of January 1; the front page will continue to be updated, however, and we may put up a feature article or two. We will return to our regular schedule on Thursday, January 8.
Page editor: Jonathan Corbet Security Security news Spam-proofing the mail system One of the major problems with Simple Mail Transport Protocol (SMTP) is that it allows email senders to forge information about who they are. The lack of sender authentication allows unscrupulous users to send email that appears to come from a domain other than where it truly originates. Spammers use this 'feature' to disguise their email and to cause any bounces or responses to be handled by someone else.There are several proposals for combating this problem that are currently being worked on; we will describe some of them below. Before we do, however, a bit of a review on how SMTP currently works is in order. When a host wants to send mail, it looks at the DNS Mail Exchanger (MX) record for the destination domain and makes a connection to the host that is indicated. The sending host identifies itself, the email address of the sender of the message, and the address of the recipient of the message to the destination host via SMTP messages. This is known as the envelope of the message and, if it is accepted by the destination host, the sender proceeds to send the body of the message. The message body contains RFC822 headers (From:, To:, Subject:, etc.) that are used by Mail User Agents (MUAs) to identify the message to users. SMTP servers traditionally do not do any kind of checking on the envelope data they receive, believing that other hosts will not deceive them. Any part of the envelope and RFC822 headers can be forged (except, of course, the recipient in the envelope). Obviously, SMTP has its roots in a much friendlier Internet where trusting other hosts was the norm. Recently, Yahoo announced an initiative that is meant to combat spam called Domain Keys. Technical details are somewhat sketchy, but the basic idea is that the DNS records for a domain would include a public key. Email that originates from that domain would use the corresponding private key to encrypt some data (it is not clear exactly what, but a cryptographic hash of the message contents would seem an obvious choice) that would be placed in an email header. Mail Transfer Agents (MTAs) that received the message could decrypt it using the public key in the DNS record and if the decrypted value was correct, the MTA would know that the message originated from the domain that was claimed. Sender Permitted From (SPF) is a proposal to add information to the DNS records for a domain specifying what machines legitimately send email for that domain. This information is the reverse of the MX record, rather than specifying hosts that receive email for the domain, they specify hosts that send it. This would allow MTAs to check the IP address of the sender and the host name provided in the SMTP envelope along with the SPF information in DNS to determine whether that IP address is a legitimate sender for that domain. (LWN covered SPF in more detail last October). The Trusted Email Open Standard (TEOS) is a wide-ranging proposal that has three implementation steps and would eventually allow for third-party certification of email messages as coming from a trusted source. This scheme would operate in some ways like the SSL Certificate Signing Authorities; an MTA could verify that a message came from a source trusted by the third party. The first step that TEOS proposes is similar to the Domain Keys proposal; it would provide a way to authenticate email senders. The second stage adds the ability for senders to make assertions about the contents of the email, saying, for example, that it contains advertising or an opt-in mailing, or that the sender and recipient have a business or family relationship. Users would be able to filter the mail based on the assertions (or lack thereof). If the sender incorrectly categorizes a message, the authentication will not allow the blame to be shifted elsewhere, providing a large incentive to be truthful when making the assertions. The Tripoli proposal envisions an entirely new email infrastructure, at first running in parallel with the current SMTP-based system, but eventually supplanting it. The underlying principle is that the receiver of email should have greater control than any of the other parties involved, including the sender, ISPs that transmit the email, or governments. The system proposed would eventually have end-to-end encryption for all email traffic. Associated with each email would be a cryptographic token that is certified by a third-party to a particular level of authentication; email recipients could then choose the level of authentication that they wish to require and can reject any messages that fall below this standard. These proposals are a testament to just how problematic and widespread the spam problem has become. The scope of some of these proposals, particularly TEOS and Tripoli, show how far some people are willing to go to try and combat it. Adding third-parties to email sending could have a number of security and privacy concerns and would almost certainly add a cost to sending email. If that cost breaks the current economic model of spamming, however, it may be effective, but it would also impact lots of other bulk email uses today (legitimate mailing list traffic, opt-in newsletters and the like). On the other hand, Domain Keys and SPF could be circumvented by spammers willing to create throwaway domains that conform to the requirements. Once the domains are identified as spam domains, they can be added to blacklists, of course, but there have been any number of problems with that particular solution as well. Authenticating senders might help track down spammers, but until the risk of detection and the cost of conviction are greatly increased, it is likely to only slow things down and perhaps not by much. It should be interesting to watch the battle over our email inboxes play out over the next few years. It may well be that one or more of these proposals is adopted (or some combination of them) by a significant portion of email users and providers. Unfortunately, in the meantime, less technical email users are suffering at the hands of the spammers to the point where email is no longer a useful communications medium for many.
New vulnerabilities lftp buffer overflows
xchat: remotely exploitable denial of service vulnerability
Updated vulnerabilities 2.4 kernel - several vulnerabilities
apache: buffer overflows in mod_alias, mod_rewrite
apache2: Denial of Service vulnerability
bind: cache poisoning
CUPS: denial of service
cvs: unauthorized file creation
ethereal: multiple remote and local vulnerabilities
Filename disclosure vulnerability in fam
fetchmail may crash on specially crafted message
fileutils/wu-ftpd: denial of service
FreeRADIUS: Denial of service vulnerability
glibc: DNS stub resolvers contain buffer overflow vulnerability
GnuPG: ElGamal signing keys compromised
gtkhtml: malformed messages cause crash
iproute: local denial of service
KDE: Two issues in KDM
kernel: local root exploit in 2.4.22
kernel-utils: setuid vulnerability
libnids: remotely exploitable buffer overflow
libpng, libpng3: buffer overflow
mikmod: buffer overflow
mpg123: heap overflow
mplayer: remotely exploitable buffer overflow vulnerability
Nessus NASL scripting engine security issues
Net-SNMP: security bugs in versions before 5.0.9
nfs-utils xlog() off-by-one bug
openssh: timing attack leads to information disclosure
Pan: denial of service
postfix: denial of service vulnerabilities
proftpd: remote root shell
rsync - remotely exploitable heap overflow
Multiple-use vulnerability in Safe.pm
sane-backends: several vulnerabilities
screen: privilege escalation
File overwrite vulnerability in tar and unzip
Multiple vendor telnetd vulnerability
vim - modeline vulnerability
wget: buffer overflow
zebra: denial of service vulnerability
Resources December CRYPTO-GRAM newsletter Bruce Schneier's CRYPTO-GRAM newsletter for December is out. It looks at whether the Blaster worm caused the August 14 blackout (he thinks it may have), electronic voting, and products using quantum cryptography. "I don't have any hope for this sort of product. I don't have any hope for the commercialization of quantum cryptography in general; I don't believe it solves any security problem that needs solving. I don't believe that it's worth paying for, and I can't imagine anyone but a few technophiles buying and deploying it."
Page editor: Jonathan Corbet
Kernel development Release status Kernel Release Status The current development kernel is 2.6.0-test11; there has been no development kernel release since November 26. Linus continues to accumulate small, critical patches in his BitKeeper repository, but appears to be waiting for Andrew Morton to return to the scene for the preparation of the next release, be it another -test kernel or the real 2.6.0.Andrew did release 2.6.0-test11-mm1 on December 17. The -mm tree now contains a full 300 patches, ranging from small fixes to new drivers and major subsystem work. Andrew has indicated that at least some of the patches in -mm will find their way into the mainline after 2.6.0 comes out. The current stable kernel is 2.4.23; Marcelo has not released any 2.4.24 prepatches since 2.4.24-pre1 on December 10.
Kernel development news Lustre 1.0 released Linux-based clusters | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![[Screenshot]](/images/ns/thunderbird-sm.jpg)