Re: Security of Debian SuX0r?
Juhapekka Tolvanen <juhtolv@st.jyu.fi> wrote:
> Have you guys and girls seen this? What do you think about it?
>
> http://www.securityportal.com/closet/
I demur from the generally benign flavor of the reactions I've seen so far. I
think this was a hatchet job by a guy who appears completely disingenuous when
he claims he would have liked to have written a glowing review of Debian.
Here's my reply to him, which was a kneejerk reaction and could have been
longer and more thorough:
Date: Wed, 30 Aug 2000 12:51:12 -0400 (EDT)
To: dep@snet.net
Cc: seifried@securityportal.com
From: Bob Bernstein <poobah@ruptured-duck.com>
Subject: point by point rebuttal
I will back up my claim that the review was biased herewith:
A casual read suggests that other distros do things much better. Wrong. Kurt
seems to think that any distro that doesn't follow *his* notion of a secure
system is flawed, i.e. contains 'bugs'.
Thus his first "Debian" criticism is something *every* distro does:
The first thing I noticed was
that while formatting the disk,
Debian defaults to an enormous /
partition and a swap partition.
I know of no Linux distro that does otherwise. And he is wise enough to
acknowledge that here. But that is the last we see of this wisdom. (NetBSD and
FreeBSD offer default disklabels that are better. OpenBSD does not bother to
offer any default at all; you're on your own.) So, next:
The next default that really
ticks me off is the password
encryption scheme - the default
is to use crypt. You can also use
MD5, but there is a warning about
compatibility.
So there's a warning? At least MD5 *can* be implemented at install-time. Why
doesn't he mention that Caldera for one doesn't even offer MD5 as an _option_
at install-time? Next:
Moving on. Once the basic install
is done, you will discover that
several services are enabled in
inetd that shouldn't be. Discard,
daytime, time, shell, login, and
exec (r services) are all enabled
by default, few of which (none,
in my opinion) are needed on
modern systems.
As you once pointed out in a linuxplanet article, this is a fault of ALL Linux
distros, in fact of ALL distros I know of other than OpenBSD! Next:
dpkg - My main beef with dpkg is
the lack of package signing
support.
The guy is simply a raving rpm zealot here. To trade off the superb utility of
the Debian package system for PGP sigs is stupid. And no, MD5 sigs are not
that much more of a risk here because due to the excellence of the Debian
package collection one is rarely IF EVER called on to use a non-official
package. This is very much in contrast to the chaos that reigns in the rpm
world. Next:
Home directories for users in
Debian are by default world
readable and executable (to
change into a directory, you need
executable permission). This is a
very bad idea. It is made even
worse by the fact that the
default umask is 022.
These are world-wide Unix standard values. And they are install DEFAULTS. If
you are going to administer a system with public access and/or large numbers
of users then you have to make some decisions and let your users know what the
reality is. It foolish to assume on any Unix system that the files in your
home dir cannot be read by others logged on to the system. And it is simple to
create a confidential subdir or - if you're not using Apache's 'public_html'
default - to change the permissions on your home dirs (as he notes). He is
creating a tempest in a tea pot here. Next:
LILO is also configured very
poorly. Despite the fact that
Debian 2.2 specifies "sulogin"
for single user mode, prompting a
user for the root password is
easily bypassed, by entering the
following argument at the LILO
command line:
Linux init=/bin/sh
I don't know how other distros do this. Kurt's discussion of these matters in
his LASG is the best I know of. And, I believe this has come up on the
debian-devel list. So I will give him a point here _tentatively_, until I hear
the other side. But, as usual, and as noted, the fix is simple. How does COL
do it? (I would add that anyone in the world can create a boot floppy or CD
that will obtain the same results! I am a big supporter of boot security, as
my security piece indicates, but at a certain point you have say that given
physical access to the machine, all bets are off.)
The rest of the article seems to be limited to a critique of the package
versions that are distributed with this release. I don't know how to answer
that. At a certain point one must freeze a release in order to make it
actually a release! The implication here is that it is possible on God's good
earth to make a release wherein none of its member packages contain any
security flaws at all! How silly. As for the fact that Debian hasn't applied
known, available fixes to certain packages in the release, he may be right
there. That's the second and last point I will _tentatively_ give him. Now he
says:
Debian's goal of a bug
free-release hasn't been met.
I haven't seen one "bug" mentioned in this article. A bug by my estimation is
a mistake, or a feature that performs in a mistaken fashion. All his quibbles
are with 'features'. No bugs. Bah.
So Kurt, why the hatchet job?
--
Bob Bernstein http://www.ruptured-duck.com
Reply to: