Slashdot Mirror
Debian 2.2 "Has Major Security Issues"? UPDATED
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
Check out the cnn article here.
OpenBSD - Three years without a remote hole in the default install.
Ex: Apache:
http://cgi.debian.org/cg i-bin/get-changelog?package=apache
IOTW - the security may not be perfect still, but let's not get carried away just because we're too damn lazy to read.
why is it that when there's a Microsoft security issue, the title of the story is always a statement while when someone posts an article about security problems in linux or other major open source applications, it's always a question or doubting statement?
Linux distros need to start making changes to there default install to a secure install. So people if people wants to use a service they have to turn on themselves.
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.
this post was brought to you by Andreas Fuchs.
echo [Address] | sed s/[-a-z]//g | tr A-Z a-z
Nothing in that article really qualifies as a 'security hole' in Debian. And most of the things in the article are common to *ALL* distributions. LEt's look at them.
;)
- 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,.
In order to be able to use "init=/bin/sh", one needs physical access to a machine (discounting the rather obscure case of having a serial console that's accessible via a network). With physical access, there is no such thing as security. Having a LILO password makes things slightly more difficult, but IMO that'll just give a false sense of security: think of booting from a different device, temporarily placing the hard drive in a different machine etc.
The author of the article should read the changelog for the proftpd daemon, for apache, and so forth. Debian has a tendency to backport security fixes instead of shipping the newest versions. I find that much better than always shipping the latest and greatest bugware. :)
--
"Rune Kristian Viken" - http://www.nwo.no - arca
Permissions (as seen on unix systems) are a horrible way of managing access to files. Every user has to be aware that his/her umask is set to some reasonable value. This value differs from situation to situation. If you are working on a project with multiple people 002 is good it the others are in your group. If you are working on private files 077 is better. How often do you change your umask when you are doing some editing? Useing permissingbits for access is asking for trouble (the users I've seen with 002 umask for files in their homedir).
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>
The author of the article claims a lot of packages (he mentions apache and proftpd) are out of date, while he didn't realize that Debian 2.2 was frozen months ago. This means that at release, packages are dead-stable (they wont crash) but might have a few holes in them by now. And, as another poster pointed out, backfixes do exist.
Ivo
<grub> Reading
That's a rather stupid approach. It's like saying let's not require passwords since that gives a false sense of security.
Sure, permissions is not the ultimate secure solution, but it's a whole lot safer than letting everyone read users home directories.
Honestly, most of the author's nitpicks are small. Debian ships with the same kind of default settings as most Linux distros do these days, openings in inetd, one large / partition, some older apps with holes, and silly home directory permissions. Really not much a seasoned user can't handle; if you are the kind of user who just installs the default and leaves it, you probably shouldn't be using any sort of unix (or unix-like) system (maybe with the exception of openbsd, which happens not to work with my network cards).
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.
This sig is false.
> Always do testing on your own.
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.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Man, that reporting was almost bad enough to be Jon Katz-level "quality."
;-). Note that several other security-minded distributions also enable them. Look at, for example, the OpenBSD default inetd.conf and be amazed at everything that they enable.
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.
I wonder how they backported security fixes for Netscape.
Perhaps it's not so funny as it's supposed to be...
I was thinking more of NFS, where files will get sent unencrypted over the network anyway. I agree, on a system where users log in locally, which isn't likely to be cracked or physically broken into, chmod go-rwx might be effective.
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.
-- Ed Avis ed@membled.com
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.
First and foremost every linux distribution caters, or atleast claims to cater to a specific subsection of the linux population. If you want the most recognized linux distribution, with the one of the bigest installed bases out there you run RedHat. If you want a distribution that is as tight as a drum you apply Bastille Linux. If you want productivity suties cleanly integrated into your install process you run Corel Linux (which BTW is based on Debian.) If you feel like supporting User Friendly you run Suse. If you want a distribution that you know all the parts work well together in you run Debian.
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.
"You can't fight in here! This is the war room" --Dr. Stra
Whatever distro you are using is completely messed up then. On a modern distrubtion these problems simply don't exist, or at least on RedHat from at least verison 5.0 they have not existed. The problems you mention are EXPLICITLY mentioned in the RedHat User Manual and they discuss they quite simple solution that is completely transparent to the user. Every user on the system has their own group and the default umask is 002. So lets say we have a user bleh. When he creates a file it will be owned by owner bleh and group bleh. The file permissions will be -rw-rw-r-- . Since bleh, is the only member of group bleh, he will be the only one able to write to the file. Every one will be able to read it. If you don't want everyone tob e able to read the file you can make your umask 007. Also note that by default redhat makes home directories -rwxrwx---. Thus another user on the system would not be able to read the file unless they knew the name of the file. Just remeber you can change your umask if you don't want other users to be able to read your files. Now let's say bleh is working on a project with several other people. The system administrator creates a new group 'project1'. He adds all the users assigned to work on the project to the group project1. He creates a directory where all teh work for the project will be stored, /usr/local/project1. He does chown root.project1 /usr/local/project1 . He does chmod 770 /usr/local/project1. He does chmod g+s /usr/local/project1.
Now, when user bleh or any other user working on the project creates a file in /usr/local/project1 the file will be owned by the user who created the file and the group of the file will be project1 (Since the directory is g+s). The permissions of the file will be -rw-rw----. This means any user working on project1 can read or write (modify) the file. ALL OF THIS TRANSPARENT TO THE USER.
The only person who has to woorry about this is the system administrator. This procedure is documentted in several places and any system admin worth a penny knows it already.
So before you go spouting about deficiences in permission lists, GO AND READ!
Group writable home directories: Debian uses "user groups", 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
We all know that go+rx is not a good idea, but as Kurt says, if you protect the userdirs (chmod go-rwx) the apache user directory behavior (the "go to http://our_server/~yourusername to see your webpage" thing) breaks.
:( - Is not like they have top secret documents, but...
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?
This is the stupidest idea continually propagated by us geeks. I'm not flaming here!
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
"We're sorry, but the website you're trying to reach has been disconnected."
From glancing through the article, it appears that he's ranting about one basic thing... there is no perfect distro, and if there was, it isn't Debian 2.2. Big deal!! I have yet to install that "perfect distro" on my machine. I don't like things about Mandrake, Redhat, Slackware, and Suse. I think this goes on the same basis as a distro war.. certain distros do things better than others. So Debian didn't suit the needs of this guy. Install something else that appeals to you and move on with life.
"You'll die up there son, just like I did!" - Abe Simpson
There is no reasonable defense against an idiot with an agenda
:wq
I realize that openness and security are always at odds, but I have always preferred world readable directories for convenience. Most of the generic files in my directory (.cshrc, .login, etc.) are files that a relative new person could learn a lot by perusing. I create private directories for the things I don't want to share.
I am probably a little more vulnerable because I don't close everything and open only what I want; but I want most everything open and I like the good atmosphere of it.
so you must somehow get the MD5 sums from a trusted host (https:// for example).
Since when does running an SSL webserver mean that it is trusted? All it means is that the connection is encrypted, not that the information is any good.
Normally I wouldn't nitpick about this, but in an article about security risks, you'd expect the distinction to be made. Ho Hum
Of course I do. But do you realize that not all of us run "free" distros and want to recompile our own kernels every other month? I was speaking of the general attitude that security rests with the user. Boxed distros/OSes and other boxed software was my target.
EMUSE.NET
"We're sorry, but the website you're trying to reach has been disconnected."
"We all know that go+rx is not a good idea, but as Kurt says, if you protect the userdirs (chmod go-rwx) the apache user directory behavior (the "go to http://our_server/~yourusername to see your webpage" thing) breaks." The simple solution is to create a directory structure parallel to /home (say /www) with more open directory permission so the web server can read them. Then reconfigure Apache to read personal home pages from there instead of ~/public_html.
Actually, I think about the best thing for your karma is to be the first to post a Karma Recipe to each new article on slashdot.
Ok...the umask is permissive and user home dirs have read and execute bits by default. All this means is that users need to be carful. I have no problem with that....thats not a real security flaw. Its just something that the author doesn't like.
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.
"I opened my eyes, and everything went dark again"
As for the basic services, some of them actually come in pretty handy. Sure, you don't want to allow them to be misused, but there's quite a simple solution for that.
Under Linux 2.2.x, you'll use "ipchains" to block off the ports these services are running on to all but your own trusted hosts. You should also block off any packets claiming to come from non-routable adresses and other suspicious stuff. This way, you don't actually need to disable any of your services, you can simply block off the ports they run on.The need for security at all is worrying to some, though, including me. Because it means that we are losing touch with ourselves - with the essential goodness of the universe. That security in other forms (non-digital) has been around for thousands of years is no license for teh behaviour of mistrust security demands - neither, however, is the non-use of it license for abuse of the trust shown by the individual in question - no, if we are to be one - with ourselves, with eachother....
This can simply be explained by explaining the universe itself - not all of the universe, but a vague conceptualization of it, and how it - in part - relates to to the parts of us that come into play when thinking about things that make us need security - alienation from fellow human beings, the thought that something deceptive is running through our minds, our souls. This is the algorithm.DIM b AS Integer
DIM Universe AS Integer55:
b=0:IF b=0 THEN
DOb=b+1
Universe=b+2IF b+0=Universe THEN GOTO 55
Everything is but a number spoken by itself.
LinuxPlanet has a pretty good article about the default security in all or most Linux distributions here.
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?
I have been using Debian, but use RedHat now. And I can still recognise each and every security complaint in this article.
/home/*/ is world readable. Well, I remember that this was part of Debian's philosophy of an open system; almost all files in a Debian install are world-readable. Please don't ask me why - I can only recall reading that it was part of their philosophy. But it is, at least practically, the same with RedHat; because they also use /home/*/public_html for the ~* Apache directory. So if you user dir would've been rwx------, you would change it to rwxrwxr-x yourself just to be able to have a website of your own. At least I did in my ignorance, and let that be a proof that other idiots will do this as well. BTW, I have access to an OpenBSD machine, here also all files are world-readable.
;-) This attitude needs changing.
-
- inetd and daemons open. I am glad that this is critisized. Because Unix is so proud of its connectivity etc., it often wants to show off that running a lot of connectivity apps by default is "standard" and "normal". In my RedHat inetd.conf, there are a whole lot of things open that I've never even heard of, but of which I don't know what will happen when I switch them off. And the daemons... well, don't speak about the things RedHat 6.0 launches
- The signed packages thing has luckily become an issue with Debian. But as shown, AFAIK, you have to check for signs in RedHat by hand. It would have been better if somehow you package system detects the problems and alarms. Now THAT would mean something. But the trust we have in automatic upgrades makes us very vulnerable, indeed.
BTW, it's funny how -x works for a directory. I never knew. Actually it works kind of strange; you can list all files, but you cannot have any further information on these files (e.g. ls -l). You can't delete the dir. Strange. Should't -w and -r have a little more logical effect? In other words, what's the special use of -x?
Greets,
Stefan
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
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?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
(1) "Defaulting to one partition."
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.
If something is really secret then encrypt it but most users including myself have plenty of files kicking around our home directories that can't encrypted but should still be inaccessible to nosey users.
For example all of the standard resource files, .profile, .bashrc, .bash_history, .newsrc etc. can't be encrypted/decrypted since software needs to read them.
Or, as has been the case, point out that the article was poorly researched ... but then, that requires actually knowing how Debian does things, doesn't it? Obviously they spent all that time between releases doing something ...
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
Bullshit!
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.
------ Curiosity killed the cat. {satisfaction brought it back | it didn't die ignorant | lack of it is killing mankind
From here, it looks like those guys at Debian should be ground up and sold for fertilizer! It's obvious they know NOTHING about Linux and are just masquerading as "security experts"...
Anybody have some white masks and torches?
(sounds *fun*, eh?)
-Ben
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The comments to which you are replying are directed at a journalist writing to inform others about security issues. If you're a journalist, yes, in fact you should read the CHANGELOG instead of simply thinking "hey, default apache 1.3.9 had security problems, therefore Debian's 1.3.9 must have them and running with that.
As a supplement to providing yourself with information, it's not like Debian's package maintainers don't use email, it sounds like the author simply went ahead with his 'scoop' without contacting the principals for their take on it. Such 'ambush' tactics are unprofessional, and obviously, in this case, they backfired.
It's no crime to call the author on this sloppy journalism.
"Oh, I hope he doesn't give us halyatchkies," said Heinrich.
Yes you should check over a car your going to buy.
It's even more importent when buying used but it's importent for new cars as well.
Mass production is not perfict and defects happen.
It is quite posable for there to be minnor damage like a leak in the break line.
Do we all check our cars for such defects?
No... we don't... We buy expecting to get what we are sold. A new car. If a defect shows up in warrenty we take the car back.
People play the same with software... Take the risk and watch for bug fixes...
If you absolutly must have a stable machine then you absolutly should check it over yourself.
If you must have a car in perfict condition you don't have a choice...
It's something for the paranoids... if you don't care don't bother...
I don't actually exist.
sudo is more flexible than su
You obviously haven't been looking at the net moderation done on my karma recipes beyond the first one...
This guy is obviously impartial; for example, he says that default is DES and, because he prefers MD5 to DES, debian would not be secure? Backward compatibility is important, DES is not that trivial to crack, and /etc/shadow is not supposed to be readable, but whatever: you're god damn prompted about this during the install!
:-)
In the top of that It looks like he doesn't not know much about debian, and the concept of freezing a developement tree (cf. his daemons paragraph).
In my opinion, the only valuable issue he raised, is those daytime, etc... ports opened by default. I think inetd and portmap should be in separated packages so that I can dpkg --purge inetd portmap right after the install
I'm using a woody at home, and It look likes they're working on it, netbase is being split into several packages.
Profesional? What does that mean? Due to the various ways which I've seen that word used, its lost all meaning to me. You mistakenly believe like so many others, that being professional is about appearance, whether that be dress or speech. Being professional should be about actions, outcomes, performance. Just because he used the word bullshit doesn't mean he's not professional, in fact it has nothing to do with it. I'd trust someone who uses the word bullshit as he did before some of the suit wearing, smiling bastards I've know who call themselves professionals.
Check out AbiWord.
Now that's very interesting. It's been a while since I've trolled, but please, someone clue me in here.
Is Hemos posting from the mid-Atlantic? Is the /. Cruiser an Andover funded time travel project? Did I ingest more than my usual amount of hallucinogens with my cheerios this morning?
Its way too early in the morning to be expected to deal with this kind of S.
F .sigs
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?
Why is it that Linux is expected to be 100000% secure out of the box, while MS products are expected to be 10000% Un-secure in the same light?
WTF is in the heads of reviewers? Debian has some issues... while any script monkey can remotely bsod any NT box from a fresh install.
Cripes, from their own statements of concern, Windows products should not be installed due to the instability and security holes!
Besides, when has ANYONE ever met a journalist that knows more than a pittance about what they write about?
Do not look at laser with remaining good eye.
The "average" user doesn't use UNIX. The "average UNIX user" knows at least "something" about security. When you first start using UNIX the first thing you find out about is security. Once they know something about UNIX, they start reading some type of document on how to secure a box.
Most of the time, these documents, tell the user to do eveyrthing that Kurt complained about.
MarNuke
MarNuke
I am reminded of the interview with the OpenBSD.. or was it NetBSD.. One of the BSD derivatives. Maybe BSDi... Don't recall the flavor, only remember the guy who started the effort to lockdown BSD for hardcore server use. He said that he main problem with the 'many eyes' approach Linux claims is that not everyone looking at Linux source is a security or programming expert.
Hey, I love Linux! My bigrig and laptop both run it. I just don't trust my server to it... as is.
(The suse_hard script in SuSE 6.4 does a pretty good job locking down the system. Tried it at H2K.. No root cracks.)
"And they said onto the Lord.. How the hell did you do THAT?!"
I used to be someone else. Now I'm someone better.
Real life is underrated.
does anyone have any more info on the status of the RBL? The author says RBL hasn't been working properly since 8/10. I find no references/complaints about that on Deja (which strikes me as odd, if there really is a problem). I use it on our mailer, and haven't seen any problems. There isn't any news posted on the RBL site. FUD?
Never meant half of the things I said to you. So you know, there's a half that might be true - G. Phillips
Ironically, however, the linux port of OpenBSD's ftpd was not vulnerable, because linux doesn't have proctitle, which is where the vulnerablity lay.
.profile up, instead of bothering the overworked sysadmin.
And IMHO, a world readable home directory is good for new users in a multi-user environment. That way, they can ask their colleages for help when they screw their
At any rate, it's not a security problem.
[from www.m-w.com:]
Main Entry: professional
Pronunciation: pr&-'fesh-n&l, -'fe-sh&-n&l
Function: adjective
Date: circa 1748
[...]
(1) : characterized by or conforming to the technical or ethical standards of a profession (2)
: exhibiting a courteous, conscientious, and generally businesslike manner in the workplace
This is the exact type of nasty response that the Linux community is known for outside (hell, even inside) Linux circles. No matter how many times we all plea that people keep their cool, there's always someone who just can't resist blowing it.
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.
Thats not going to help the newbies who are running every service and go on irc and get 0wned in a few minutes. Why enable everything when the majority of people don't use them?
Only the State obtains its revenue by coercion. - Murray Rothbard
One poster who's post I lost track of pointed out that Debian uses crypt instead of MD5. Crypt is compatible with other Unix's. This would provide a easier time migrating passwd files, and shadow files. Second, isn't MD5 just a checksum algorithim? I mean why not use blowfish which is actually meant to encrypt something. With little processser over head. Debian, could get a little more credibility if it would post a formal security review before each release. Something along the lines of 'hey we have done a security audit. Here is a log of the patch's we have applied. And measures we have taken.'
Cheers,
WFE
===========
I look at the list of services and running processes, and I'm not sure that I want to willy nilly disable anything I don't know exactly what it will break, or what it will do for me if I leave it in?
I guess what I'm looking for is a securing a new system checklist. anyone?
---
I did several installations, and I can safely say I don't terribly like the defaults Debian uses. The first thing I noticed was that while formatting the disk, Debian defaults to an enormous / partition and a swap partition. Unless you use quotas, a user can easily fill up the disk (/home/username,
What? So, after creating a separate /home partition, if a user decides to fill it, this still helps the others using the resource exactly how? If I have quotas, sure, I'll buy that. Just creating a separate partition however does not help in the least. It means I can still get e-mail while I can't create any new files in my home directory- unless the person is more determined, can manage to discern that there may be more than one partition, and fills the mail spool partition, too.
Semi-valid arguments for this might be that you can at least mount some of these partitions noexec or nosuid as a deterrent for casual users and lame crackers. However, this has nothing at all to do with the distribution, or DoS attacks. All Kurt is suggesting is that I should have more granular DoS. Yay. It's still a DoS, no matter how you cut it.
Security Portal, huh? Hrmm.
--Rana
I got mandrake this weekend and it would not even install! I'd rather have a few patchable security issues and an installed OS than this!
It crashed out at several Xwindows related packages, things like the glide drivers, but it let me cancel past those errors and continued the install. But it crashed some more during application setup (these were fatal error crashes and the installation crashed out of its runlevel)! It also kept asking for CD's that weren't included with the $30.00 Box package, who knew what I was skipping when I had to cancel through those entire discs. After all that, after finally getting the core installed, LILO wouldn't run at all! kept printing out "LI [carriage return]" over and over till I rebooted. what a depressing experience....
I was doing the install on a completely ordinary machine- a Celeron 400 with an 8x IDE CD-ROM (totally standard issue) and a riva TNT. I installed both Turbolinux 4.0.5. and Redhat 6.2 just fine, after I'd given up on the mandrake. Turns out Turbolinux is smooth and sweet, if a little sparse, and Redhat is the flagship badass distro, AFACT. Anyone else have problems with the Mandrake 7.1 installer? I think it may have been my partition scheme and that the HD was primary slave that caused all this, but Turbolinux and Redhat had no problems with the same setup. overall a big TWO THUMBS DOWN for mandrake!
Because this is a serious site and if a title was posted such as "Microsoft security problem?", it would just be too funny to post.
ayottesoftware.com
i dont know why he's complaining about the deafult install's partitioning scheme. /var and /tmp, and perhaps have /usr mounted over NFS - but who uses the default install anyway? these people probably do not have users to worry about! since we are not yet using LVM, this is the most efficient way to partition. you will never run into problems where you run out of space on one partition and have to juggle stuff around.
the default debian install has a swap and a huge / partition. i agree that this is a bad-thing if you have users, in which case thier home directories should be seprate, and so should
while it is not the way i do it, it is definitly the best choice for new users - the ones who would choose the default install.
X-Chat 1.5.7-devl fixes the issue mentioned. Perhaps the author could have looked at the home page and seen for himself.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Never did I say Linux is user friendly, or that Linux is right for everyone and their mother.
/. is a mindless drone.
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
This sig is false.
I don't think *any* of it is extremely serious, but I do hope to see netscape and lilo fixed in the distro, as they are very commonly used by people. Overall, the author overreacted, but he did have a valid point or two.
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.
This sig is false.
I somewhat expect to get flamed for this, but what the hell...
Having used Linux as a toy since the 2.0.0 kernel, and having played with Slackware, RedHat, Debian, and SuSE, I have seen strengths and weaknesses in all of them. It seemed like people were bickering back and forth between each other over really, really trivial differences. I mean, come on people, if you're truly qualified to be working as a SysAdmin, you should know your platform, WHATEVER platform you choose, so points like were mentioned are irrevelant. If you don't know your OS, get a different job. I don't consider myself a Linux admin, despite the fact that I don't use anything else, because all I do is play. I don't know how many slashdotters actually do admin, but I would venture a guess that it is significantly smaller than the total number of geeks posting. It's easy to install an out of the box Debian, RedHat, SuSE, etc, and set up server daemons, and call yourself an admin, but that doesn't make you any better than any idiot who "borrowed" his company's NT Server CD and installed it at home on PC on his cablemodem. Sometimes, it seems like _everyone_ has forgotten why admins are paid well, and that is because they haven't just taken a stupid course at some tech school and passed some lameass test somewhere. They learned through experience, by fixing problems, and by dealing with system crackers from time to time. It's brains that make a sysadmin work, not where the downloaded their OS or what small workarounds, bugs, implementations, etc, need changing.
I personally don't like Debian, I had problems installing earlier versions (2.0 range) that caused the console to stop accept console input for whatever reason, but if other people do like it, fine. If they want it as a server and know what they need/want to fix, let them have at it. It's not like they paid anything for it. I'll stick with my Slackware installation, where they assume that you will handle the little patching and downloading of new daemons. In the mean time, remember that they are the ones developing, and if you want it different, stop bitching and join 'em. If they're being 'leet, and don't want you helping with development, screw them and move to a different disto. Whatever you do, stop whining. It's annoying...
Enough of my rant...
IBM had PL/1, with syntax worse than JOSS,
And everywhere the language went, it was a total loss...
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!
Will I retire or break 10K?
"Yes. (Maybe I have too much time on my hands, but yes.)"
:P
I cannot believe that Debian users are expected to sift through the changelogs periodically to make sure no security problems have been found. Doesn't Debian make security announcements like most other distributions do??
I, unfortunately, have too little time on my hands.
If someone can tell me a more efficient way to keep up on Debian security, please let me know.
Otherwise, I'm starting to feel more secure in my choice of a non-Debian distro at home and work. (Apologies to all the moderators for daring to question the Holy Church of Debian, of course!)
PS: what's up with my original post being tagged [0: Flamebait]??? What was flamebait-y about it? Slashdot moderators are starting to look like a rabid pack of jack-booted Debian jackasses. GO AHEAD, I have plenty of karma to burn! How's that flamebait for ya!
Kurt and I go way back, and I know he knows what he is doing. I was talking to him just the other night and he was installing debian. Now, i dont know how long he had to write the article, but I feel that Kurt most likely did not have the time to write a proper article? Isn't this how all journalism works? "Get that aricle in here, it has to be up by tomorrow!". The author has to rush and unfortunatly has to rush it out the door.
Also, since when has the linux community been so quick to anger? An angered response is a sign of somthing to hide, and also starts flame wars.
Consider me a nobody then. People have made some of the kind of comments about Linux too but times have changed. Can't crack it if you can't find an install to crack. Most of the Unices have similar security methods and can be locked down to similar levels depending on what is installed. The real complaint should be what is installed and what doors are left open. It wouldn't do you much good to install the latest patched up ftp server and then put the root at / with write access. If we were talking about how Atheos hasn't been cracked then maybe your comment would be a little more valid.
holy crap, is that kurt guy an idiot. what a waste of slashdot space. some bogus 'security' article by a kiddie.
anyone with half a clue reading that article knows what im talking about. bitching default home directory is mode 755 but then bitching after he 'fixed' it, ~/public_html didnt work.
and the clincher... the one i completly stoped reading at... suggesting all installs should set a lilo password... HELLO? UNATTENDED REBOOTS? idiots...
Thanks
Bruce
Bruce Perens.
Well, MD5 is a one-way hash function yes, but why would you need a reversible encryption algorithm for passwords?
Password entry is one-way isn't it? It's not like you are using a retinal scanner to request access to decrypt the passwd entry using the data encoded into the backs of your eyeballs. =)
Also, MD5 is a more complex algorithm than 56-bit DES. A machine that can check 1,000 DES keys a second could only do about 100 MD5 hashes. Also with DES there was an 8 character limit on passwords, MD5 expands this to I think 127 (or maybe more?) Greater processor overhead is important here because it significantly increases the amount of time needed for a brute force attack.
-P
The idea of using a hash function like MD5 rather than bona-fide encryption like blowfish for passwords is that it's literally impossible to decrypt the result. The only way to get someones password is to run it though the hash function and see if the result matches their hash. Sure, someone can run random strings through the hash function and find a match with someone's password, but they'll only be able to get access to that account.
With an encryption function, if someone figures out the key, they could concievably decrypt everyone else's password. This doesn't mean blowfish is insecure for passwords though. When the crypt() function uses blowfish, it actually jumps through alot of hoops (like using your password as the encyryption key, that way you would need to know the password to decode it) so that the result is impossible to decrypt.
- My password is slashdot
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 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.
Go not unto/. for advice, for you will be told both yea and nay (but have nothing to do with the question)
Duh. Subscribe to the debian-security-announce list. If someone can tell me a more efficient way to keep up on Debian security, please let me know.
There's the list mentioned above. And duh, the Debian homepage itself lists recent security issues.
The Debian Security page gives the line to add to etc/apt/sources.list to configure apy to download fixed package.
Frankly, with Debian it is easier to follow security than other distros. You get an announcement of a fixed package, and then you just do "apt-get update; apt-get upgrade".
Thanks, that makes sense. I figured Debian must have a central source of security announcements (besides package changelogs).
PS: thanks for the patronizing "duhs", you're contributing to my already low opinion of Debian users.
PS: thanks for the patronizing "duhs", you're contributing to my already low opinion of Debian users.
I could just as easily say the same thing about you and non-Debian users for making such a ridiculous statment, as if this guy represents Debian users everywhere. Of course, then I'd be guilty of the same thing and this conversation could go on forever...
My other
The "duhs" are due to the fact that by just looking at the Debian front page, you could have seen that the security announcements are right there. How long could it take you to point your browser at the logical place to find out about Debian, the home page, and skim the page? Certainly less time than what you've spent reading and posting on /.
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!
WWTTD?
We needed quite a lot of work to get him avare that Mandrake does things somewhat differently... Now he does a similar mistake with debian. Fun. He will gett a lot of JB awards, if he goes on like this...
First I thought that he simply has something against Mandrakesoft, but now... I don't know, maybe he has no time to do a homework on distros he does not use. It is strange, when one knows that he is the author of the "Linux Administrators Security Guide".
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.
- I don't care if they globalize against free speech. All my best free thoughts are done in my head.
To recap: User home directories are ug+rwx with guid = uid. (umask=007) So all the files created in that home directory are only accessible to that user. Project directories are set g+rwxs, and guid=projectname. Now everyone in that project has access to that directory and every file that is created in that dir is automatically given the right permissions.
And the scenario where someone hacks into /etc/groups, well if they can hack groups, what's stopping them from hacking /etc/passwd?
KONala   >^..^<
Is there some page out there that shows you all of the security vulnerablities when first installing, and how to get rid of them?
/etc/apt/sources.list to include the mirror of your choice, then do "apt-get update;apt-get dist-upgrade" as root. Presto, all your packages are current.
New bugs are posted on the main page, or you can check out Debian's security page for more information. As for holes in default installation, welcome to the beauty of Debian. Edit your
You are right. I am stupid. It is far easier to search the web than it is to ask a simple question on slashdot and get flamed to hell and back for being stupid and asking questions. I am so glad you are here with your gigantic noggin' to point out the error of my ways, Eladio.
You can do a minimal install with most linux dists and probably with all the other bsd's which would probably lead to nothing being remotely vuln.
After you mount your swap and root partitions, I think the next action by defualt is to install the kernel, but alternatively you can select "initilialize another linux partition". It'll format the partition and then ask you where you want to mount it. Not very intuitive, but once you know what option to use its easy to set up seperate partitions for /var/cache or /home, et al.
Ok, well to start I have been running a server on the internet for 6 years and I admit that I am not always the best administrator, especially in terms of security updates. One of the risks of having an OS that can stay up for a year at a time is that you leave it alone since it is working. As time goes on and exploits are discovered it takes a special attention or a full time job to catch every security hole. As such one has to commend Kurt for making an effort to analyze security issues in ANY distro. As to his lack of understanding of DEBIAN's policy on backfixes, well perhaps it should be made clearer. I am a VERY experienced programmer and administrator in terms of Linux and I LIKE reading changelogs but I don't always get a chance to and a Novice is unlikely to know much about that. In any case Kurt made a mistake and he apologized gracefully, as opposed to the Debian response which was sort of harsh.
.99p16) there were good services available and THAT was why I began running it. Fear of being hacked was not what turned me on to Linux. it was the fact that I could take my little 386sx and make it a SERVER. SERVER implies SERVICE. Now I understand folks are trying to switch linux into a desktop machine, and for that maybe it is best to take on the macintosh model of NO SERVICES. Seems to me that could be a REALLY small distro compared to these massive cd sized ones. Even so eveyone wants a webserver, having your own nameserver is nice, a mailserver can be handy, an ftp server solves alot of problem, and hey its nice to have remote access, even if you jsut want your friend to help you on the machine, and so it goes.
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
I don't think "geeks" have been saying everyone has to do full testing of their entire distribution. That would defeat the purpose of having a distribution at all. You might as well run Slack. :)
Distributions are collections of software pre-maintained at a certain level. If you need more than that (for work or whatever) you add it yourself. If you are building a server, and you're paid to do it, you will do this ANYWAY. It wouldn't even have to be a UNIX server. This is the same as testing the brakes on a shipping vehical. You will do it on delivery, before use, and on a regular basis because money and lives other than your own are at stake.
If you care if someone breakes into your car or computer, it is your responsibility to take whatever steps you feel are sufficient to make sure that doing so is difficult enough. It is never impossible to break into anything.
Linux is both a desktop and server kernel, and Debian, RedHat, and others are also useful for the range of roles from tinker toy to big iron. The distribution maintainers and upstream developers have no requirements other than those they place on themselves. They are volunteers! Anything you want more than what you get, you have to buy or do yourself. If you want guarentees, be prepared to pay someone to get insurance against your guarentee. That's what car companies do.
So, yes, if you care enough if it works to your specs, test it yourself. If you don't care if it works, quitcher bitchin'.
A newbie won't be able to keep a system secure, Windows or Linux. His best bet is to hop on a system you can't get back to like AOL, use a text only mime incapable mail reader and use mosaic. That would be a reasonably secure environment for a newbie.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Yah. Generally you WANT the owner of the home directory to be able to rwx in it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Why is it that so many non-Debian people feel like they have to write about Debian's shortcomings anyway? It seems that every time I read something about Debian it becomes immediately apparent that the author is not actually a user of the system.
Just recently, Linux Magazine had an article about package managers. The author said he would talk about rpm's, deb's, and tgz's. Later in the article, (I am paraphrasing here) after a lengthy discussion of rpm's was a statement that "deb's probably work about the same way". In other words, the author never really uses them. Just once in a mainstream article I would like someone jump up and down and in bold print say "the recursive dependency checking of deb's, etc., is just outstanding". It is solid, reliable, and works.
Alas, here I am, not really an expert with rpm's. But my colleagues would seem to be at least as expert with rpm's as I am with deb's, and I can say that deb's seem to offer fewer problems than rpm's over the course of time. (I.e. I have never had a deb decide to break my copy of dpkg and then my copy of gcc leaving me with a machine on which I can no longer compile packages and for which I can no longer install a working compiler).
I use both rpm-based systems and deb-based systems where I work. My bias is obviously toward Debian (I am writing this). But I never - never - have to clean-install my Debian system.
OK, I am running out of wind. So I end with my small but fervent opinion: Debian is a good.
these people have gotten their grubby hands on a redhat cd - they're competent users of windows, however so much of an oxymoron you think that is - and they've installed it. then they've tried to use it... but the help and man pages suck if you don't have an understanding of the system as a whole when you start. i'm guessing here, but some people think that servers are necessarily more powerful machines, and may install with server options just because it's cool. dumb? absolutely. common? probably.
What I think you are saying is: people who don't know, should be protected from the danger they might get into."
hey - people who don't know what's out there should be protected from the danger they can put you into, smartypants. does that make more sense inside your little box?
The real point here is that "common knowledge" is a frightful way to decide what security defaults should be. A good configuration, as pointed out many times in this discussion, should be locked down from the start. If you want to turn something on, then you're going to have to:
Read about how to turn it on and how it works
Read about any security flaws it may have
Read about how these relate to the system
Think about it
You can't force the last point, but it would be relatively trivial to implement everything else. There's no reason that any distro of any OS should default to anything other than maximum security. If you want to repetively install something else, you should already have to have aquired the knowledge of what you're doing and the 'expertise' to automate that.
People like you make software suck.
[|]
The original issue arose because the article's author had seen security advisories about the versions included in the 2.2 release, and simply hadn't realized that the fixes for those problems had been backported. While it may show a poor understanding of the Debian distribution, it does not reflect poor administration practices.
*cough* *cough* hummmmmm ... heh.heh.he...bwahahahahahahahahaha!
RFC2119
Moderators, "-1 Flamebait" is not appropriate for the above post.
"When I first heard Daydream Nation it quite frankly scared the living shit out of me." -- Matthew Stearns
Yes, it is annoying that .bash_history gets created 644. I don't know why bash doesn't create it with a sensible mode to start with. (Although even here you can argue that this is illusory security - anybody could run 'ps' every second and get a complete log of the commands you run.)
.newsrc or .bashrc is particularly sensitive. If your account could be compromised by somebody who knew the contents of .bashrc, making it go-rwx is just security through obscurity. (If you do have secret stuff like database passwords, put them in a separate file and read them in.)
I don't think that's a reason to change default permissions for all files in a home directory; the answer is to fix bash. I don't see how
-- Ed Avis ed@membled.com
Secure system does not mean closed system. In almost every case the read permissions on the home directory does not have any effect on the security of the site. It actulla ofter gives more security problems not having the home directories readable for uther users that not having them readable.
It's nice that he apologized (just about unheard of kind of apology for a journalist) and that he posted a response to his website, but why not include it at the beginning of the article? It seems to be a sidebar (which looks enough like regular sidebar crap to be ignored by users) and the article has been just about untouched. Doesn't seem right to me. Nevertheless, still nice he apologized.
icqqm [ICQ:11952102]
No, not at all. They'll backport your bugfixes (not your new features) and call the package "aicq 1.1-2" or something similar.
The point is that you have a feature freeze for the software. You don't have to worry about having to upgrade libicq along with aicq; you know that the library requirements and all will stay the same.
-Matthead
-Matthead
This is just a suggestion for you guys so you can use your mod points more productively...
If the parent of a reply is off-topic, then moderating down the parent allows the thread to be offtopic. My reply to his off-topic was not off his topic, was it?
Just a suggestion...
"a powerful and unexpected ally..."