See also: last week's Letters page.

Letters to the editor

From:	 Adrian Hosey <alh@warhound.org>
To:	 lwn@lwn.net
Subject: kernel modules and security
Date:	 Thu, 17 Jan 2002 08:56:39 -0500 (EST)


> Not everybody likes this idea. Many people build kernels with no loadable
> module support at all, and wish to continue doing so. Their reasons
> include:
>
>    * Security. Some people feel safer if there is not an easy way to
>      patch code into their running kernels. The fact of the matter,
>      though, is that the Bad Guys figured out how to modify a running
>      kernel some time ago, whether or not that kernel has loadable module
>      support."


This is specious reasoning. Security is about probabilities and
possibilities. By closing as many avenues as possible, I reduce the
probability of being a victim. There may be a very few Bad Guys out there
who know how to take advantage of a modular kernel, but there are even
fewer who know how to modify a running static kernel.

Let's estimate that 1 thief in 1000 carries a set of lockpicks. You still
lock the door to your home don't you? To keep out the other 999? Saying
that "A does not matter because some small number of people know how to do
B" just does not follow.


-- 
I am woefully underprepared to rock.

From:	 "Brad Spengler" <bspengle@bucknell.edu>
To:	 <lwn@lwn.net>
Subject: about module security
Date:	 Thu, 17 Jan 2002 21:21:22 -0500

>From the kernel section:
>"Security. Some people feel safer if there is not an easy way to patch
>code into their running kernels. The fact of the matter, though, is that
>the Bad Guys figured out how to modify a running kernel some time ago,
>whether or not that kernel has loadable module support."

You failed to mention that it's trivial to also stop the only other
method attackers are able to use to modify the kernel code without
module support.  It's a simple one-line patch that has been shown in the
newest edition of phrack and will be included in grsecurity 1.9.3 with
logging.  So, really, the security of module support isn't a "non-issue"
as you claim it to be.

-Brad
http://grsecurity.net

From:	 David.Kastrup@t-online.de (David Kastrup)
To:	 letters@lwn.net
Subject: A sidenote to the AOL/RedHat merger story
Date:	 20 Jan 2002 21:08:10 +0100


When this letter is published, matters will probably have long cleared
up.  Whichever way they do this, I would like to remind people of a
small thing that has been widely overlooked.

When RedHat was afloat with market capitalization, they acquired a
strategic asset before anybody else could.  Cygnus, a comparatively
small company in charge of the development of gcc, the GNU compiler
collection.  This compiler is crucial as infrastructure to most Free
Software projects.  Linux would not have happened without it.  The
quality of the generated code currently is good, mostly.  It usually
cannot hold water compared to the best commercial compilers with a
larger development crew and probably less portability, but it is good
enough to be workable for most projects on a wide range of platforms.
Competitiveness of free software hinges upon the quality of this
project, and its ability to cope with the idiosyncrasies of frequently
emerging new processor architectural details.

For this reason alone, the purported deal cannot be shrugged off in
the vein of "well, if RedHat goes down the drain, there will be dozens
of other distributions remaining".  The clout (or lack of it) behind
gcc development is crucial for Free Software.  So let's all hope for
the best.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de

From:	 Dylan Griffiths <Inoshiro@kuro5hin.org>
To:	 letters@lwn.net
Subject: Shortsightedness of some kernel developers.
Date:	 Thu, 17 Jan 2002 17:10:58 -0600

	Since no one seems to have pointed this out, much more than "Aunt Tilly" 
would benefit from an autoconfiguration system for Linux.  Ever deploy 
Linux on a 6 box homogeneous network?  You can share your kernel config. 
BUT, move to a company with a few hundred boxes, each one from a different 
generation of purchasing... and you find out, you really need that 
autoconfig.  That way you can script deployment in ways you currently can't.

	Added functionality like this doesn't make "the 31337" less so, it merely 
opens up more possibilities.  Precisely why I started using Linux 
specifically, and computers in general.
-- 
     www.kuro5hin.org -- technology and culture, from the trenches.
                          -=-=-=-=-=-
Those that give up liberty to obtain safety deserve neither.
  -- Benjamin Franklin
   http://www.zdnet.com/zdnn/stories/news/0,4586,2812463,00.html
   http://slashdot.org/article.pl?sid=01/09/16/1647231
                          -=-=-=-=-=-

From:	 Guy Harris <gharris@sonic.net>
To:	 Bryan Henderson <bryanh@giraffe-data.com>
Subject: Re: buffer overruns - helpful tool
Date:	 Thu, 17 Jan 2002 23:44:35 -0800
Cc:	 letters@lwn.net

> asprintf() is a surprisingly little-used GNU C library routine.  It's 
> special to the GNU library, so you can use it only in Linux-only code.

No, and no.

% uname -sr
FreeBSD 3.4-RELEASE
% man asprintf

PRINTF(3)              FreeBSD Library Functions Manual              PRINTF(3)

NAME
     printf, fprintf, sprintf, snprintf, asprintf, vprintf, vfprintf,
     vsprintf, vsnprintf, vasprintf - formatted output conversion

SYNOPSIS
     #include <stdio.h>

	...

     int
     asprintf(char **ret, const char *format, ...)

	...

DESCRIPTION
     The printf() family of functions produces output according to a format as
     described below.  Printf() and vprintf() write output to stdout, the
     standard output stream; fprintf() and vfprintf() write output to the giv-
     en output stream; sprintf(), snprintf(), vsprintf(), and vsnprintf()
     write to the character string str; and asprintf() and vasprintf() dynami-
     cally allocate a new string with malloc(3).

		...

     Asprintf() and vasprintf() return a pointer to a buffer sufficiently
     large to hold the string in the ret argument; This pointer should be
     passed to free(3) to release the allocated storage when it is no longer
     needed.  If sufficient space cannot be allocated, asprintf() and
     vasprintf() will return -1 and set ret to be a NULL pointer.

		...

NetBSD and OpenBSD have it as well.

So perhaps it should be rephrased as

	asprintf() is a surprisingly little-used GNU C library and BSD C
	library routine.  It's special to the GNU library and the
	{Free,Net,Open}BSD C libraries, so you can use it only in code
	that only runs on free UNIXes, unless you use your own copy of
	asprintf on UNIXes lacking it, or, on those platforms, use GNU
	libiberty:

		http://gcc.gnu.org/onlinedocs/libiberty/

	which includes asprintf().