Leading items

The first X.Org release

The X.Org Foundation has announced the release of X11R6.7. This is, in some sense, a relatively minor release with little in the way of new features (see the release notes for the details). It is, however, a milestone in the development of the X Window System, and worthy of note.

Readers of LWN will be familiar with the tensions which have stressed the XFree86 project over the last year. There have long been disagreements over how the development of X should be managed, and core developers have been leaving the project for some time. The issue came to a head with the the adoption of the XFree86 1.1 license, which is widely seen as being incompatible with the GPL. That move led to the formation of the X.org Foundation under the umbrella of FreeDesktop.org. It also led to many distributors saying that they would not incorporate the XFree86 4.4 release.

The X11R6.7 release is the first official release from X.Org, though some distributions (e.g. Fedora Core 2 Test 2) have incorporated pre-release versions from the Foundation. It is intended to be a transitional release, a way for distributors to move over to the new code base. As such, it deliberately does not include much in the way of radical new changes. There will be a couple more X11R6.x releases this year which will add more new stuff.

The real plan for the future, however, is to split the X release into a number of components, including the server, client libraries, and applications. This split will allow each part of the system to progress at its own pace; it will be possible to release support for the latest graphics hardware without dragging along all of the applications as well. The X hackers have all kinds of schemes for reworking the server and the X protocol to better support modern 3D hardware to to get Linux, finally, out of its old, two-dimensional world.

Conventional wisdom says that forks in free software projects are a bad thing. But one of the valuable aspects of free software is that it can be forked. The X fork looks like a necessary one; with luck it will lead to a reinvigorated development process and good things for the future Linux desktop.

Comments (2 posted)

First SELinux impressions

With the recent release of the second Fedora Core 2 test, many users are getting their first exposure to Security Enhanced Linux (SELinux). We decided to take a look at SELinux in Fedora Core to give readers a taste of what's to come.

SELinux introduces new layers of security, enforced by the kernel, in addition to the standard Discretionary Access Control (DAC) model that Linux users are already familiar with. The DAC model applies security based only on a user's identity and the permissions associated with files and processes. SELinux adds Mandatory Access Control (MAC) over processes and files based on a policy set by the administrator, rather than based solely on user or process identity.

SELinux also provides Type Enforcement (TE) for files and devices, otherwise known as "objects," and Role-Based Access Control for users and processes. TE in conjunction with Role-Based Access Control (RBAC) provides the ability to set policies based on the type of object, rather than its DAC permissions. The practical upshot of this is that a user or process must not only have the appropriate DAC permissions to access an object, but also must meet the RBAC requirements to access an object.

It's important to note that SELinux does not do away with the standard DAC model. For example, if a normal user attempts to execute a file owned by root with the mode 500, they will be denied the ability to do so without SELinux features coming into play. However, SELinux goes beyond that level of control. For example, an administrator can set policy that prevents a user from granting access to files to other users even if that user owns the file.

To paraphrase Spider Man's tagline, with great power comes great complexity. Getting up to speed with SELinux tools and policy will take some time. While SELinux gives an administrator a greatly enhanced security toolbox, it also complicates the job of administrating a system. The integration of SELinux adds a number of new programs and configuration files for the administrator to familiarize themselves with, as well as adding new options to familiar programs like ps and ls. It is safe to say that the syntax for SELinux's policy configuration files is less than user-friendly.

Administrators who plan to tweak the SELinux policy settings should plan to set aside a fair amount of time to learn the syntax and procedure for updating policy. To edit a system's policy requires the administrator to edit one or more of dozens of configuration files under /etc/security/selinux/src/policy, then compile and load the new policy using make.

Users should also be aware that the additional security checks involved with SELinux may come at the price of a performance impact. The Fedora SELinux FAQ notes that SELinux decreased performance by 7% for "completely untuned code" when SELinux was last tested and may have become worse due to changes made since then. Of course, a 7% drop in system performance is generally considered preferable to a 100% compromised system.

Administrators considering SELinux should note that it may limit their choice of filesystems, at least with Fedora's implementation. The popular ReiserFS in Fedora does not support file labeling, making it unsuitable for use with SELinux. This writer also found that the ability to turn enforcement on and off, using "setenforce" is quite invaluable during SELinux testing. It is possible to disable logins to a system simply by setting /etc/passwd's security context incorrectly. For those who don't want to jump into SELinux with both feet, setting the enforcement policy to "permissive" will cause the system to print warnings whenever access to an object would have been denied, but to not restrict any access beyond what the traditional discretionary controls dictate.

For the most part, the end-user experience is, with luck, largely unchanged. Though some users have reported problems with various end-user applications not working with SELinux enabled, this writer did not encounter any problems using FC2 on the desktop or at the shell for normal work.

Despite its complexity, SELinux shows a great deal of promise for improving the overall security of Linux systems. It seems likely that the tools for creating and customizing SELinux will improve over time and make the task less difficult. Even at the current level of complexity, it would be well worth an administrator's time to learn and deploy SELinux for systems that are directly connected to the Internet or other hostile environments.

Comments (11 posted)

Motion in Red Hat v. SCO

After a lengthy period of inactivity, there has finally been a bit of movement in Red Hat's lawsuit against SCO. The news is mixed.

SCO's motion to dismiss the case was denied; Judge Robinson reached the reasonable conclusion that Red Hat did, indeed, have reason to fear a lawsuit from the SCO Group. So the case will go forward; SCO will not be able to shake it quite so quickly.

This case will not go forward anytime soon, however. Instead, it has been put on hold until the IBM case is worked out. Both sides have to file every 90 days giving their view of the state of the IBM case. If that case looks like it is not going anywhere, the court may restart the Red Hat case.

For now, however, the Red Hat suit is suspended. Given the speed at which things have moved in this case to date, it may be hard to tell the difference. This ruling does, however, free SCO from the need to fight on this front for now; SCO can concentrate its resources on the IBM, Novell, DaimlerChrysler, and AutoZone suits. Plus any others that SCO might, in its wisdom, decide to file. That should be enough to keep the lawyers busy for a while. (See Groklaw for more information).

Comments (3 posted)

The User-Accessible Filesystem Hierarchy Standard

The User-Accessible Filesystem Hierarchy Standard is a proposed standard which has recently been put forward for wider review. The problem this standard attempts to address is: how do users of desktop Linux systems install software for their personal use without using the root password or hosing the system? The problem is real enough; as Linux shows up on more desktops, and more interesting applications become available, people will want to be able to do their own installations. Anything which can make those installations easier and safer should encourage desktop Linux adoption. It is not clear that this proposal will do the trick, however.

The UAFHS states that every user should have a directory (.system) in their home directory for the installation of personal software. This directory would have the usual subdirectories: .system/bin, .system/lib, etc. The placement of software there would contain it within one subtree and make it easy to find. The standard also suggests the creation of a .config directory under the home directory and moving all application configuration files there.

The next problem is that users of a shared system may want to install software for others to use as well. To that end, the standard says that /home/shared/.system should be available and writable for all users. The authors seem to have anticipated one of the possible complaints with this setup:

The argument here seems to be that, since the root password will not be required for software installation, the system will be more secure. The simple fact, however, is that making it easy for unprivileged users to install programs into the path of other users is not the best way to secure a system. This sort of mechanism could easily become a favored way of escalating access to a user account into a full root compromise.

This standard also fails to address the real issue. Unprivileged users who want to install software are not much concerned about where it is going to go. They will be far more interested in easy management of installed software. Mixing packages together into one big directory tree does little to help somebody who wants to get rid of things in response to the inevitable "no space left on device" or "quota exceeded" message. This standard says "put software over there," but does not concern itself with how users will actually manage that software.

Making software installation easier is a worthy goal. Part of achieving that goal can even be the designation of a target directory for installations. But anybody who wants to concern themselves with making this aspect of desktop Linux easier really needs to be dealing with the package management issue. Creating a version of rpm or dpkg which can do per-user package management could be harder than writing up a proposed standard, but it would do far more to address the issue at hand.

Comments (22 posted)

Legislative fun worldwide

Linux Australia has published a lengthy position paper on the free software implications of the recently negotiated "free trade agreement" (FTA) with the United States. This agreement uses the trade treaty approach to bring American-style anti-circumvention and software patents to Australia. Linux Australia is now working to prevent the adoption of the FTA, and is looking for help. Among other things, there is an online petition to be signed, but the first priority for Australians is probably to contact their members of Parliament. See the Linux Australia FTA page for more information.

Meanwhile, on the European front: there will be a two-day gathering at the European Parliament in Brussels starting April 14 in an attempt to, once again, stop the threat of software patents in Europe; see this press release and the demonstration home page for details. The European Parliament voted against patents on software, but the European Commission and Council of Ministers have the last word - and they are considering a very different course of action. If Europe is going to avoid the imposition of U.S.-style software patents, Europeans will have to make their voices heard.

In the U.S., the House of Representatives is busily addressing our pressing national problems by considering the Piracy Deterrence and Education Act (PDEA - available in PDF format). This act calls for the FBI to "facilitate the sharing among law enforcement agencies, Internet service providers, and copyright owners" of information related to file sharing. The Attorney General's office is to set up an "education program" on "the value of copyrighted works and the effects of the theft of such works on those who create them," along with the security risks of file sharing. Most fun of all, however, is the provision for three-year jail sentences for anybody convicted of sharing a single file valued (by the copyright owner) at over $1000. The PDEA has passed the House Judiciary Intellectual Property Subcommittee; no word on when it may be voted on by the entire House.

Comments (5 posted)

Page editor: Jonathan Corbet
Next page: Security>>