Slashback: Bindery, Locality, Gruviness 48
Why is there a lizard in my hard drive? chromatic writes: "The Protozilla team has responded to the earlier Slashdot article with answers to some common questions." This helps explain a lot of the questions raised in comments about why anyone would want or need to run CGI processes locally.Yet another win for documentation!
The ties that BIND make great cable-holders, too. fredpasteck writes: "LinuxSecurity.com has a FAQ from Paul Vixie that helps to explain some of the controversy and misunderstanding surrounding the ISCs creation of a 'members-only' mailing list. Perhaps the community was a bit quick in their assessment of what's going to happen?"
Do you feel reading Bugtrak makes it easier to talk to people? Speaking of BIND, to dispel any misconceptions which may have entered the minds of readers of this story (which cited the reaction of several Big Names to recent moves to restrict certain information about BIND), Kurt Seifried of Securityportal wrote to clarify:
Let it not be said that Bugtraq is a controlled substance.I actually interviewed Vince/Theo/Dragos/Greg via phone/email seperately, they didn't post those things to Bugtraq. Although they are all Bugtraq users ... hehehehe. (that makes it sound like we're all shooting up heroin or something).
Stop kicking, stop kicking! A nameless shirker writes: "More 'clarifications' from Linuxgruven CEO Matthew Porter can be found during a recent discussion on the Kansas Linux and Unix Users Association(KULUA) mailing list. His answers were very evasive to what were considered very straightforward (if direct) questions. The beginning of his involvement in the discussion can be found here with follow-ups linked from that message. Other discussion on this topic before and after Porter's response can be found near near the bottom of the following archive thread page.
Just wanted to make sure everyone could see how "clear" Porter makes things in his "responses" to the questions he is asked."
LinuxGruven. (Score:2)
Re:Secret Mailing lists are still evil. (Score:1)
As to the matter of money == evil, I'll not argue, regardless of my stance, but simply point out that the development of BIND9 has already been ``funded'' by a large group of corporations. I don't think that that funding goes simply for disks to write the source to.... ;)
Re:This secret mailing list is a good thing (Score:1)
Re:Secret Mailing lists are still evil. (Score:1)
Re:Secret Mailing lists are still evil. (Score:1)
On a personal basis, I'm more than happy to get the root servers and TLD servers upgraded before an official security notice out - these things are critical to the operation of the whole internet - no root servers, no internet.
Re:Secret Mailing lists are still evil. (Score:1)
2) the world runs off of money. since nobody seems to be interested in doing the work for free, someone will have to be hired and paid to maintain this mailng list.
3) it is common practice to keep vulnerabilities "secret" for a time in order to give the vendor a headstart in fixing the problem (e.g. RFPolicy [wiretrip.net]). this list facilitates that, and presumably will shorten the time between discovery of a security bug in bind and release to the public.
4) write your own OpenBind if you don't like ISC / Paul Vixie. quit yer bitchin.
Re:Secret Mailing lists are still evil. (Score:1)
What do you mean they are "supposed to?" Are they "supposed to" work for free? Who enforces the rule about what they are "supposed to" do?
KTB:Lover, Poet, Artiste, Aesthete, Programmer. There is no contradiction.
Uh.... Is it a contradiction that a self-described poet and programmer can't spell "internet?"
Bingo Foo
---
Re:This secret mailing list is a good thing (Score:1)
Now, the funny thing about this race condition, is that it happens regardless of when the information was privately discovered. It depends only on when the information is publically released. However, anyone who knows the knowledge before public release has an advantage - they can patch their systems and never worry about the race condition.
So keeping this information secret neither helps nor hinders the average sysadmin in his security task. The race condition always exists at the moment of public announcement, regardless.
However, buying this information early gives you a distinct advantage - you get a system which is less likely to be attacked.
So let's face facts: this is a ploy to raise capital, based on the unarguable market value of early information. It is not in the interests of the average sysadmin. It is in the interests of the seller and the buyer alone.
Re:Secret Mailing lists are still evil. (Score:1)
Re:This secret mailing list is a good thing (Score:2)
Has it happened yet? No. So, what's wrong with the current model?
Re:This secret mailing list is a good thing (Score:1)
Calm down, dude. (Score:1)
2. Yes, the bug notification through CERT will still happen. But not everyone who needs and deserves the information gets it at the same time. That's the whole point of having the "in-group". They've decided that some providers are more important than others, and that they have the right to make that determination, and to charge money for the information. I disagree.
3. As for arrogance, read the answer to the second question under "Member Selectivity". "We're real sorry if you lose a ton of money because you didn't know about a vulnerability. But it's not our fault that you're not important enough!"
I stand by my post. They're brushing us off like the criticisms don't matter without even considering them seriously. That bothers me more than the fact that I don't agree with the answers. I don't like their policies or attitude towards a community that has supported them in the past, and thus will not use their product. If you disagree, hey, what you run on your machine is your business.
Uhh, you didn't read the FAQ at all. (Score:1)
The list is purely an ADDITIONAL resource for those people running "if this dies then half the internet goes with it" DNS servers. It gives them a chance to patch up the mission-critical machines before every single script-kiddie in existence finds out how to bring them down. They ALREADY get this advanced notice; they have SINCE 1993! The only difference now is that the mechanism has changed.
EVERYONE who previously got their critical bug notification from CERT will CONTINUE TO DO SO. In THE SAME TIMEFRAME as before.
And as for you calling them arrogant, I think it's YOU who is arrogant. They're saying that if someone else produces a better product than they do (lets face it, BIND **IS** the dominant DNS server product - it's not boasting), that they will learn from it. And you're saying they SHOULDN'T learn from any better product that surfaces? You're just spouting flamebait.
BIND perspective (Score:3)
What is the purpose of the delay? To minimize the damage done by the vulnerability. Immediate disclosure means everyone's vulnerable until the news spreads, and even then, the only option is to disable the vulnerable program until a satisfactory fix is found (which is costly enough that many people will not disable it). Waiting until a fix is found still leaves people vulnerable while the news spreads, and subsequently while they evaluate the fix (a non-trivial task for critical systems), but it usually results in less overall harm. A logical next step is to inform, in confidence, the users most at risk prior to public disclosure. That, if we give them the benefit of the doubt, is all the ISC intends to do.
There are two problems with this strategy: It offends some people because it is inegalitarian and secretive; and the chance of a leak or independent discovery go up as the number of people in the know increases and time passes. If you hold an extreme version of the first position, you should argue that not even the program maintainers should get advance notice. This is a legitimate stance, but is by no means consensus among security researchers. Otherwise, you must admit that it's a trade-off, not a black-and-white issue.
Consider: Imagine you found a hole in a program you were using. Obviously, you would fix it locally before announcing it. Would you also get a review of your analysis from a trusted expert before disclosing? What if your friend were using it--would you tell him first? What if an organization you admire were at risk? It's a delicate balance.
I'm not defending Vixie's specific policy, I just want to point out it is not prima facie unreasonable.
Re:Sick of BIND? Me too. (Score:3)
Maybe BIND sucks, but it's still got my vote for now. I'd buy Mr Vixie lunch if he was ever in the area.
Vixie needs to lay off (Score:1)
Re:Uhh, you didn't read the FAQ at all. (Score:1)
* DISCLAIMER: This is a guestimation of charges at best only. No weight should be given on the amount of money received by ISC for access to the closed list. Any at all is too much.
---
You can't *buy* the info. (Score:1)
Even if I had a million US dollars and offered it to the ISC, I can't get onto the list - I don't run any DNS server critical enough.
Think about it - if you could join the list by simply paying for it, then the utility of the list DROPS TO ZERO. All you need is one cracker(or group of crackers) to get the cash and join, and then there is no longer any benefit in delaying notification because it is ALMOST CERTAINLY ALREADY PUBLIC. This service is for a select group of white-hats.
The fact that ISC collects fees from them is irrelevant; you are confusing implementation with motivation.
"ploy to raise capital" - they have to get money from somewhere. They are not-for-profit, so every cent they raise goes back into actually keeping the ISC functioning. And "market value of early information" only applies when that information is on the market. It's not - you *cannot* get the information using money alone.
Re:Secret Mailing lists are still evil. (Score:1)
Re:Secret Mailing lists are still evil. (Score:1)
On the other hand, if they silently fix security holes, leaving unwitting users at the mercy of better-informed kiddies, they will deserve the flogging they will get and it will be fork time. But nothing I read in that FAQ leads me to think that will happen (although the distinction between 100,000 zones and 1,000,000 seems arbitrary; how many companies do you think fall in between?). And if it does, the code will probably fork and it will be obvious which lifeboat holds the smart folks.
Boss of nothin. Big deal.
Son, go get daddy's hard plastic eyes.
Simple BIND fix (Score:1)
An open question to Paul Vixie and the Bind People (Score:2)
Sick of BIND? Me too. (Score:4)
Have a gander at djbdns [cr.yp.to]. This is software done right people.
Instead of upgrading to the latest version of bind because of yet another security hole, I decided to switch. And I've been happy ever since.
I've been searching for an alternative forever and I still can't believe I hadn't come across djbdns until someone on Slashdot posted it. There must be others like me.
Re:Secret Mailing lists are still evil. (Score:3)
ISC is trying to make money, yes, but it is a non-profit organization. They need the money to keep the global DNS system working. I assume you want that.
The most important port of an Open Source organization is that the Source is Open, which it is in this case. They are allowed to have private discussions just like anyone else, but anything substantive that is done to the code as a result of these discussions will be available just as soon as they've fixed certain critical nameservers.
If it weren't for this slashback this would be another slashdot hall of shame entry.
Someone would pay to be on this mailing list because anyone who runs a critical nameserver, or has customers that do so with their software will find it essential, no question. THAT is all.
Chris Morgan
Re:Secret Mailing lists are still evil. (Score:1)
Right, that's why RedHat is only doing things for people who pay them money, and not giving you an ISO you can download, burn, and install from.
This, I agree with. The whole reason that these lists are USEFUL is that they make vulnerabilities public right way, motivating vendors to issue patches ASAP, or at least workarounds.
--
They didn't listen to any criticism (Score:3)
For example: the answer that referred to (paraphrased) "if anyone else's software runs on 80% of servers and is as dominant as ours, then we'll take a lesson from them" smacks horribly of arrogance. Nah, couldn't be that anything but the most widespread software would be the best, could it? *cough*Microsoft*cough*Sendmail*ehem* Just because your software is on more machines than others, doesn't mean it isn't "full of holes."
Basically, the ISC is closing off the information loop for its own benefit and leaving the little guys in the dust. I could understand this better if it were a purely commercial entity, but their purpose is to serve the community, not just an elite, specially chosen group who is willing (and able) to fork over the money to be in on the secrets. This is not right and that is exactly why the community is in an uproar.
Anybody who's thinking of migrating to BIND9: if you're going to retool for the new version anyway, just switch to something else. Save the headache in the long run.
This secret mailing list is a good thing (Score:4)
Now, if a bug is found in BIND, do you really want every script kitty trying to make a name for himself to HACK ROOT on the ROOT NAMESERVERS for the ENTIRE INTERNET? Does this sound like a good plan to you? Wouldn't you rather, since the entire internet depends on them, that they get a chance to be patched up first?
I realize we're all in favor of open processes, but I think if anything this proves that in some situations they aren't appropriate.
As an example, have you ever left your front door unlocked? Would you prefer if someone told you personally, so you could fix it? Or would you rather they sent this information to the doorunlockedtraq mailing list to let you and everyone else know of the mistake you made, before you get a chance to fix it?
Securing Bind Script (Score:1)
http://www.antioffline.com/secbind.html
Lazy Mans Link [antioffline.com]
Delayed mail archive (Score:1)
I would hope for a bit more timely response than the 30-year + fudging type rules that predominate for government, however. How about a 30-day delayed archive? That way it gives them a chance to deal with vulnerabilities but the process is still transparent and dodginess can be made rapidly accountable. I suspect if you don't allow some secrecy for a matter as critical as this people won't use official forums at all, just send personal mail.
Re:Secret Mailing lists are still evil. (Score:1)
Really? That's hilarious.
Thank-you for brightening my morning.
BIND to djddns Migration Guide/ HOWTO (Score:2)
It's a free country.
tar zxf djbdns-1.04.tar.gz
cd djbdns-1.04
make
make setup check.
what a pain in the ass!
Switching from BIND to djbdns? Here's a howto: BIND-to-djbdns Migration Guide / HOWTO [flounder.net]
Re:This secret mailing list is a good thing (Score:2)
It is dicovered that certain models of the Acme "Gluon" door lock can be opened with wet spagetti.
This lock is used on lots of people's doors, and also on the door to the local army camps' armory, the local jail, and the town bank.
The lock makers, being responsible etc., want to tell people to change their locks, so they put an ad in the paper.
Now, the question here is, is it reasonable for them to quickly ring the camp, jail and bank, to tell them to change their locks straight away, and only then put the ad in the paper?
If yes, then the average joe has an insecure lock for a few dsays longer than strictly necessary, and has a risk of getting burgled if someone else discovers the spagetti trick.
If no, then there is a risk that the prisoners will escape, steal the guns, and rob the bank.
Re:Secret Mailing lists are still evil. (Score:1)
Re:This secret mailing list is a good thing (Score:5)
To rework your door analogy, suppose a particular model of lock had a problem. Perhaps it can be opened with a piece of uncooked spaghetti. Would you rather that everyone was told, or just those people "with a reason to know", such as locksmiths, process servers and baillifs? Plus of course, any incognito burglars who'd stumped up the change to get on the list. Remember that you still think your door is locked.
Re:BIND to djddns Migration Guide/ HOWTO (Score:2)
Now, more easily *machine* readable / writable I'll buy - autogenerating BIND zone files needs a little care, and parsing them is non-trivial. But to a human, which is easier to follow:
host.dom.ain IN A 1.2.3.4
which quite clearly tells you which type of record you're dealing with, or:
+host.dom.ain:1.2.3.4:0:4000000038af1379
which unless you're editing the damn things day-in, day-out, you're not going to remember which meaningless symbols correspond to which types of resource record.
The djbdns docs seem to advocate maintaining the DNS via the 'add-foo' scripts rather than editing zone files, secondarying is one of a variety of hacks ('run the axfr prog, filter the output in various ways, rebuild the database' or 'not our problem, use rsync'), and starting and stopping the daemons is non-standard.
The whole design simply doesn't work for me.
Regards,
Tim.
Re:Sick of BIND? Me too. (Score:1)
This is not true. You're not allowed to distribute modified versions, but as long as you don't redistribute the package, you're free to do with it as you please - according to Bernstein [cr.yp.to].
You're all missing the point (Score:1)
Don't want djbdns installed in /usr/local? Neither do I. I want it in /usr/djb (don't ask). So I take the hugely complicated step of running:
echoConfused by the datafile format? Think it's no good unless you spend all day looking at it? Well isn't that what sysadmins do? Once you're used to it (which doesn't take long), don't you think it's easier to add edit one config file and run make (copy and paste new entries if you still can't remember which symbol means "A record") than to edit at least N files where N is the number of subdomains for which you are authoritative, remembering to increase an arbitrary number and then possibly root about in another config file, placed in a totally separate directory?
Don't like the way djbdns does secondarying? Good. You aren't supposed to. The whole point is that you don't worry about delegating "masters" and "slaves" and waiting fifteen minutes for them to synchronise. You just ssh your cdb database on to each of your dns servers.
What? You meant that you REALLY NEED to support a secondary running bind? Well what's so hard about tcpserver 0 53 axfrdns anyway?
Don't like the licensing issue? Oh come on. So Dan gives you complete freedom to hack away and change what you like with the sole condition that you don't distribute modified binary packages. Oh how harse. Actually you might not have noticed but Microsoft don't let you pass Windows around (they call it privacy) but they don't let you see the source either, let alone edit it or distribute patches. Sounds like Mr Bernstein's licence is a bit less restrictive than others. Oh, wait, I forgot. It isn't GPL and any other licence is no good.
Folks you have to learn that the whole point of djbdns, like the whole point of qmail, is to redesign from scratch bad software. Is it so surprising that it ends up doing things differently? So it takes a while to learn how to use daemontools and ucspi-tcp. So the cdb files and their intermediates the data files can be confusing at first. Isn't this worth putting up with if it means you don't have to spend half an hour editing your configs, nearly as long again waiting for the server to restart (remember bind has to slurp everything into memory and it's unusable while it's doing this whereas tinydns just a new data.cdb as soon as it's available) and then running away with all your memory? Isn't it more in keeping with the unix tradition to have separate tools for separate jobs (tinydns, dnscache, axfrdns)?
Why don't you stop moaning (probably your bad moods are caused by incessant patching of bind) and open your eyes to the superior alternatives?
Re:Uhh, you didn't read the FAQ at all. (Score:2)
> The FAQ makes it absolutely, positively clear that EVERY SINGLE CURRENT AVENUE of bug notification will REMAIN IN PLACE.
Use you head.
First, current way of handling bugs isn't correct, or this member-only list would not be necessary.
Second, with a different channel for the most demanding users, do you beleive that the current avenues will become more or less performant ?
Third, by having a fee-based list for most important security issue, do you think that ISC won't have an interest conflict ?
Fourth, this FAQ is written from the sole point of view of ISC. You need to take its content with a grain of salt, particulary due to the biased questions.
Fifth, what I found most missing are the guarantees. For instance, if there was something like a way to get access to all the list archive automatically after, say 7 days, I would be much less suspicious.
Cheers,
--fred
Re:Sick of BIND? Me too. (Score:1)
This way you can still use documentation written for an unmodified system; you will know what changes you've made, because you made them. This is in contrast to vendors' helpful changes, which make it harder to write Djbdns in a Nutshell because each paragraph needs to detail the differences on half a dozen UNIX flavours, none of which is yours...
I find Bernstein's work very interesting. His style reminds me of Strunk & White (Rule 17, Omit needless words! becomes Omit needless features!). Things like the /service directory are very simple, elegant and useful. It's a pity that the licensing issue is going to get in the way. I can see his logic in eschewing the GPL if you already have all the rights he believes matter, but life would be easier if everyone just stuck with the good ol' GPL...
Re:An open question to Paul Vixie and the Bind Peo (Score:2)
The odds of a bug are not important to the equation: if in all of history there were one dangerous bug in BIND, it would still be important that it be fixed and the information be distributed to those important servers first.
To those who argue that security through obscurity is a bad idea: yes, it is. But it is also better than no security. To pubicise problems before a fix has been made is equivalent to taking an ad out in the paper stating that one's locks no longer function. Far safer to keep that information private and try to fix those locks ASAP, hoping that for a moment the insecurity will escape notice.
It's not as though DNS is a non-vital service which can be turned off in case of security flaws; rather, it must continue to run, even when it is known that it has problems. One can stop running irc if it has problems; DNS, OTOH, is essential.
Well, not really, but who remembers IP addresses anymore?
deez (Score:1)
Secret Mailing lists are still evil. (Score:2)
1)It is a clear attempt to make money by the ISC. They are supposed to develop Open Source software for the Interent. Money corrupts that.
2)More importantly, it is the secret nature of the list which is bad. The most important part of an Open Source organisation is that information is free. Here they are trying to make it secret.
Now, if you don't believe me, ask yourself this. Why would someone pay to be on this mailing list? What would they get out of it, that they couldn't get normally? I would guess that they get influence and information that gives them an unfair advantage. Secret Mailing lists for OSS related organisations are antithetical to the spirit of the OSS community, from which they benefit. That is all.
KTB:Lover, Poet, Artiste, Aesthete, Programmer.
Speaking of bind... (Score:1)
Comment removed (Score:3)
solution (Score:1)
Anyways I wrote a shell script for Linux, BSD*, for those lazy admins, or clue(lessler) admins, who don't know how to fix up DNS in a strong environment.
http://www.antioffline.com/secbind.html
Wow! (Score:2)
Security through obscurity (Score:2)
I'd always thought "security through obscurity" was a bad thing...
Re:if you read the q3 manual..... (Score:1)