[LWN Logo]
[LWN.net]

Sections:
 Main page
 Security
 Kernel
 Distributions
 Development
 Commerce
 Linux in the news
 Announcements
 Back page
All in one big page

See also: last week's Back page page.

Linux links of the week


The CLUE Linux Centre is an actual bricks-and-mortar place, but it's worth an electronic look as well. Based in Toronto, their purpose is to become a permanent research and demonstration center for Linux - the first in the world, they claim. They have also undertaken the "Learnux" project - taking old castoff computers, installing Linux, and donating them to schools and students.

The Linux Bulletin Board is set up to host Linux-related discussions on a number of topics. The number of messages thus far is low...let's see of LWN readers can stir things up a bit for them...

Section Editor: Jon Corbet


September 16, 1999

   

 

Letters to the editor


Letters to the editor should be sent to letters@lwn.net. Preference will be given to letters which are short, to the point, and well written. If you want your email address "anti-spammed" in some way please be sure to let us know. We do not have a policy against anonymous letters, but we will be reluctant to include them.
 
   
To: letters@lwn.net, gnu@toad.com
Subject: Debian FSG vs. DNS Security license for BIND
Date: Thu, 09 Sep 1999 23:22:22 -0700
From: John Gilmore <gnu@toad.com>

As the person who negotiated the DNSSEC license that permits BIND to
use patented RSA technology, let me clarify the intent involved.
Debian is free to put in as much effort as it wants in eliminating
this 'DNSsafe' code, but I believe it won't exist in BIND after the
patent expires in October 2000 anyway.  I therefore suggest living
with it for a year as the easiest and most beneficial course.

The reason the BIND authors licensed the code, and the reason RSA
licensed them to use it, was for the mutually beneficial purpose of
jump-starting a public key infrastructure centered on the Domain Name
System.  Debian should not undermine this goal if it can see a way
to support it.

The DNSsafe code is copyrighted by RSA and requires custom licensing,
unlike the rest of BIND.  If the BIND authors continued to use the RSA
code in BIND even after the patent expired, it would make BIND
distribution and maintenance more cumbersome.  They are far more
likely to replace it with code that is unencumbered.

Debian contributors could perhaps best use their time by writing a
free, compatible, and extremely fast replacement for this code.  This
would provide ISC with a ready-made free alternative as soon as they
are released from having to license the patent.  Given the US Commerce
Department's erratic interpretation of the export regulations, I
recommend having a non-US contributor write it, even though the
regulations make it clear that authentication code is not covered by
US export controls.  (An earlier prototype of BIND that used RSAREF
for authentication was denied access to the authentication exemption;
this denial was administratively appealed by Hugh Daniel, the
applicant, and is awaiting a determination from the US Bureau of
Export Administration.)

As a firm believer in free software I don't want Debian to undermine
their stand for freedom.  The question at hand is what's the best
response when the unfree code is temporary.

	John
   
From: "David Jao" <djao@sc-24018.fas.harvard.edu>
Date: Thu, 9 Sep 1999 03:44:40 -0400 (EDT)
Subject: Caldera and GPL
To: hoserhead@bigfoot.com


> Caldera says "Ok, if you want to get your hands on this CD you've
> got to sign this piece of paper which says that you have decided to
> not exercise your rights under the GPL

Section 6 of the GPL (attached below) states very clearly that under
no circumstance may Caldera impose _any_ further restrictions on the
end-users rights under the GPL, even if the end user has signed a
document permitting Caldera to do so. The end user has no legal
authority to give up their end-user rights. Those rights are mandated
by the original licensor (i.e., the software author), and only the
original licensor of the software can give permission for Caldera to
restrict those rights.

>   6. Each time you redistribute the Program (or any work based on
> the Program), the recipient automatically receives a license from
> the original licensor to copy, distribute or modify the Program
> subject to these terms and conditions.  You may not impose any
> further restrictions on the recipients' exercise of the rights
> granted herein.  You are not responsible for enforcing compliance by
> third parties to this License.

The end user can certainly agree not to sue for their rights, but the
original licensor is under no such restrictions. No matter what the end
user has signed, the original licensor of the software could sue
Caldera, and would have a pretty strong legal case.

-David


   
Date: Thu, 09 Sep 1999 13:51:45 -0600
From: Bruce Ide <nride@us.ibm.com>
To: letters@lwn.net
Subject: Security and Kernel Modules

Please note that at the time the kernel module is installed, the
intruder already has root access to your system. I think a bigger issue
is the simplicity of obtaining root access once you've compromised a
user account. In my humble opinion, distribution maintainers are far too
free with those setuid bits. Packages requiring setuid access to the
system should undergo thorough and documented third party source code
auditing, as should the C library itself and any other components that
the setuid package relies upon directly. Closing the buffer overflow
hole would be a huge step in the right direction too, perhaps through
the implementation of something like the Linux-Privs project.

No one takes security seriously enough and I believe that a major
disaster is going to be the result of this lazyness. I'm not talking
about just Linux either. Will it take a bank losing several billion
dollars or some group shutting down a huge portion of the nation's
electrical grid before we start taking security seriously? Will we take
security seriously even if that happens? It's only a matter of time
before something like this happens, and I only hope there won't be a
huge loss of lives in the process.

As far as kernel modules go, perhaps some mechanism could be put in
place to allow cryptographic signing of the modules and the execution of
only signed modules. Of course, this would be pretty difficult to
implement given the US Government's asinine stance on crypto but I'm
sure our friends in free countries like Finnland or Russia could come up
with a set of patches that could be downloaded and applied to a kernel.

-- 
----------------
Bruce Ide
nride@us.ibm.com
   
To: "LWN letters" <letters@lwn.net>
Date: Thu, 09 Sep 1999 10:15:33 -0700
From: "   " <lkollar@my-Deja.com>
Cc: 
Subject: Kernel feature thrashing

> The natives on linux-kernel are starting to get
> restless. These patches are considered necessary
> by many just to get a working system. Why do they
> not find their way into the mainstream kernel?

That's a valid question, but IMHO another question that should be asked is
"are people upgrading because they have to, or because a new version is
out?"

One of the reasons people use Linux and other open-source software is to
step off that "upgrade treadmill." Why apply that commercial-software
thinking here? If the kernel you're using does the job you need, maybe you
should consider keeping it until you have a good reason to upgrade --
especially if you have to hand-patch in features you consider essential.

Old habits die hard, I guess.

I guess the anti-Linux camp will have a field day with this issue. I can
see the quotes now: "Linux is having growing pains" or "Linux is collapsing
under its success" or "Linux failures underscore need for commercial
support." Yuuuuuck-o. All this <b>really</b> means is that Linux users
should examine their needs and determine whether a new kernel release meets
those needs before upgrading. (If you want to be a guinea pig to help the
cause, that's a different story.)

After all, it's not like you won't be able to find working software just
because you don't have version 2.2.10 or greater. In fact, you could use
kernel 2.0.37 and not be left behind, except for a few specialized admin
tools. This <b>is</b> Linux we're talking about, not Windows.

	Larry "Dirt Road" Kollar


   
Date: Thu, 09 Sep 1999 10:13:04 +0200
From: Michael Thayer <michael.thayer@student.uni-tuebingen.de>
To: letters@lwn.net
Subject: New code in stable kernels

I can see that people are reluctant for major changes to be made in
stable kernels.  However the RAID and NFS problems might be solved by
creating a new stable line (something like 2.2b) when 2.2 has settled
down - a sort of "half major" release like Debian is planning.

Yours,

Michael Thayer
   
To: letters@lwn.net
Subject: User space utilities that depend on kernel version
Date: Thu, 09 Sep 1999 14:12:30 +0100
From: Andrew Stitcher <astitcher@orchestream.com>

It has seemed to me for as long as I have been using Linux (since 
0.99 and SLS days) that there is a problem in the way that utilities 
that are intimately bound up with the kernel are distributed.

There are quite a number of user space utilities that depend on a 
particular version of the Linux kernel to function and vice-versa for 
some things the kernel depends on the correct user space program - 
for instance update, insmod, ps, procinfo. mount and similar things.

As the kernel and these utilities can't really be separated it makes 
sense (to me at least) that they should all be distributed together 
and maintained in the same source tree, that is the kernel source 
tree.

If this were done the days of getting a kernel patch to fix NFS or 
RAID say and then needing to go search the web for the correct 
versions of the user space tools would be over.

What do other people think?

Andrew


   
Date: Sat, 11 Sep 1999 21:41:00 -0500 (CDT)
From: <surazal@is.toofarnorth.com>
To: letters@lwn.net
Subject: Thoughts on sort-of-open-source Star Office (long)


I've been brewing over this Star Office deal for a while and have come up
with some thoughts on the matter...

I've always had sort of an ambivalent attitude towards Sun the
corporation.  While they do produce some really good software (about an
order of magnitude better than MS's usual crud), and have played an
extremely important role in the Unix world, their political plays in the
free software world leaves me wondering.

Sun seems to want to have their cake and eat it too.  On the one hand Sun
played a key role in helping to legitimatize Linux in a number of ways.
They were one of the early players to join up with Linux International.
They sponsor an excellent service at http://www.sunfreeware.com by
providing packages for the GNU tools so that us poor saps who have to
administer Sun boxen don't have to recompile the tarballs all the time.
All this and many other "small favors" do add up in the long run.  But on
the other hand we got this SCSL thing: all the disadvantages of commercial
software combined with none of the advantages of free software.  Why?  Let
me elaborate a bit:

Back in the dawn of the century, there was a popular type of music called
Ragtime that was all the rage with younger folks (and was condemned as
Satan's music by some older folks :^).  If you actually took a close look
at Ragtime music, you noticed two immediately apparent things.  One, the
inherent structure of the music was hideously complex.  Two, all ragtime
tunes were hideously complex in a rather identical manner.  In other
words if you wanted to write a ragtime song, you had to follow some rules
that were set down in stone.  Ragtime did not entirely allow for a lot of
flexibility.

Needless to say, ragtime didn't last for very long.  For one, all the
songs sounded the same (go figure :^), and so it got a little old with the
listeners.  For another, song writers had mostly migrated to a new
type of music that was gaining ground: Jazz.  Jazz was nice in that you
could pretty do what you wanted to do.  Granted, there were some basic
rules you had to follow, but the flexibility of Jazz allowed it to survive
for nearly a century (and it's still going strong).  Similarly, Rock music
has the same sort of flexibility (more or less), and thus it too has
lasted decades longer than ragtime could ever hope to.

Which brings me back to the SCSL.  Now the SCSL is Sun's answer to free
software.  They say "We give you the source, but we control everything you
do, and you have to play by our rules."  Well, having rules is fine.  But
the restrictiveness of the license puts Sun's license in the same position
that Ragtime had when Jazz started to become really popular.  The GNU
license provides flexibility in that if, say, Red Hat ever decides for
whatever reason to drop GNOME, a group of developers can pick it up
and continue using it and working on it.  Not so with Star Office.  I am
at Sun's mercy, which is no better than being at MS's or AOL's mercy.
Heck I got into Linux because I was no longer shackled by what some
faceless corporation thought was best for me.

That's why I feel that Star Office, though it may end up being somewhat
successful, won't take the steam out of any free software office suite.
There's more flexibility and freedom over there.  :^)

Just like how I might be able to listen to a Ragtime song or two every
now and then, I'll pick one of the many flavors of Jazz that have come
down the pipe over the decades to listen to any day.

			- Dave Finton

 

 

 
Eklektix, Inc. Linux powered! Copyright © 1999 Eklektix, Inc., all rights reserved
Linux ® is a registered trademark of Linus Torvalds