Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
LWN.net Weekly Edition for August 4, 2005Wiring DRM into the system An interesting bit of corporate research was recently performed by the EFF's Seth Schoen, who attended the Microsoft Windows Hardware Engineering Conference and wrote up a four-part report on what he learned (part 1, part 2, part 3, and part 4). The resulting picture suggests that Microsoft is going out of its way to appease the entertainment industry with its future products. Upcoming Windows releases will be able to ensure that no "unauthorized" hardware or software exists on the system. Load an application which the "protected media path" code does not like, and much of the system's multimedia capability could be shut down. A Microsoft-controlled "revocation list" will allow drivers to be disabled by Microsoft in the future should those drivers be determined to not properly implement the DRM specifications. Overall, it is a vision of a world where "our" computers are, increasingly, not under our control and not operating in our interests.The comments on the original LWN posting pointing to Seth's reports suggest that many readers believe that this sort of intrusive DRM technology will provoke a massive consumer backlash and, as a result, fail in the market. There are some signs that this hope could be realized; there is currently a fair amount of grumbling in the U.S. over the HDCP copy-protection mechanism, which can prevent the delivery of high-resolution video to large numbers of high-definition TV monitors which do not implement HDCP. As others have often said: Americans will put up with all sorts of misbehavior from both governments and corporations, but they will not tolerate anybody who messes with their TV. All of this may be wishful thinking, however. It may well be that the industry will get its DRM technology working to the point that it no longer interferes greatly with the life of the average couch potato. If things "just work" for most people, they will be accepted by those people. Few of us have the time or knowledge to worry about the larger issues of fair use, control over our own systems, or long-term sustainability of the cultural commons. After all, there's a game on in a few minutes. Consider also the reports that Apple is planning to make use of the trusted platform module (TPM) chip in its future kernels. The primary purpose here, most likely, is to keep people from running Mac OS on non-approved x86 systems. But it is hard to believe that Apple would not also use the TPM, for example, to help ensure that audio files do not escape from the one system where they are authorized to be. Then consider that the latest Linux kernel includes basic TPM support, and work is underway to increase that support. As was discussed at the Ottawa Linux Symposium, the TPM can do a number of good things for Linux users. It can also, however, be used to deprive a Linux user of control over the system and implement all of the same DRM stuff which is being added elsewhere. A Linux-based set-top box could be just as user-hostile as one based on Windows. Availability of source would not be helpful in such a situation; the TPM can be used to ensure that the system will boot only kernels which have been signed with a specific key. Linus Torvalds has stated in the past that this sort of usage is fine with him. Now, Linus is not the only copyright holder for the kernel, and others may yet decide that the GPL requires that the keys used to sign the kernel be distributed with the source. The GPL's source distribution requirements do include "the scripts used to control compilation and installation of the executable," after all. It may even be that a court will buy that argument. But any such finding will be at the far end of a long process of litigation; it is an uncertain and distant prospect. In the mean time, it is safe to assume that we will see more systems which, while running Linux, allow no more user control than their equivalents based on proprietary software. At OLS, Jim Gettys compared the DRM situation to the American experiment with crypto export regulations. We'll win in the end, but there may be a decade or two of pain in the middle. Sadly, it appears that we are just beginning to enter the "pain" phase of this battle. This is a fight we can win; we will likely be helped by the fact that the entertainment industry will have a hard time stopping short of the point that makes consumers rebel. But there may indeed be some unpleasant times between here and there.
Cisco v. full disclosure The story has been sufficiently widely reported that we do not need to go into the details here; see Bruce Schneier's summary if you have some catching up to do. In short: Cisco is going after ex-ISS employee Michael Lynn after he made a presentation in Las Vegas on security vulnerabilities in Cisco's IOS. There is now an FBI investigation in the works, and Mr. Lynn faces the possibility of lawsuits from Cisco or ISS (or both). Meanwhile, copies of his presentation are circulating on the net, closely followed by lawyers with takedown notices. BoingBoing has posted a list of mirrors for those of you who have not yet gotten your copy.Cisco's argument is that Mr. Lynn's presentation discloses Cisco's trade secrets. By this reasoning, Cisco's customers are not entitled to know about vulnerabilities in the boxes they have used to put their networks together. In fact, it appears that Cisco has known about this vulnerability since April, but did not see fit to tell its customers - or anybody else - about it until after Mr. Lynn's presentation. Cisco's concern for its public image has clearly outweighed its concern for its customers' security. The company has turned against disclosure of security problems, and also seems to have forgotten what the net has taught us over the last twenty years or so: attempting to suppress information which has escaped onto the net is not only futile, but it increases the distribution of that information. There is another aspect of this situation which is worth looking at, however. It has often been said that users of embedded systems do not care about which operating system is running inside. The system is invisible, and all that matters is that it does its job. Security problems clearly increase the visibility of an embedded system. But so do trade secrets, and in an unpleasant way. If Cisco's routers ran Linux, there would be no question of the company using trade secrets to shut down disclosure of vulnerabilities in the core system. There cannot be trade secrets embedded within GPL-licensed code - at least, any such secrets will not remain secret for long. So an attempt to use trade secrets to block disclosure of a security problem is almost certain to fail. This is a good thing, and a nice added benefit from the use of free software. People may not care about the code running inside their router, phone, music player, automobile, or Furby, but they may yet learn to care about having vulnerabilities in those devices hidden from them. Among the many promises carried by free software is this one: it does not contain secrets which may be used to censor those who would tell you about a problem with your gadget. That is a worthwhile freedom.
Our bloat problem Andy Oram's report from the Ottawa Linux Symposium notes that OpenOffice.org took some grief there:
Already, two speakers have made wisecracks about OpenOffice.org,
tagging it as a bloated memory hog. I have the suspicion that some
attendees see Linux as something to run for its own intrinsic
value, rather than as a platform for useful applications that can
actually help people accomplish something.
As one of those speakers, your editor will plead guilty to taking a cheap shot for an easy laugh (and people did laugh). But the remark had nothing to do with the value of OpenOffice.org as an application. It was about bloat. In a private conversation at the same conference, an engineer working with a services company in a developing country mentioned a valuable line of business for his employer. It seems that there are customers with large numbers of older desktop computers running legacy operating systems; they would like to extend the life of those computers by putting Linux onto them. But Linux does not run as well on these systems as anybody would like; it is simply too big. OpenOffice.org is especially problematic on smaller systems, but the problem does not stop there. Not that long ago, Linux was a relatively small and fast system which could run well on a wide variety of older hardware. That may still be true in some specific cases - Linux-based firewall/routers, for example - but, as a general-purpose operating system, Linux has become just as bloated as its proprietary competition. Your editor just looked at his desktop system, with two days of uptime, to see where the memory went. A few examples:
It is a sad world when 10MB of memory is required to display a clock, and 21MB to run a terminal emulator. Developers who have taken a class in data structures have probably heard all about time-space tradeoffs. Programs can often be made faster at the expense of higher memory usage. The truth of the matter, however, is that these tradeoffs are often illusory. Big code is slow code. From inferior processor cache usage through to virtual memory thrashing, large code slows things down across the entire system. On contemporary systems, the way to faster code is often by using less space, not more. There are signs that more developers are beginning to understand the costs of bloat. There is a GNOME memory reduction project underway, for example, though it does not appear to be progressing rapidly. But a more serious effort will be required if the Linux desktop is going to lose some significant weight. And it should lose that weight. Some growth is to be expected from the development of the software itself - Linux systems can do much more than they could a few years ago. But it seems clear that much of our development has been aimed at the addition of new features, and relatively little attention has been paid to memory usage. At this point, Linux need not feel insecure about the features it offers; maybe the time has come to put some more effort into implementing those features with fewer resources. Otherwise, Linux is inflating itself out of a number of possible applications and losing the leanness which used to be one of its best attributes.
Page editor: Jonathan Corbet Security A look at NuFW In many environments, it's sufficient to set up a firewall to filter traffic based on IP address. However, in some situations, an administrator may wish to set up a firewall that can actually filter packets based on the user, rather than the IP address that packets are coming from. A typical firewall using Netfilter is capable of filtering traffic and setting QoS rules only by the originating IP address, and doesn't recognize the concept of users at all.Now User Filtering Works (NuFW) is a package that promises the ability to do a lot more. NuFW is a package that runs on top of Netfilter and allows packet filtering and quality of service (QoS) rules to be assigned by user or application, rather than by the machine or IP address that packets originate from. This makes it possible to apply finer-grained permissions than are possible with Netfilter alone. There are two daemons that run to provide NuFW's services. The nuauth daemon - the authentication server for NuFW - and the nufw daemon, which runs on the firewall and works in conjunction with Netfilter to actually filter traffic. It is not necessary for the nuauth and nufw daemons to run on the same server, so an administrator can set up nufw on the firewall, and nuauth on any other machine that the firewall can communicate with. We contacted the NuFW developers, Eric Leblond and Vincent Deffontaines about the project, and asked about the performance impact of NuFW. According to the developers, NuFW uses Netfilter's connection tracking features, and only authenticates the SYN packet of each TCP connection. This means NuFW has no impact on bandwidth, since it is removed from the equation once a connection is open. Leblond and Deffontaines said that NuFW's impact on performance is minimal:
We also worked on the concern of performance for the SYN packets, as this
is very important, too. Both daemons, nufw and nuauth, are multithreaded
for max performance. We incorporated from v0.9 on an internal ACL cache
into the authentication server, so it doesn't need to perform ACL checks
when they were just fetched.
There remains, of course, a measurable impact on the time it takes to open TCP connections. We performed a small, basic bench, to measure this. We built a very basic process that opens a TCP connection to a host, then closes it, in loop for 1000 times. Running that process behind a NuFW firewall took 34 seconds. Running that process behind a "conventional" Netfilter firewall (same hardware) took 20 seconds. So, we're pretty happy with NuFW's behaviour on DoS conditions, and quite confident about the performance matter. In addition to the nufw and nuauth daemons, each client system must be running the NuFW client -- Nutcpc for Linux, and NuWINc for Windows. Note that the Windows application is governed by a proprietary license, whereas NuFW is available under the GPL. Leblond and Deffontaines said that it should be easy to port the Linux client to Mac OS X and BSD OSes -- and it may run as-is. "What we mostly lack on this is testing. We are, of course, very open to contributions." When clients send packets through the firewall or gateway, the nufw daemon checks with the nuauth daemon to authenticate the user and verify whether a particular user has the appropriate permissions to send traffic through the firewall. NuFW distinguishes protocols as well, so users could be allowed (for example) to send HTTP traffic, but not SSH or POP3. Nuauth supports several authentication methods, including LDAP, system authentication with PAM, dbm or a plain text file with user credentials. NuFW uses an Access Control List (ACL) to determine which services users and groups can access. In the event that two groups have conflicting permissions -- for example, if a user belongs to a group that can access SSH and a group that cannot -- NuFW can be configured to either allow access or deny it. NuFW also offers detailed logging of activity, so that it's possible to track which users are sending traffic through the server and what traffic has been rejected or accepted. NuFW can log to syslog, or a MySQL or PostgreSQL database. There is also a Web interface which works with NuFW called Nuface, and a firewall log analysis application called Nulog, which provides a friendly interface for viewing NuFW's logs in detail. One limitation of NuFW is that it only filters TCP. The developers said that they want to implement UDP, ICMP and other protocols. There are a few other features that they're looking at for the long term as well:
We have to go into IPv6 support, too. We're looking for greater integration
into Netfilter with NFQUEUE (yay! it will/should be in 2.6.14!) and all the
current work of Netfilter's team on NETLINK, which will allow for even
finer filtering. We're in contact with the Netfilter team for this.
We also asked Leblond and Deffontaines if there was any chance of NuFW being ported to any of the BSD OSes. They said that they have looked at this, but that none of the BSD IP filter packages have a feature like Netfilter's QUEUE target, which is used by NuFW. "When/if there is one, we'll be happy to port the nufw daemon to BSD. Right now, the nuauth daemon should run on BSDs, as it is POSIX C."
While NuFW provides a rich set of features, it also adds quite a bit of complexity to the setup. In addition to installing and maintaining an additional set of packages, administrators will need to set up the appropriate groups and define permissions for those groups to determine which users can utilize which services. Admins will also need to install the NuFW client on all machines that need to authenticate with NuFW, and this means that (for the moment) NuFW is an option only for organizations that restrict their systems to Windows and Linux. It is possible to set up NuFW to ignore one or more subnets on your network, but this does defeat the purpose of using NuFW to some extent. As Leblond and Deffontaines point out, most of the complexity "comes not from internals, but rather from the fact that NuFW is a glue between systems that don't know about each other: the firewall in the center of the network, and the user directory in the center of organisation." They are working on a "appliance" solution with NuFW that will make it easier to deploy. It's also worth noting that NuFW is now available in Debian sid and the developers say that other distributions are looking at packaging NuFW as well. This could go a long way towards making NuFW much easier to deploy.
New vulnerabilities apt-cacher: remote command execution
epiphany: Mozilla regression vulnerability
ethereal: dissector vulnerabilities
libgadu: memory alignment bug
gopher: insecure tmpfile creation
gzip: arbitrary command execution
libtiff: insufficient validation
nbSMTP: format string vulnerability
NetworkManager: format string bug in nm_info_handler
PowerDNS: denial of service
ProFTPD: format string vulnerabilities
pstotext: remote execution of arbitrary code
Updated vulnerabilities a2ps: input validation error
affix: two remote vulnerabilities
httpd: off-by-one overflow and cross-site scripting
bzip2: race condition and infinite loop
ClamAntiVirus: integer overflows
cpio: directory traversal
CUPS: multiple vulnerabilities
cyrus-imapd: buffer overflows
dbus: information disclosure
dhcpcd: denial of service
ekg: multiple vulnerabilities
emacs21: format string vulnerability in "movemail"
enscript: arbitrary code execution
evolution: message crash vulnerability
fetchmail: buffer overflow
Foomatic: Arbitrary command execution in foomatic-rip
gdb: multiple vulnerabilities
gtk-pixbuf, gtk2: denial of service
gettext: Insecure temporary file handling
ghostscript: symlink vulnerabilities
glibc: tempfile vulnerability in catchsegv script
gnupg: information leak
grip: buffer overflow
groff: insecure temporary directory
heartbeat: insecure temporary files
htdig: cross site scripting
imap: buffer overflow in c-client
imlib2: buffer overflows
infozip: privilege escalation, directory-traversal
junkbuster: heap corruption and settings modification
kdelibs: kate backup file permission leak
kernel: ELF loader core dump vulnerability
kernel: multiple vulnerabilities
kernel: multiple vulnerabilities
krb5: double-free flaw
libconvert-uulib-perl: arbitrary code execution
libdbi-perl: insecure temporary file
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||