Re: SecurityPortal Review of Potato
I'm sending this response just to you (if I remember to edit the
headers ...); also, please note that I am on a very, very slow telnet
connection, so I do hnot have the type to correct the typos (plus the
keyboard is in Spanish, but the setting is in North American data).
Pleas enote that I'm sorry and put on your accurate error correcting
ability.
From: Anthony Towns <aj@azure.humbug.org.au>
Subject: SecurityPortal Review of Potato
Date: Wed, 30 Aug 2000 19:22:07 +1000
Message-ID: <[🔎] 20000830192207.A8859@azure.humbug.org.au>
aj> From http://www.securityportal.com/closet/closet20000830.html
aj>
aj> ] Moving on. Once the basic install is done, you will discover that
aj> ] several services are enabled in inetd that shouldn't be. Discard,
aj> ] daytime, time, shell, login, and exec (r services) are all enabled by
aj> ] default, few of which (none, in my opinion) are needed on modern
aj> ] systems.
aj>
aj> The former three services aren't security problems in Debian (daytime/udp,
aj> time/udp, and echo/udp would be, but they are specifically *not* enabled).
aj>
aj> I find myself shocked and horrified (well, surprised, anyway) that he's
aj> actually right about the latter services being enabled. It appears that
aj> rsh-server is depended upon by rstartd (the preferred alternative to ssh,
aj> according to the dependencies, and hence apt), and rstartd is in the
aj> x-window-system task.
aj>
aj> I think we need to fix this in r1 (with a new task-x-window-system
aj> package), and IMO an advisory wouldn't be out of place either. It could've
aj> been avoided in the first place if we'd fixed all the "optional package
aj> depends on extra package" bugs, but we didn't. [0]
aj>
aj>
aj> The lack of fixes (or, more accurately advisories) for both Netscape
aj> and Xchat are also pointed out.
aj>
aj>
aj> I'm not really sure what the author wants with regard to partitioning.
aj> Without quotas, or separate partitions for each user, it seems to me
aj> that most parititioning schemes "[don't] help other users much" either.
aj> There might be something worth looking into here, at least.
When I was installing BSD (FreeBSD I admit, but I'd rather try OpenBSD
then NetBSD today if I had a choice, but that'\s based on surmise, not
experience speecifically ...) it makes / have about 80M (on a 1G
system), /with /usr and something else like /var on their own
partitions. It follows closely the concepts allowed by the FSSTND's
successor (and the FSSTND itself); I forget the -- ah yes,, the "FHS
2.0" (it may be even more upt o date now) -- Filesystem something
Stadard.
I believe this is what he is referring to, and by the way I agree at
least as of three years ago when I did it to my system.
aj>
aj>
aj> The remainder of the cited problems are largely either "its a feature
aj> not a bug" issues or just plain wrong, afaict: users' files defaulting
aj> to being public rather than private is certainly how I prefer things,
aj> and MD5 versus crypt passwords; and the author completely neglects to
aj> note that the versions of Apache and ProFTPd distributed by Debian have
aj> the holes he mentions already fixed.
I would prefer someone to put together a BSD-grabbing group -- that
is, one person look at the code for an idea, pass the idea on to the
other person in such a way that it covers no copyrights (patents be
deamned, esp. since BSD doesn't poatent itself), and then let the
other person code it without the loss of having looked at how BSD
coded it.
A third efficiency person can then analyze the result, and pass the
ideas of those analisys to the first person who can re-ideaize them
and opass them on tto the second person again. Or the first person
could do that himself, but it gets kind of hectic if the first person
does all of the back-and-forth -- <I hitnk clear seperation of duties
is good here. "Person" is replacable by "group", but you shouldn't
just copy BSD code of course ...
Then you can go through the ("you " I mean the 1first person) can go
through the code changes files (all those version change difference
things -- a lot of diff work to play with) on all of the BSD systems,
and see what they're actually been doing; some of the BSD projects
have some very good bug stoppng and security enhancements. This is
good even and especially for a distribution; it's not just kernel
stuff.
The opinion of "very good" BSD stuff is that of others, but so many
people have said it that I tend to believe it.
For instance, OpenBSD brags about a much better password system than
used on most Linux distributions and even other BSD ones; I would like
not to think that if my friend or I or the company's system I'm using
happened to use Debian, they would have a less secure password system
by default. POne day my system WAS misconfigured despite my BEST
DILIGENCE, and someone downloaded my /etc/shadow file. I KID NOT.
This is a very important issue to me; I was already many hours (days)
into compiling longer passwords, etc; I never did fix that, and that
was since 1995. At least Debian gives the option, but I do believe in
non-crypt passwords myself )(I'm somewhat curious what your likek for
default crypt is; why would anyone ever want crypt, much less
defayult? You have your reasons, so I would not flame you (yet)).
aj>
aj>
aj> It'd probably be a good idea to send a response correcting some of the
aj> errors; it'd probably be a better idea to make sure the rest are errors
aj> by r1 though.
Ok, this is eomthing I want to point out. I it is very important for
the administrator of a system to know in which packeges "version
TOTALLY SUSCEPTABLE of PROGRAM XYZ" is actually fixed. The
administrator is really hurt when Debbian has secretly fixed a whole
lot of security bugs in VERSION SUSEPTABLE (a natural response, I
might add), but then DOES NOT DOCUMENT IT: the administrator then
goes and gets VERSION UNSUSEPTABLE for BUG #1,3,4,7,8,9 but then ends
up with a MORE suseptable version because Debian already fixed also
bugs 2,5,10,11,12,13. Sure maybe Debian didn't fix #14 and version
unsuseptable did (along with bug #15, 17, 18), but it just goes to
show how lost an administrator is if the install scripts, the programs
themselve s(in their "about" boxes in the analagous to Windows
progrfams, or for the non-GUI stuff (yay thank earth I get so sick of
GUI sometimes with those dirty rodents all over the place) the versioh
lines -- even when it's only found with "emacs executable| or if
you're lkucky "strings executable | egrep -i v[\.,blarglededup] |
less" ...
That is, if it is Netscape v4.73, then it should say "Netscape v4.73
unmodified" or "Netsape v4.73 with modifications as described in
/spot/where/file/really/actually/as/a/matter/of/fact/in/this/case/is.html"
, with the same file available during install script and with as much
notification. (However dpkg works. I've wanted to expierence dpkg,
but have not really hjad much chance; the few times I've tried, I
would freak out about no signatures and dump it.)
Ok, about signatures: I feel like saying "I'm sorry" since I've
brought it up myself: I'm sorry, but the signature point he made is
very iomportant. He goes on for many paragraphcs; this sort of
reveals that he knows that Debian some how is retarded on this issue
and has already put it on the "we'won't -do-this-list" in some
strange, odd way, although I'm not sure that's set in stone.
aj>
aj> Cheers,
aj> aj
aj>
aj> [0] From http://bugs.debian.org/~wakkerma/unmet.html
aj>
aj> rstart Depends optional rsh-client extra
aj> rstart Depends optional rsh-client extra
aj> rstartd Depends optional rsh-server extra
aj> rstartd Depends optional rsh-server extra
aj>
aj> There are lots of similar problems with other task packages.
I take your word for it, since I do not know myself. ("What? You're
just throwing peanuts?" Well, they're nutricious so ....)
This sounds like a good thing to fix.
But, I'd like to point out that OpenSSH is now out, and the xport
restrictions for the US are gone if you file th right papers or
something like that. I think it is still not a bad idea to be
paranoid about the papers vs. no papers thing, but since I'm fuzzy on
how easy it is for a Debian admin to install OpenSSH by default on his
installs with very few little changes, I'm just flaming the fire.
WHat it needs to be is that getting OIpenSSH on the Debian system is
easy, somehow, someway, whatever that way is (in a secure fasion, that
is).
aj>
aj> --
aj> Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
aj> I don't speak for anyone save myself. GPG signed mail preferred.
aj>
aj> ``We reject: kings, presidents, and voting.
aj> We believe in: rough consensus and working code.''
aj> -- Dave Clark
Thank you for your list posting. It was productive, and I agree that
someone needs to correct the guy who wrote the article; his other
points are things that I hope are well-taken as well. And thank you
for working on Debian. i do not have to time myself. And I
appologize again for not having time to get things right -- eventhings
like "you" when I should have said "somebody".
I can't even sign this, since I don't have enough quota for FISH
(OpenVMS compatible version of SSH) ...
-u
<Ulmo@Q.Net>
Bradley Allen
Reply to: