Debian 2.2 "Has Major Security Issues"? UPDATED 248
If you would have bothered to check the changelogs for the packages you noted as having "root hacks in them", you would have noticed that every daemon you pointed out is not vulnerbale to the holes you point out. Here is a list:
apache (1.3.9-13) frozen unstable; urgency=medium
* [RC, security] Backported security fix for Cross Site Scripting issue
(CERT Advisory CA-2000-02) from apache 1.3.11 patch.
* Added default charset iso-8859-1 to initial configs.
* [RC, critical] Perl dependency reordered to "perl5 | perl", closes:
#61421, #62427, #60575.
* Postinst no longer complains on missing /etc/aliases, closes: #60575.
* Cron script detects logfile lines with whitespace, closes: #59995.
* Fixed apxs filename edited when enabling modules (missing /g in rules
sed); suppressed linking to -ldbm, closes: #53172.
* The apxs in apache-dev no longer needs apache binary, closes: #47221.
* Perms registered for suexec changed to 4755 from 4555, closes: #60147.
* Added text from beleagured Debian Webmasters to intro.html, making it
clear the project is not responsible for installations, closes:
#61414.
* LICENSE file of manual included since 1.3.9-1, closes: #42940, #60994,
#60995.
-- Johnie Ingram Sun, 16 Apr 2000 08:29:56 -0500
* Use setproctitle(%s,foo) in main.c, lamagra@DIGIBEL.ORG advisory.
-- Johnie Ingram Wed, 5 Jul 2000 18:50:07 -0500 As for netscape 4.75, it is *already* available in our potato-proposed-updates directory. Now I suggest you change the utter bullshit you have on your review to reflect the real information, and next time do some more digging before you make false accusations and spread misinformation like this.
From Kurt
Well, it looks like I made some significant mistakes in this article. I'm not a long time Debian user, so I am somewhat unfamiliar with it. It appears Debian backports fixes, and that Apache 1.3.9 and ProFTPD 1.2.10pre10 are not subject to the various vulnerabilities I mentioned. Unfortunately I did not read all the changelogs in question (in /usr/share/doc/*/). If I had, I would have noticed this.
Folks, I assumed (assuming is bad, I know) that Debian does updates like most distro's. I expected that if Apache 1.3.12 comes out with bugfixes, that they would issue a 1.3.12 package, not backport the changes to 1.3.9. I've also been writing a weekly Linux security digest for several months now, and while there have been Debian advisories regarding Potato, most of them mention the changes being merged in, rather than warranting a new release. I should have noticed that.
While RBL's failure isn't Debian's fault, my point is that they go to great lengths in some areas to make the distro "more secure", but are missing other very key elements.
I officially apologize to the Debian community, and am glad to have been made aware of an important point: Debian backports fixes, and it is necessary to read all the changelog files in question.
-- Kurt
CNN (Score:1)
Untrue (Score:1)
OpenBSD [openbsd.org] - Three years without a remote hole in the default install.
Security patches were applied on many packages (Score:5)
Ex: Apache:
http://cgi.debian.org/cg i-bin/get-changelog?package=apache [debian.org]
IOTW - the security may not be perfect still, but let's not get carried away just because we're too damn lazy to read.
Re:Home directory permissions (Score:2)
MS vs Open Source (Score:4)
Secure by default (Score:2)
r services disabled by default? (Score:3)
Dunno whether the author of the article missed it, or whether the postinst was changed again, but I'm pretty convinced that this point is invalid.
--
this post was brought to you by Andreas Fuchs.
Sorry.. (Score:5)
- Single partition / for whole system as a *default*.
Well.. first, you *DO* have the option of changing this when you install. It's not an 'automatic' thing insomuch as windows does this automatically. And from what I know, most home users do this anyway Servers no, Home use, yes.
Crypt passwords (instead of md5) by default. HELLO.. the screen ASKS you what you want to use, and just happens to have 'crypt' already selected. And they *are* right.
Now.. basic inetd services (time, echo, discard). Yes, those of us security minded tend to shut these off.. however... I think it's common knowledge that the *FIRST* thing you do with a new distro is go in and disble these. I have yet to use a distro that doesn't put these in. And I'm unaware of any current (or past) security holes in the basic inetd services. These services are *internal* to inetd. If you are *really* worried about inetd's security, why not STOP RUNNING IT ALTOGETHER?
As for 'login' and such... see above. Commenting out inetd is standard pratcice. EVERYBODY knows that.
'gnuplot' is mentioned for some reason.. even though they install it correctly (as the article says).
And EXIM using RBL? What has that to do with security (whether or not RBL is currently working?).
Okay. Calling DPKG a security problem because it doesn't allow package signing? I'll grant that's kind of valid.. but how many signed packages are their in any other linux distribution? I don't believe I've ever seen even a single one! (in other words.. who cares if RPM can do this if nobody uses it). Oh wait.. you could always just INSTALL RPM!
The users home directory thing.. that's something to always check on every distro, because it's always different wherever you go. As the admin, if you don't like it, change it. Also.. the permissions suggested on users home directories lulls them into a sense of security
lilo doesn't use sulogin? C'mon.. if you are local, you can break in *anyway*. Lots of distros don't use sulogin, and nobody has a problem.
I have to catch a plane, so I can't get the rest of the article (There look to actually be acouple of valid thigns that could use patching mentioned).
But that whole first section of the article is just whining about settings not being exactly the way the author would have liked them,.
LILO password (Score:5)
backported bugfixes. (Score:5)
--
Re:Untrue (Score:1)
Not that Debian couldn't be secured with a little extra work, but I prefer to be a _little_ lazy with my installs.
______________
Re:Home directory permissions (Score:1)
Furthermore, access is managed on a per-file bases. Access control on a per directory bases is easyer to handle and suffices in 90% of the cases. Persmission bits are not centraly managed, wich makes things harder. Acces control lists are easyer to manage and are more natural.
If I want the http deamon access rights to part of my directory, but do not want other programs reading that I have to juggle with groups and permissions. I have to check every file in that directory for the rights permissions group id's. For all my accounts I use a script with a dozen chmod's and chgrp's to set permissions for my directories and files right.
<b>Screw permissionbits, I want ACL's (something like netware)!!!</b>
Re:Untrue (Score:1)
Try installing it yourself - you'll save hours over trying to tie down any linux distro. Same for solaris too
Due to long release cycles (Score:4)
Ivo
Re:Home directory permissions (Score:1)
Sure, permissions is not the ultimate secure solution, but it's a whole lot safer than letting everyone read users home directories.
I don't know if I would call this major. (Score:5)
The default crypt passwds, I admit, was kind of dumb, but it takes one command usually to change. Not a big deal. I don't get his beaf with dpkg not handling signing automagically; nothing stops you from signing it with gpg anyway and checking the sig by hand, or even writing the script to do it. Make dpkg do one little thing, and do it well; it might not need the kitchen sink welded on too.
I agree with him on two points, however: the improper lilo configuration, and the version of netscape that ships with 2.2. The default lilo lets you boot into single user root mode without a password, and the shipping netscape still suffers from the huge java hole. These are two very important pieces of software to most users, and might very well cause a lot of boxen to be compromised, so make sure you fix it.
Personaly, I think this attention will only make debian better for everyone. All in all, make sure you know what you are getting into when you install any distro. And subscribe to bugtraq.
Worth repeating (Score:2)
I felt like repeating that bit. 'cos not many people do, and then they blame their tools when things go wrong.
And that applies to all systems of course though, not just Debian and not just Linux.
Re:MS vs Open Source (Score:1)
Re:Sorry.. (Score:4)
Not necessarily a valid argument, as you can read in an old Freshmeat editorial [freshmeat.net], where representative of both Debian and RedHat made really interesting points on the subject.
Re:MS vs Open Source (Score:1)
a) editors at Slashdot are extremely biased and by no means objective whatsoever and
b) this time they were sort of right, because the article does not talk too much about real security issues but instead blabbers about Debian's Exim using RBL not completely right or something.
Granted, if Debian does all the things Kurt proposes, Debian will get a lot better, but not neccessarily a (more) secure distro.
Ivo
Re:LILO password (Score:2)
There was a (no, more than one, actually) flamewar on debian-devel on this issue. One about the autofs daemon, and one about the MBR that is set up on initial install.
They all started with your argument, and they ended with the participants throwing nothing but profanities at each other. So, before you reply to this post saying something along the lines of "But lilo should be secure, too!", please, please check out the Debian List archives [debian.org] to see whether your point has already been made!
Thank you for avoiding trouble. (-:
--
this post was brought to you by Andreas Fuchs.
Kurt did a hack job (Score:5)
Let's see, defaulting to crypt is necessary for compatibility with NIS+. Note that Kurt's vaunted Red Hat gives you the choice of crypt as well....
r* services simply aren't enabled in Debian by default. I don't know what Kurt was smoking, but they're not. Time, discard, etc., are, but if you can't trust them, you can't trust inetd period (which isn't to say I don't comment 'em out anyway
RBL not working is a security hole? C'mon Kurt, if you don't like Debian, just say so. FUD gets you nowhere (though it does promote sales of your Red Hat-oriented books, I realize).
dpkg not doing GPG sigs is a problem. The new version does support it, and that'll be in the next release. In the mean time, there is MD5 sum checking....
Just because a distribution uses a different default permission set for home files than Red Hat doesn't make it insecure. It just makes it different than Red Hat.
I actually like the "prompt for password for LILO" suggestion. It's something no Linux distribution (including Kurt's vaunted Red Hat) does currently, but it's actually not a bad idea. Give the man one point.
Daemons: this point *could* have actually been valid, but if Kurt had bothered to do any research at all like a real journalist should, he would have discovered that Debian does not ship Apache 1.3.9. They ship 1.3.9 + backported security patches. Ditto for ProFTPD. The security hole he's claiming exists is a figment of his overactive imagination.
Similarly, contrary to his claims, Debian has released updates which upgrade to Netscape 4.75. Y'know, that's what apt-get upgrade is for.
Are all of Kurt's articles completely FUD like this one? I've never read him before, or even heard of him, but from what I've seen here, he seems rather clueless.... And I say that as someone who admins Red Hat for a living, not Debian.
Netscape too? (Score:1)
Perhaps it's not so funny as it's supposed to be...
Re:Due to long release cycles (Score:1)
Sorry for the minor nitpick here: it does not mean that the packages won't crash, it just means that none of them have release-critical bugs (== bugs with a severity above "important") in the Bug Tracking system [debian.org] that can be fixed before the release.
If they can not, they will have to wait until the next revision (that would be 2.2r1) and go into the release notes.
--
this post was brought to you by Andreas Fuchs.
Re:Home directory permissions (Score:1)
I didn't advocate ditching permissions on home directories, just changing the default. If users want obnoxious permissions, that's their choice, but the default should be something sensible.
Re:backported bugfixes. (Score:4)
A bit of a bizarre thing to do in the case of the APache and ProFTPD versions mentioned in the article. The newer versions only include bugfixes - so why not ship the real thing? I can't beleive that the Debian maintainers know more than the Apache/ProFTPD maintainers about the inner workings of the software, so what makes their backported fixes any better?
Chris
Re:I don't know if I would call this major. (Score:2)
Wow, whatever happened to ``Linux is ready for the desktop,'' ``Linux is user friendly,'' ``Anyone can use Linux, down with the Microsoft empire''? Now it's, ``if you're a regular user you shouldn't be using this.''
Geez.
-pf
Re:LILO password (Score:1)
A safe that can be opened in 1 hour is better that one that can be opened in 5 minutes.
Next time do some real research. (Score:2)
The main thing i thought (after reading the article) was that it's mostly right, as far as i know.
The package-signing thing has been bothering me as well.
But.
The example of rpm's package-signature checking gives an example of a better idea, but i don't want to think about what happens when the vendor key is compromised. If somebody has the key the rpm's are signed with, he/she can create a very real false sense of security ('the signature's right, so the package is 100% certain correct and secure, as well'), by applying the signature to altered/compromised packages.
The lilo-security thing seems a little farfetched to me as well. I didn't see a comparison with other distributions, and as far as i know, there are no other distributions that enforce a lilo-password.
Did he check the packages of wich you mentioned there was a security hole in them (proftpd, apache) ? A lot of debian packages (and these as well, afaik), are patched to fix those holes. Apart from that, Debian offers (fast) updates to vulnerable packages, in the form of a security.debian.org apt-rule, where fixed/patched versions are available.
From the article: >This portion could be rather long, so I'll cut the list short. Debian has
>shipped more than a few daemons that have severe security problems, many
>of which were fixed well before Debian 2.2 was released. I find this
>unacceptable, especially in the light that Debian has not released any
>updates for these packages!
I wonder if he actually checked all these 'more than a few daemons'. By my knowledge there are no publicly known vulnerabilities in Debian.
Some comments on the summary:
>Debian's goal of a bug free-release hasn't been met. But to be fair, it's
>not like any software vendor will ever release bug-free software.
>Debian has done a particularly bad job in my opinion, shipping out-of-date
>software and especially publicly available network daemons that have root
>hacks in them.
There is no such thing as a bug-free release. Debian has done a pretty good job in keeping their releases (including the latest one) secure. There is no software shipped in the last Debian distribution with the publicly known root hacks mentioned.
>If you do go with Debian, you'll have a lot of manual updating ahead of you
>to bring it up-to-date and secure it. Unfortunately, the argument "
>apt-get, apt-upgrade" won't work, since many of these updates are not
>available as dpkg's yet.
Adding security.debian.org in your apt-rules list works just fine. A lot of Debian maintainers fix security bugs in their packages, often before they become publicly known. An out-of-the-box Debian system will only have the security bugs that have become publicly known after its release date, and these can be fixed with the above-mentioned security updates.
>Debian has also ignored a lot of work other vendors have put into making their
>distributions more secure. If you don't learn from the mistakes and
>improvements of others, there is little hope. This is especially frustrat
>ing in light of Debian's effort to secure various parts of the distribution,
>using Exim by default instead of Sendmail.
>Having seen things like that during the install, I had a lot of hope for
>Debian, but my hopes were dashed to pieces upon closer inspection.
Debian is a distribution that _adds_ to the work other vendors do, making their distributions more secure. If he actually would would have taken a closer look (wich he obviously hasn't done), he would've seen there's a lot more work being done on the security of Debian than there's mentioned. The article shows some knowledge of security in linux systems, but also a very badly-informed, no-research, superficial look on Debian security issues.
Re:LILO password (Score:2)
IMHO the main idea is not to allow the casual nosey colleague to boot the machine. For most home users a password is just a pain in the back anyway.
Same goes for the permissions as far as I am concerned. Imaging the first thing Joey the Brain tries is an ls -l, the one command he has ever heard of, and it does not work -- can you spell panic ?
Now not a distribution user I don't know any of it, but perhaps something along the line press Y to secure the system would be a nice idea.
By the way - changing /home/joey's permissions seems to be a rather silly idea as I am probably going for root anyway.
To be honest, and as someone else wrote already, that article seems to be more about what the author disliked than about security which does not come that cheap -- if you really need it.
Re:Kurt did a hack job (Score:4)
But first you might like to take a look at the init scripts, where you'll find that inetd isn't enabled by default. On all my RedHat and OpenBSD machines inetd isn't running (on the RedHat machines it isn't even installed).
Chris
Re:I don't know if I would call this major. (Score:1)
Note that no Netscape packages ship with Debian GNU/Linux 2.2 proper; they are included in the `non-free' area of the FTP site, and are not included on the official CDs.
Updated packages can usually be found at the Debian FTP sites, either at security.debian.org or in dists/proposed-updates directory of ftp.debian.org (and mirrors thereof). Most of those packages will be integrated into Debian GNU/Linux 2.2r1 when the time comes (probably in a month or so), and the official CD images will be rebuilt.
BTW the problem with login, shell and exec services not being disabled is a bug caused by some sloppy dependencies in task-x-window-system task-package, which pulls in installation of rstart{,d} packages, which in turn enable those services. It should get corrected soon, too.
Re:r services disabled by default? (Score:1)
The point of Debian (Score:2)
The author of this article seems to lack an understanding of the Debian release cycle. Debian was frozen before several of the release he mentions came out. Once Debian has been frozen getting a new package into it becomes substanially more difficult. Now before everyone screams about how now that potato (Debian 2.2) is stable these fixes can't make it in, keep in mind that security fixes are one of the items on the very short list of packages that can be changed once a release goes stable.
Joe Homeuser most likely isn't going to choose Debian as his distribution. Most people who choose Debian do so because the support Open Source ideals to the extreme and as such have problem been around the Open Source block a time or two and atleast have some idea what they are doing.
Are these valid secutiry holes in potato? Yes! Should someone have written an article bringing them to light? Yes! Is this a big enough deal to warrant a Slashdot Story? No! It should be a quickie at best.
Re:Sorry.. (Score:3)
Actually, every RPM issued by Red Hat is signed.
Re:Home directory permissions (Score:1)
Re:r services disabled by default? (Score:3)
Not only that, but the rsh/rlogin/rexec daemons are NOT installed by default on new Debian 2.2 systems. They are in the package rsh-server, which is priority Extra.
Informed comments from a Debian Developer (Score:4)
Question about the home directories thing (Score:1)
Is there a safe workaround? i mean, i have here a computer room for a school with 270 users that want their homepage to show up, even if it's internal -we have one dialup for 12 computers and no money for a bigger connection or more PC's
BR> -you mean that if i were root, i could get all the passwords?
Re:Netscape too? (Score:1)
You have to install them from the ftp-site.
Always do testing on your own? (Score:4)
Why should I have to continously check every new phrickin' software product I install for security problems?
This is analagous to everytime I buy a car, I've got to get under my car and inspect it's braking system, it's steering system, it's fuel system, etc. so the damned car doesn't send me and my family careening over a cliff or exploding on us.
For God's sake, this industry has GOT to start getting things right BEFORE they phrickin' ship. We need a Consumers Reports or UL type-testing system so the software user can reasonably expect they're getting a quality product.
Passing testing security off to the user is lame, lame, lame.
EMUSE.NET [emuse.net]
Re:LILO password (Score:1)
It's not too useful on a desktop system, since it's overly paranoid, but I used it on a 486 that sat in the corner of my dorm room. All it did was crack RC5 keys anyway
"I may disagree with what you have to say, but I will defend to the death your right to say it"
Re:Sorry.. (Score:2)
I will cut you some slack and assume everybody falls into the Everybody(Read:*nix power users)
However, I dont think most people have a clue what they install as the default. Sendmail setup as an open relay by default? When your first learning unix do you know what sendmail is?
I bet learninga bout it is a painful lesson when your machine is hacked or left on a college network full of people ahem.. learning about all facets of comptuer err security.
So yeah after you learn a little its rather easy to go through and pick services you need running and pay attention to Bugtraq/security focus and patch up any bugs for the services you run.
Now.... the average user is not going to just realize (he|she) needs to go to these places or that these things are even insecure..
Jeremy
Re:backported bugfixes. (Score:3)
Some silly points (Score:2)
MD5/crypt passwords. Yup ok thats kind of a silly default these days. Of course IMHO crypt is good enough. An attacker practically needs to compromise root just to get the shadow file anyway!
Lilo is setup to allow command line options. Yea so? Doesn't that make sense after a first instal? Exploiting it requires physical box access, at that point 99.9% of machines can be compromised by throwing a root disk in the floppy drive and hitting cntl-alt-del anyway. Besides....after a fresh install you may want that, lock it down after its working right!
Face it....ANY system, out of the box, needs to be secured.
As for Apache....he complains that it being 1.3.9 rather than 1.3.12. Well Debian has been in freeze for a while. That means "NO NEW CODE", unless there is a security fix. Is that apache upgrade a security fix? If not, then its right to not ship it.
PROFTPd, no clue, would have to ask the maintainer as to why it wasn't done. A look at the Debian BTS shows a root compromise bug fixed...perhaps they just patched the problem in the old version. That way fixing the security issue without introducing any more NEW CODE than is absolutly needed (it was during a freeze).
This is probably the case for several other deamons. He should check and make sure that the system is actually vulnerable before he goes around reporting that it is. Of course without a complete list of which "insecure deamons" he found, its hard to refute is claim that there are "lots".
As for xchat...no clue. I don't use it. Looking through the bug report logs now, I don't see any bugs mentioning this, perhaps noone reported this bug that he is complaining about. He could I dunno, report the bug! What a concept.
> Debian has also ignored a lot of work other
> vendors have put into making their distributions
> more secure.
Eiither that or some author has completely ignored changlog files and bugreports...and feels the need to fault the system for not having the defaults that HE likes. Not like they arn't changeable.
Re:LILO password (Score:2)
The case lock was the most complex and secure I'd ever seen, which coupled with a hardened case made it very difficult to get into without damaging the data. The mirrored hard disks were connected to a custom controller that encrypted the data during disk writes (and doing geometry translation as well, I believe), making it impossible to read the contents if a disk was salvaged and placed into another machine. There were other security issues as well.
Unfortunatly the manufacturers had spent so long on R&D and certification testing with the MoD (UK equivalent of the DoD), that by the time the machine was released to the public the specification was so out of date that the machine was unuseable by modern software. :-)
Secure by default? (Score:2)
It is about the lack of default security in most distros.
Why is it that most distributions isn't made secure by default? (like OpenBSD, which I have heard is pretty secure by default)
Is it convinience? (just turn on "everything", then the user don't have to bother with starting any services)
I know that you can choose the security level when installing the Mandrake distro - does anybody know how secure it is if you choose "paranoid" (the most secure), or which level you have to choose to make it pretty secure by default?
Re:Question about the home directories thing (Score:2)
--
Re:Sorry.. (Score:4)
Um, nope. When I started running linux, the redhat 5.2 manual said nothing about that. Neither did any of the docs I found online, or in the new-linux-user-help type webpages, nor anyone I spoke to on IRC, or over email. I just happened to be talking to a friend and the subject came up, and he said the same thing, "oh, you should turn a bunch of stuff off, everybody knows that." If it's enabled by default, but "everyone" knows to turn it off, why not have it off by default, and let the people that need it, enable it?
--
Re:https being trusted? (Score:2)
--
That's the best he can do? (Score:4)
First thing I do when I install a new dist is go in and fix the default brain damage -- disable all servers (Bind, sendmail, Portmap and FTPD being absolutely evil in my book) install some secure stuff and continue. Now a newbie woudln't know to do this but a newbie won't be able to keep his system secure anyway. Which brings me to point two.
About half the stuff he gripes about assumes you have users. For most Linux installations, if you hand out accounts, you may as well be handing out your root password. Do this sometime: "find / -type f -perm +6000 -exec ls -al {} \;" and count up the setuid files. Now ask yourself how many of them NEED to be setuid. How did you do? Half? Less than half? Distributions hand out setuid bits like haloween candy. Does all that crap need to be setuid? NO! And if you're wondering why setuid bits are bad and you've handed out accounts on your system, you've probably already been taken over.
Re: Netscape: I always turn java and javascript off by default. Not only do I not trust the langauges, but the browser is much more stable without them (Especially Java. Netscape with Java enabled is satanic, really.) 'Course I've pretty much completed my transition to Mozilla, too (With Java still turned off.)
Re: Dpkg: Cryptographic signing would be nice. Probably take less time to add than it did to write this article (Or this post for that matter.)
As for physical access, if you really want to be sure, install encrypted filesystems, because if someone's broken into your house or office with the intent to rifle through your computer, he'll have brought a boot disk and a screwdriver so he can jumper your bios back to its default settings, too.
Personal quibble, chmod go-rwx /home/username? What UNIX god doesn't use the octal numbers, saving themselves 3 keystrokes (chmod 700 /home/username) in the process?
point by point rebuttal (Score:4)
Last time I installed Debian, I had to use fdisk to set up partitions, but maybe I just selected the advanced option. I dunno.
Anyway, unless the machine is a remote syslog server, this opens you up to (at most) a "local denial of service attack". And the only way to deal with those is with a baseball bat.
(2) Crypt instead of MD5 passwords.
The only advantage MD5 has over crypt is that you can chose passwords with more than 8 characters, and a larger salt to make dictionary building harder. Lousy passwords are lousy passwords, no matter how you hash them. And good passwords (8 characters, including non-alphanumerics) are good, even when they're hashed with crypt.
(3) Services in inetd. (discard, daytime, rsh, etc.)
Yeah, these should probably default to off, but none of them are security problems in and of themselves. It'd be nice to ship with openssh, but they can't do that until Sept. 20 when the RSA patent expires.
(4) dpkg not able to check signatures.
This is your one legitimate point.
(5) Home directories world readable, umask 022.
No real security problem here. If a user wants to hide something from prying eyes, they should learn about permissions, or better, how to use cryptography. In general, you shouldn't expect anything on a multi-user system to be private.
(6) LILO.
To "exploit" this, you'd need physical access, at which point the attacker could just as well boot off a floppy. If an attacker has physical access, the game is over.
IMHO, they shouldn't have even bothered with using "sulogin" when entering single user mode.
(7) Apache and ProFTPD versions.
Okay, Apache could stand to be updated, but the cross-site scripting hack is hardly a major security problem.
And your statement about ProFTPD 1.2.0pre10 being exploitable is just plain false! It's ProFTPD 1.2.0pre8 and earlier that have known root exploits.
IMHO they should be using the OpenBSD ftpd by default, but at least it's not wu-ftpd ("Providing remote root since 1994!"), which is the default ftp daemon on RedHat.
In general, I've found that Debian releases security patches just as fast as RedHat and SuSE, slightly quicker than Mandrake, and way quicker than Turbo and Caldera, which run about a week behind.
And the convenience of apt makes getting the security fixes much easier than trying to find a RedHat mirror that's both up-to-date and not completely overloaded.
Re:Always do testing on your own? (Score:3)
Is that the industries responsibility too? Perhaps you want brick-proof winshield glass as well?
Of course it doesn't explode of go off a cliff while you're driving it. Driving is its primary USE. Just like computer systems have a primary USE. It's ABUSE we are talking about here though and the "industry" can't cover everything. All they can do is their best. The rest is up to you.
If you think there will ever be a system you can install and leave and it will be 100% secure then it's only a matter of time before you are H4x0R3d.
Bullshit (Score:2)
I have never used Debian, but I run Slackware, Suse, Redhat, Solaris, Free|Net|Open BSD, HPUX, la la la.
But this article is full of shit. Default Installation is not a security hole. Calling / partiton
and swap partition a weakness cuz they are default is just wrong. Most people using linux today, are
single users. Anyone smart enough to be setting up linux for multiple users is usually smart enough
to partition the drives easily. The default password is crypt? How is this a security hole? This has
been the default, and I will really be ticked off if it was default of MD5 or some other better scheme.
Unless the Unix community adopts a new standard, crypt should remain the standard, Solaris, HPUX, they all
use crypt, not MD5. Default internet services are enabled, again this is nothing new, sure they should
be disabbled, but still, can this goon tell me the security holes in them? It is very amusing that he
mentions that gnuplot needs to be installed setuid root. Has gnuplot being audited for security bugs? How
can he make such stupid comments? First of all, there is X version of gnuplot, and I believe that is what
a user who needs to use gnuplot needs it for. No suid needed! Exim (if configured during install) gives
you the OPTION to use the RBL. What is the freaking problem? It gives you the option, if RBL is not working,
you have the option, and Exim is not debian. It is a package. Home directorys are mode 755 by default and
the default umask is 022, what again is the freaking problem? The only valid point I see him making is that
dpkg does not have a signing support. He blahs about LILO, if someone has physical access to your box, you are
owned!!! unless you are using crypto filesystem. Now, if he has bothered to check the CHANGELOGs he will notice
that security patches have been applied. This is a troll article.
Re:Question about the home directories thing (Score:2)
This is for zsh, but bash should work similarly, I guess. Put it into your global zshrc. (No, I didn't write it, I just "borrowed" it...). It doesn't solve all problems, but some of them:
umask()
{
if [[ $# -ne 0 && $PWD != ~/public_html* ]]; then
_orig_umask=$1
fi
builtin umask $*
}
umask 077
chpwd ()
{
if [[ $PWD = ~/public_html* ]]; then
umask 022
else
umask $_orig_umask
fi
}
Re:Kurt did a hack job (Score:4)
Re:point by point rebuttal (Score:3)
Right. So let's screw all the newbies, then tell them they should have known better.
Of course, on the last remote root exploit just the other week, OpenBSD's ftpd was every bit as affected as wu-ftpd...Re:Informed comments from a Debian Developer (Score:3)
>"usergroups", where every user gets their own
>group. This makes working on shared projects
>(in a +s directory) slightly easier, since your
>umask is 002. However, since nobody is in your
>group by default, your home directory and files
>there are as secure as if they were only user
>writable. This is configurable in
>/etc/adduser.conf, and if it is set to no,
>Debian's default login scripts do the correct
>thing and set your umask to 022
No no no! This is _not_ the correct thing. If each user is the only member of his/her default group (i.e. joeuser/joeuser) and all of his/her files are owned by that group, you are providing _no_ extra functionality by having them group-writeable, or even group-readable. None. Zero. This "makes working on shared projects (in a +s directory) slightly easier" thing is an absolute myth. In order to do what you describe, the user would both have to a) have an idea of how to run chmod and b) actually _run_ chmod, at which point they can change the safe, secure, hopefully default permissions that allow _only_ the original user access to it.
Why is this so important? Because leaving everything completely accessible by groups, _any_ groups, opens up another file to be comprimised. In the above arrangement, all a hacker needs to do is find a way to hack
Also, neither you nor Ben Collins address the problems of leaving user directories world-readable and -executable by default. Say goodbye to working ssh under that arrangement, unless you've got the foresight to manually set your directories up properly. And what happens when you try to set your ssh keys up, expecting things to be secure? You've got a window of oppurtunity where another user on the system can get _all_ of your RSA information. Your personal and private keys are right there, ripe for the taking with just a simple "cp
Come on folks, say it with me now: The correct thing to do is set umask 077 and chmod -R 700
Re:Reaction from an outsider (to Debian) (Score:2)
Sure there is - you assume that your OS vendor knows what they're doing. Debian 2.2 was frozen for several months, during which they've had ample time to fix things. Unless you have reason to believe that they're incompetent, and in the absence of any security advisories telling you to upgrade a package, it's probably safe to assume that the problems have been fixed unless you have evidence to the contrary.
Now, in the case of somebody writing an article about a product, the onus is upon them to check their facts. The changelog is the obvious place to check them. What would you prefer Debian do?
Re:Always do testing on your own? (Score:2)
Re:Always do testing on your own? (Score:2)
And you do have the undersides of your car inspected once in a while. They are called mechanics. They check the oil, if you pay them, rotate the tires. They do do maintenance for wear and tear.
---
Automatically getting all the security fixes (Score:2)
Re:Untrue (Score:2)
Re:LILO password (Score:2)
rawrite bare.i a:
Re:Secure by default (Score:2)
I agree completely. You have to take a proactive measure to security, regardless of what system you run, be it Linux, *BSD, Winblows, whatever. Then, someone will counter, "but I have to install N machines, same (or very similar) configuration for the foo application!".
Well, son, you have several choices.
I did this at one of my clients' sites, where we had over 600 SPARC boxen. Of course, took it one step further, by providing an install server, but then, this was also in a very protected subnet.
Do it only once, but for Seldon's sake, do it right!
--
Gee, nice response, Ben. (Score:2)
Please, people, keep your cool when people say negative things about Linux stuff. I don't know why I'm saying it seeing as how very few people seem to hear it, but I'm saying it anyway. Maybe if some of us say it enough, the abrasive minority will start to listen.
You do all of us a disservice when you react like Ben. Yes, the review was misinformed. Yes, this Kurt guy didn't do his homework.
That's the press. If I had a dollar for every time I read a misinformed review of a Linux product, I'd have that MR2 Spider that I've had my eye on.
One day they'll "get it", but until they do we need to guide them a little. Flamage will get us nowhere. Be calm, and people will listen. We need to come out on top here, folks.
Re:Simple equation. (Score:2)
Italian men as well as many europeans men carry large "wallets" that could be called purses by americans.
many english actually call a wallet a purse.
also, did you ever see the Seinfeld episode about the male purse?
Re:OpenBSD's ftpd (Score:2)
The fact is, more users will need help than not for most situations. This isn't going to change in the foreseeable future. It's only responsible to set up the software to help the newbies by default, with an option to take off the "training wheels" for expert users.
Most coders seem to sometimes forget that we have a responsibility to our users to make the software as easy to use and learn as we possibly can. When we don't do this, we're screwing the vast majority of our users over big time.
----------
Re:Informed comments from a Debian Developer (Score:2)
The flaw isn't with SSH. It's with Debian's default umask and it's default permissions on home directories.
Re:Informed comments from a Debian Developer (Score:3)
What happens if there's a bug in say, vi, that lets an unpriveledged user kidnap an editing session only for the current file being edited? If you're editing
Your example for
Having to do both of those things means you have saved the user exactly NO time by making things default to being group read/write/world read.
There is nothing wrong with having those permissions on a directory. It _is_ a problem if those permissions are the _default_.
Microsoft Windows security problem? (Score:3)
Re:*nix users (Score:3)
Increasingly, the "average" user is using UNIX, or at least being exposed to it. The problem is... how do you learn something about UNIX, if you don't know anything already? As has been pointed out, documentation (installation guides, bug reports, security vulerabilities) are fragmented; quite frankly, there is no way that a new Linux user can set up a secure system, because existing distros are all installed with certain well-known insecurities.
If you think that's untrue, consider someone with a new computer and a copy of RedHat/Debian/whatever, who get's told that all this wonderful security information is available on the net. In order to gain access to it - and read about how to secure their system - they need to install an unsecure system. Of course, this isn't the reality of the situation - most new users aren't aware of security resources on the net, of course, and nobody thinks to mention them to newbies, because, after all, everybody knows about them, right?
If there was a bug in login that allowed someone to gain root access to your system if a common file (installed by default) existed in /etc, there would be no question - this is a security flaw, and it must be fixed. Saying "Everyone knows that's a problem - if you really know UNIX, you just make sure you remove that file after you do an install" wouldn't cut it.
The same holds true in this case; installing services - like sendmail - that have blatantly stupid default settings and open up a box to potential abuses, just because "everyone knows" that you need to change the default configuration to prevent it, isn't an answer. The systems should install locked down tighter than a miser's wallet, and require a user to gain knowledge in order to expose new capabilities.
Re:That's the best he can do? (Score:2)
I tried your experiment on my redhat system and found only 34 suid files. 12 of those were actually had the sticky bit set on the group so they only changed gid, not uid. Of the remaining programs they consisted of either security wrappers like Xwrapper, pt_chown or programs that need suid to work gpasswd, chfn and friends, su, mount, umount, etc. or daemons and safe programs that need it at, ssh, crontab, sperl, suidperl. The only questionable choices I found were ping, traceroute, and usernetctl but ping and traceroute don't work with out suid and usernetctl is small (
Incidentally as others have pointed out, RedHat has changed to not installing inetd when you choose the workstation config and I believe they closed off a lot of the open services in their default inetd.conf
Re:Security patches were applied on many packages (Score:2)
Clearly you are on the super heated smack.
Re:Informed comments from a Debian Developer (Score:2)
>of an original file within the constraints of
>your umask. With a umask of 022, a file with
>permissions of 600 will keep those permissions if
>you cp it somewhere. scp behaves in the same way.
>Unless you're doing something stupid like
>using cat to copy your keys around, it doesn't
>seem like a problem.
Hrm. Poor example then. You do, however, see my point. Anything you create is immediately vulnerable to being copied by any other user. Forget using your favorite editor to create files. Now you need to "touch filename;chmod 600 filename;vi filename".
Fortunately emacs obeys existing file permissions with is tilde files, otherwise you could be in for even more pain.
Proftpd potental invulenerability (Score:2)
Don't put words in my mouth. (Score:2)
The fact of the matter is, whenever I visit my mother, I sill have to baby her through *Windows*. She can't install a single piece of software, she can't set up a ppp conection, she can't configure the zip drive she bought, nothing. She knows where to click to check her mail via telnet, and when I tried to convince her to use putty instead, she said her "mail wasn't on putty, it was on telnet". And my mother has four degrees.
As another example, I was down in the telecom office of my university yesterday, and listened to a conversation between a lady having problems with her campus dial in connection and a telecom desk operator. Aparently, when she dialed in, she was prompted for a "new password", leading her to believe her "hotmail and internet explorer been deleted, it was all just deleted". The telecom desk operator's only job was to collect payment, so she couldn't offer any sort of help. This lady was stuck in some sort of wonderland where she didn't understand anything.
I'm a firm believer that unix isn't right for everyone, just, as you can see from the above, that windows isn't right for everyone.
So next time don't put words in my mouth, thanks. Not everyone on
Oh, don't get me wrong, (Score:2)
Glad to see the hard working folks at debian are on top of it, though, and there is at least a reason behind it all.
Re:Kurt is a reporter, so the answer is 'yes' (Score:4)
How much work is it to just update the package to the latest version anyhow? Sure, some things change, but when it comes right down to it, people want to look at a machine and say "Yes, I've got Apache 1.3.12, and I'm safe" rather than digging through the bug reports for obscure information.
It's VERY easy to update to the latest and greatest. The problem there is that then you'll be distributing reletivly untested packages with various unknown security flaws in them rather than one where you have patched against flaws in a well tested version.
In other words, updating a package (Debian or any other package) involves about 5% work to put the package together and %95 to make sure it's at least no worse than what you have, including broken dependencies, silent loss of data, and gaping holes in security.
Many people ALREADY perceive Debian stable to be out of date. They can either use another distro or load unstable (Currently Woody). Others use Debian stable in production because it is WELL TESTED. For a busy ecommerce site do you want the latest of everything, or proven reliable stuff that's a bit older?
Besides that, new versions come out DAILY! Nobody can release a new distro every day!
Re:Security patches were applied on many packages (Score:2)
Creating their own scheme just confuses everyone. If they have patched apache so it is the equivalent of 1.3.12, then call it that, so that the sys admin knows that both the Solaris box and debian box are up to date.
But they didn't do that! They just backported the security and bug related fixes. For new features, you'll need the real 2.3.12 release when it's available (or install it from tar.gz and take your chances).
Re:Sorry.. (Score:2)
My personal opinion is that if you are running *nix, you should know this stuff. Not every end user is going to be a *nix expert but being ignorant of the operating system you are using is something that irritates me. However, I also believe that if vendors like Red Hat are going to market to the home user, they need to educate the home user and/or make their default install more secure. It is lame and irresponsible to just install everything and enable everything by default.
The guide I mentioned above is a good checklist for fixing open security problems in that it helps you whittle your install down to only the files you need. Its hard to get hacked via the rpc.statd exploit if you don't have the NFS stuff installed. However, one major problem I have with that guide is that it functions mainly as a checklist (not to mention that its 95% regurgitated config files, READMEs, RPM listings, file listings, and kernel sysctl Documentation) is that is mostly a checklist. Its long on the "delete this package, that package, make this change, do this, then that" and short on explaining why or how a service or package is a real problem. Of course not everyone cares about the inner details of exploiting services but the best defense, in my opinion, is a good dose of common sense and a good notion of how someone can exploit what you have. For that, experience is the best teacher and I haven't found a HOWTO for common sense anywhere (maybe thats why so many people are clueless). If you want a sort of overview of how hackers operate and how they might exploit something, I might recommend "Hacking Exposed" by Stuart McClure and Joel Scambray.
Hope this helps. email kSeviTn_OmyPer@iuS13.kP12.pAa.uMs if I can be of more help. (Remove the STOP SPAM)
Re:Sorry.. (Score:2)
Yes, I am a Linux newbie, but the docs that come with, say, Red Hat 6.2, don't mention anything about how you go about disabling sendmail (which in RH6.1 is installed even if you tell it not to put it on), inetd, wu-ftpd, and whatever other programs, daemons, etc. need to be disabled, removed, or at least reconfigured.
Look in /etc/rc.d/rc5.d and rc3.d. All scripts in there are links to the startup scripts of the various daemons. If you want to kill off sendmail, do:
./S80sendmail stop
rm S80sendmail
The first kills the daemon, the seconds keeps it from running next time you boot.
For inetd, vi /etc/inetd.conf. Insert a '#' in front of any service you don't want.
After saving that, killall -HUP inetd to make it re-read the configuration.
Bugs vs. features (Score:2)
Bugs arent features, see?
Try telling that to Micros~1.
"PROBLEM: Windows bluescreens when you do foo, bar, and baz. STATUS: This behavior is by design."
<O
( \
XGNOME vs. KDE: the game! [8m.com]
Re:LILO password (Score:2)
Disable booting from floppy and password protect your bios will solve the floppy disk problem.
Make sure your BIOS has no backdoor passwords in it. Some did a few years ago for when a luser would set and forget a password then call tech support. I don't know if that practice has stopped or not.
Other physical access problems are a lot harder. It is impossable to make it ABSOLUTELY secure from physical attack while still being a usable system. If security is paramount, a kernel hack that asks for the key to the encrypted root filesystem on boot would be a good start.
Oops. (Score:3)
Thanks
Bruce
Re:That's the best he can do? (Score:2)
There is a subtle difference between the two types of command: the latter is like the former with an implicit "chmod u+rwx
Kurt's Cluelessness (Score:2)
Here is one of his articles that ended up in a printed mag. It discusses PAM and attempts to discredit shadowed passwords in the process. The information is misleading and inaccurate. The article sounds more like it was released from a marketing dept instead of a self-proclaimed security expert.
When he discribes limiting access to ftp, he is basically saying only a good password will limit who can access the system. What about, /etc/ftpaccess or /etc/login.access. Not to mention using tcp wrappers and /etc/hosts.deny.
When he discribes using limits on users, he tries to imply only PAM can do this. Yet he fails to mention /etc/limits. If you 'man limits', you will see the available options are EXACTLY the same the ones he mentions are in PAM.
I see Kurt post to a few security mailing lists, Suse , BUGTRAQ, Linux Security Auditing Project, Bastille, etc. For the most part, his posts are worthless. Claiming PAM is the greatest thing since sliced bread, flaming others for off topic posts, repeating well known information, etc. His new project, LSKB [securityportal.com] lacks any kind of useful information and is more of a waste of time than anything else.
I have no respect for him and try to ignore him as much as possible.
Re:point by point rebuttal (Score:2)
Right. So let's screw all the newbies, then tell them they should have known better.
Debian is mostly targeted at experianced Unix users. A newbie who wants to set up a home system should do some reading first, ask a more experianced friend to help out or start with a more newbie friendly distro. Most do the latter simply because they base their purchase on advertising.
My own experiences (Score:2)
A couple of weeks ago, I used Debian 2.2 to set up a test firewall at work. I'll try to summarize what I did.
This firewall is nowhere accessible through the Internet. One ethernet card is connected to the company Intranet, while the other just has a crosscable attached. Because of this, I wasn't very concerned about security. I wanted to practice a little by tuning the box.
(Why this firewall, you might ask? I figured we needed a setup to demonstrate to our clients that our applications will also work through a firewall setup. And I had nothing more important to do - being between 2 projects.)
When the installation program prompted me to allocate partitions, I opted for a root partition, a small /boot, and the second hard disk for /usr. (Nobody really tells you how to partition hard disks - that's why most newbies end up with a single partition.)
At the end of the installation, I was asked whether I wanted MD5 or crypt passwords. The dialog listed some of the reasons why I would want either one.
The default network installation did activate a couple of services like telnet (don't remember which ones), which I had to uninstall. For the builtin inetd services, I didn't even bother to deactivate them. (I'm not sure why I left inetd running. Probably because I wanted one service from the list.)
I did leave exim because I needed a way for the system to report what's happening. Unfortunately, this left a process listening on port 25.
I deactivated X (the PC had a lousy video card anyway).
I had to recompile my kernel in order to support IP forwarding and Masquerading. In the collection of packages I found mason, which is supposed to make it easier to configure a firewall.
I tried this, and I got a list of all the broadcast messages on the company network (quite a lot). I threw away all that junk, and started studying the HOWTOs. I ended up with a configuration that will forward 5 TCP ports (we have a couple of web servers listening on unusual addresses), DNS (for convienience) and ICMP (to facilitate network debugging).
The machine has a couple of services running that might reduce security: DHCP (to configure the client PC), squid and SAMBA (easier access from my own PC).
The bootup settings: no BIOS password (automatic reboots), but the LILO images are restricted (i.e., you need to enter the password if you want to pass options).
Finally, I had to set a few kernel parameters as mentionned by the HOWTO.
All in all, a pretty secure machine, at least from the network. I can't think of anything that would hold of a determined person who gets access to the console.
I can always close up the remaining holes if I want to, but I don't think anyone will try to break into the machine anyway.
All in all, it took 2 days to get everything the way I wanted (not only the security aspects). I learned a lot out of this and, most importantly, it was fun!
Re:Your karma recipe for today (Score:2)
Hmm... Internet Explorer has a minor bug that allows some users to view (not change, mind you, but view) contents on a select number of users hard drives. "The travesty! Has Microsoft no remorse! Clearly they don't test their products, and anyone using them from a security standpoint should be marked as a rat bastard!"
Debian is earmarked for possible security faults. "It's a shame, but I'm sure it won't happen again. Remember people, nothing is 'automagically' secure. Linux users are the cream of the crop, and a bug... well... I just don't believe it myself.
Sigh... when is Slashdot going to be seen as reputable? When they stop throwing a bias at everything involved with Linux.
Security vs Convenience, Experts vs Novice (Score:3)
That brings me to TWO points. Alot of this discussion has turned into "Everybody Knows" and people need to shut off everything in the machine to make it secure.
#1. If everybody knows, that implies a culture which doesn't accept newcomers with a proper sense of respect. We want new people to use Linux (supposedly) but then we say that it is ok to leave certain security holes because everybody knows to close them. That is nonsensical because what it implies is that the only important people to consider on these installations is experienced users, when a truly experienced suer is NOT the target of this sort of install. Infact one of the joys of Linux is that a really experienced user can make their own canned distro anytime they want, and can essentially fix the assumptions of a distro to their own desire. Yey... Newbies on the otherhand need alot of guidance, more than Linux or Microsoft give. My understanding is that Apple managed to make it so that one can turn on their G4 models with airport and run a webbrowser immediately. That is FAR closer to what newbies need. Closing off security holes as the first step is NOT.
#2. My father has been in the industry since the 60's and he basicly told me that the perfectly secure machine has NO access. Basicly on one side is the availability of services, and on the other side is security. the more services the less secure. People ehre are mandating locking floppy drives, welding shut cases, turning off services.
This is sort of ironic. Even when I started using Linux (Slackware with kernel
Before one evaluates security one needs to evaluate use, and while a distro can be helpful to give a new user an idea of the risks versus the benefits of any decision they make in terms of services and security, there is never going to be a hard enough solution to protect against local penetration, no matter what folks say. In circumstances where someone has physical access to a server even if one can't physically tamper with the machine, effective surveilance, keyboard taps, and any sort of wiretap on datalines makes true security difficult especially in circumstances where the average user STILL probably uses a variation of his/her kid's name as a root password. Or worst writes it down.
Linux has come a long way, and Debian, Redhat, Slackware, SUSE, and every other distro makes a competition of both features and philosophy that is so valuable to the community, that discussion of fragmentation has seemed to fall off in the last year. We can see that ALL Linux is growing, and we are indebted to all those who have examined security issues on EVERY package, every DISTRO, every OS, every kernel. However security is a wide scale and no system that runs power is truly secure. Lets just be thankful that we are talking about a system where users CAN learn to secure their system by themselves.
dlg
Compared to Windows you mean? (Score:2)
Chmod... (Score:2)
Re:LILO password (Score:2)
They all have the password backdoor of taking the battery out so that the info including the password is erased in the BIOS.
Absolutely. Many motherboards even provide a convieniant jumper for that now. At least it's harder to inconspicuously open up the case to reset the password than it is to go in (looking like a run of the mill techie), and use a backdoor password.
The more paranoid will put a good lock on the case so that opening it is much harder to do.
Re:Can Someone Help? (Score:2)
Does a lot of talking make your system more insecure, or does it just make you feel insecure?
It is much safer to be frightened by talk and let the fear drive you to education than to wallow in ignorance.
Anyway, please check http://security.debian.org/ if you're using Debian.
Making a network more secure requires an admin to think of what could possibly happen in any situation. For example once upon a time in a land far far away, someone pondered:
"Hmmm, packet sniffers make it possible for someone else on a network to capture transmitted data."
"Waitasec, telnet is unencrypted! Everything is sent out in the clear."
"Maybe I should stop typing in my passwords via telnet to access a machine remotely."
Re:Reaction from an outsider (to Debian) (Score:2)
ROTFL (Score:2)
Re:assuming you aren't trolling.......... (Score:2)
What should I do fix the holes in the default installation?
The first thing you should do is subscribe to the debian-security-announce [debian.org] mailing list. That way you will be informed whenever a security fix is made available. (Don't worry, it's not often enough to flood your mailbox!)
The second thing you should do is make sure you fetch those updates. You can always get them by hand (the instructions are in the announcements made on the mailing list). An easier way, if your machine can reach the World Wide Web, is to use apt. Put this into the /etc/apt/sources.list file:
deb http://security.debian.org/ potato/updates main(Make any other changes to your sources.list at this time.) Then run apt-get update , and apt-get upgrade . You can run those commands any time you like, to get the most recent updated packages. Now that potato is stable, there will not be updated packages very often, but it doesn't hurt to check.
The third thing you should do is review what's installed on your system and delete anything you don't want. This is tedious and time-consuming. You also won't be able to make too many informed decisions at first, since you probably don't know what everything does yet.
I haven't installed the newest version of Debian from scratch yet (my Debian boxes are a couple years old), so I don't know how much "cruft" there is in the default tasks. But if it's anything like the previous version (slink) there's probably a whole lot of cruft.
So run dpkg -l | less and actually read through the output. You will probably see some things that look vitally important (like "dpkg" or "libc6"), some things that look terribly unimportant (like "bsdgames"), and a whole lot of things where you can't decide.
Start by removing all the things that you know you don't want. If this is your desktop system and it's behind a firewall, you probably don't need to run a name server or have the Apache web server development kit installed... on the other hand, if this is your firewall, you probably don't want xbill installed. ;-)
Once you've done all of those, take a look at some of the individual packages. You can use "dpkg --status packagename" to see all the meta-information about the package, including its long description. (You can also see this in "dselect" if you use that program.) Then try removing some of them. Remember two things here:
The fourth thing to do is to look at the system from the outside point of view. Try port-scanning your box from somewhere else on your network (another Linux box running nmap is a good way). If you see a port that's open, find out why. (Hint: lsof -i :25 will show you the processes listening on port 25. Or, fuser -n tcp 25 will give you the process numbers, which you can then look up with ps.)
At first, you may not know what each of these services is, so you'll have to do some research to figure out whether you want to keep them. Find people you trust and ask them, or hit the docs.
When you find services you want to disable, find out how to do it. The methods vary with the service -- some services run as a standalone process (like sshd on tcp port 22). Some run under the control of inetd (like telnetd on tcp port 23). Some may run either way, depending on which program is implementing that service and how the program's configured. (E.g., sendmail runs as a standalone daemon and offers smtp service (tcp port 25), whereas qmail-smtpd could run from either inetd or under control of a separate program called tcpserver.)
Each service is different, so you will have to do some investigation to figure out whether you want to disable them, and if so, how to do it.
By the time you've done all that, you won't be a newbie any more. ;-)
The fifth thing you should do isn't specific to Linux or Debian. You should make regular backups of your important data. I'm constantly amazed at how many people fail to do this. The most important things to back up are your personal data (/home) and your system configuration files (/etc). (Note that Debian policy requires all configuration files to be under /etc.) If you've got more room, you should probably back up /var and, if you use it, /usr/local. If you still have more room, back up the whole file system hierarchy.
Also, make sure you have more than 1 backup. Don't just reuse the same tape every time -- have at least two tapes (or Zip disks, or whatever) and alternate between them. Better yet, have a lot of them and rotate them (use the oldest one each time). If you're doing this on an important system (not just your personal toy), you should ship some of those backups off-site in case of a major disaster.
Can you name the things that I need to change passwords on?
There isn't anything you need to change passwords on -- but you might want to set a few passwords.
Your user accounts (most especially root!) should all have good passwords. That's absolutely essential.
Beyond that, it depends on how paranoid you are, and how much the data on your system is worth to an attacker. It will also depend on external factors (e.g., is the computer locked in a room to which only you and your boss have keys?).
You can set a password in LILO (assuming you use LILO to boot), which will prevent users from passing boot parameters to the kernel. But in order to pass boot parameters to the kernel to LILO in the first place, they have to be physically present at the keyboard, and they have to be able to cause the machine to reboot (e.g., by disrupting its electrical power).
A user with physical access to the machine has other options, however, besides LILO. They could insert a floppy disk and cause the system to boot. You can prevent this by telling your computer not to boot from floppy diskettes (in its BIOS), and then setting a BIOS password which prevents the user from changing the BIOS back to its defaults. (This has nothing to do with Debian or even Linux.)
The problem with this is that it's still possible to override the BIOS password, either by changing a motherboard jumper, or by temporarily removing the battery, or by stealing the hard drives. This requires access to the inside of the machine, which is why some people here have been talking about locks on the computer's case.
Personally, I don't bother with any of that stuff. If a system has to be secure against the kinds of things discussed in the preceding few paragraphs, then it should be in a secured room.
Re:Kurt is a reporter, so the answer is 'yes' (Score:2)
You have hit on one of the few problems with Debian. Stable is too darn stable, and unstable sounds bad.
Personally I simply run stable with a few packages from unstable (PostgreSQL for one) that have packages that I know are solid upgrades. This sort of thing is trivial to do with Debian Linux. It involves changing one line in /etc/apt/sources.list and then run apt-get update apt-get install and then changing /etc/apt/sources.list back.
The Debian project is also adding yet another distribution that will be somewhere in between stable and unstable.
I can understand your response to Debian backporting patches. I mostly agree. It would probably be easier for all concerned (less wasted effort) if they just upgraded to the newest stable version. As for Debian developers telling someone to "piss off" when they find a bug in unstable, clearly you have never used Debian, nor their bug tracking system. Most developers actually use unstable, and they are VERY interested in making sure that it works.
Side-note correction? (Score:2)