The X.Org Foundation has announced
release of X11R6.7. This is, in some sense, a relatively minor release
with little in the way of new features (see the release
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
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)
With the recent release of the second Fedora Core 2 test, many users are
getting their first exposure to Security Enhanced
(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
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
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
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
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)
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
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)
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:
An additional concern regarding security is that all users will be
able to easily install programs. This is not a security flaw, and
is in fact a way to strengthen security. All users are already
capable of installing software, it is merely difficult.
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)
Linux Australia has published a lengthy position
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
to be signed, but the first priority for Australians is
probably to contact their members of Parliament. See the Linux Australia FTA page
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
Comments (5 posted)
Page editor: Jonathan Corbet
Next page: Security>>