-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/989/thoughts-on-ten-years-of-qmail-security/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
Funny how qmail used the concept of developing on a secure platform/framework then. Now, everyone recommends doing so for the same reasons. Why reinvent the wheel and at the same, reintroduce problems that allow developers to make the same mistakes over and over again.
The unreadable homegrown install infrastructure? God forbid DJB would sully his code by shipping it with an automake script.
... Sorry, just still bitter from that one time I had to try to grok that code because it was breaking on some system. I do admire DJB's design and coding practices, and I ran tinydns for the couple of years that I ran a name server at all. (I also ran qmail as my local MTA until I got bitten once too many times by the qmail-OSX fail-to-start race condition.)
The fact that it can conditionally compile certain things based on checking the output of the programs is awesome. Also, compile time is shorter and faster than using any configure programs. For example, on FreeBSD compiling the new modular Xorg 7.2, I bet more time is spent running configure scripts than is used to actually compile the individual modules.
DJB's homegrown install infrastructure is better than any other I have seen!
@Matt: Dude, most automake scripts are probably bigger than the qmail source code. Reducing code size is crucial.
As great a triumph as qmail is, it's as much a lesson in what not to do as it is in what to do. That is: Unless you are a super genius, do not write C code that receives input from across a privilege boundary; and no, despite what you think, you are not a super genius.
No, really, you are not a super genius.
You too, in the back. I can see you fidgeting.
Take the lessons of qmail with you into Managed Code Land, and you might stand a chance.
The real security problems with email are 'soft' security problems: spam, viruses, phishing and the like.
10 years ago you could set up qmail and walk away from it.
A few years later, there would be a virus outbreak and your /var partition would be out of space in an hour or two. Somebody would use your mail server as an open relay, so you couldn't get mail out to AOL users. Your users connecting via dial-up and DSL would find that they couldn't connect via port 25.
Around 2002, e-mail became a homeland security problem, and qmail didn't catch up. Dan Bernstein has the crazy idea that software is like a painting -- you finish it, get it perfect, and then it's done. He wouldn't maintain it, and he licensed it under terms that wouldn't let others maintain it.
Yes, you can install about 20 patches to get a qmail system that can survive today's environment, or you can use sendmail and postfix. Postfix has a similar architecture to qmail and has similar security and configurability benefits. Sendmail is a bear, but at least they keep it up to date, which you can't say for qmail.
For my part, the feature I care most about is that my mail gets delivered, without losing messages or the machine the mail server is installed on.
While DJB talked about security backed up by the impressive track record of qmail, Wietse coded and his code speaks for itself because it is actually readable and maintainable :)
1.
qmail has a better security track record than Postfix. I found a vulnerability in Postfix (when it was VMailer).
2.
Both qmail and Postfix derive their security from architectural decisions, and virtually every one of those architectural decisions originated (years prior to Postfix) in qmail.
I'll argue that qmail made a contribution to the field that Postfix merely popularized.
As for the architectural decisions, well I wouldn't credit qmail for them, they are the basic foundations for writing secure code and originated long before qmail (or Postfix) existed. DJB and Venema just took them to heart and followed those principles in their design. Both of them are laudable efforts. I am just trying to point out that while qmail is often touted as the ultimate effort in securing UNIX MTAs, Postfix delivers more functionality, has an equally impressive track record (give or take one bug), is still a live project and doesn't make so much fuzz about it. Incidentally I think the personality traits of the creators of each package are clearly reflected in source code and the evolution of each project. I don't want to offend either author, their contribution to the infosececurity community is immense.
BTW, being a "real dick" in public is hardly a valid argument in any discussion about security and even then Venema is probably the one I'd place last in the top-100 ranking of people that made meaningful contributions to infosec and have been "real dicks in public" at some point in time.
re: guninski
a bugs a bug, it doesnt matter that you suggest everyone wrap themselves in a security blanket, the fact of the matter is that the code could potentially do something incorrect, thats a bug in it. New Linux kernels no longer have a limitation on the number or size of arguments passed to a function, if that resulted in an argc overflow and your sudo got owned, would you call that a bug or that sudo should've had a reasonable expectation of environmental sanity?
The same cannot be said of Postfix.
I strongly disagree with your take on the novelty of the qmail architecture, and cite all mainstream software, and in particular all MTAs, released prior to qmail to defend my argument. Nothing (that anybody used) worked that way before qmail.
It's not even a mainstream design --- even among competent developers --- today. Compare DjbDNS to all other DNS servers.
I mention this to rebut your implied argument that DJB sat around and bitched while Venema kept right on coding. Bernstein clearly disagrees with you about the importance of SMTP TLS, IPv6, and milters. I'm glad he rescued me from BIND rather than wasting time on IPv6, and hope he'll take out SSH next instead of wasting time on DNSSEC.
Regarding TLS, IPv6 and milters: DjB may disagree with me and the rest of the modern Internet about their importance but guess what? we don't care, we expect MTAs to inter-operate with us, TLS zealots, IPv6 crazies and the spam filtering fundamentalists. This is the DNSSEC argument, only now you're on the other side of the fence.
I won't address the "who's got the bigger contribution" argument because it doesn't lead anywhere (specially when neither of us had contributed a fraction of a fraction of what Bernstein or Venema had). The point of my original comment was to point out that Postfix is still out there, it has an equally impressive track record, it is actively maintained and up to date with current technologies, its based on the same architectural principles of qmail and has not been given nearly the same credit from the security community.
Incidentally, I didn't know BIND has been replaced! OMG! when did that happen? Did I miss the party?
To argue that BIND hasn't been replaced, you'd have to argue that you'd rather deploy BIND9 than DJBDNS. I can see lots of arguments for Postfix over qmail. I can't see many for BIND.
I still think however that it should've been patched.
astute observation, id say that or synchronization issues, there's still a lot of both out there. Interesting method to get uninit variables in win32 applications is to watch out for functions that return 3 possible return values- error, okay, and buffer not big enough.
For instance, in the shell api the maximum path length is 260, however when using unicode api's its possible to have a path that is something like 34,000 wide characters leaving a slight disparity between the two. This means that a lot of the shell api will either return that third error value which is a positive value greater than zero and leave the buffer untouched- a condition that isnt explicitly check for in a lot of instances, or the path gets truncated which in turn leads to other interesting problems.
Name one OS that ships DjBDNS as its nameserver daemon. There, that's the pro-BIND argument: "It comes with the OS, I just need to configure it and I'm done"
I disagree with the assertion that Postfix's architecture clearly owes much to qmail. The fact is that the coders in question are both of academic mien, and were immersed intellectually in environments that could easily have led them to similar conclusions.
It seems pretty obvious that djb and Wietse both "get it", and have for ages.
It doesn't all have to be vi vs. Emacs.
Judging people by their contributions isn't "---- swinging" (I apologize for bringing that word into the discussion, let's kill it). What's Venema's long-term contribution? Specifically: what do I know now that I didn't know 15 years ago because of Venema?
Ivan, I can trace far more of my knowledge to you than to Venema.
From my perspective the conjunction of tcp_wrappers, SATAN, Venema's replacement to portmapper/rpcbind, TCT and Postfix contributed quite a bit to my interest in and understanding of practical information security matters. Anyway, I reiterate that my comment was not intended to elicit a swinging-by-proxy contest between Bernstein vs. Venema, both of whom would laugh about this entire blog post if they ever read it, but to indicate that in terms of security Postfix is at least on an equal standing with qmail
I never used SATAN, and in my scanner-developing days was never inspired by it. I was, however, inspired by Dan Farmer's "Improving the Security of your Unix System Break Breaking In To It", which I bring up as an example of a clear contribution.
I used wrappers and portmap3 extensively. I liked them. But what do I know now that I didn't know 15 years ago because of libwrap?
It's not insulting, offensive, or juvenile to judge that one person has made a greater contribution to software security than another. Probably both have made a greater contribution than I have. Sure, Postfix is as secure now as qmail has always been. That doesn't make their contribution equal: qmail appears to have taught Venema how to write Postfix.
"soft security" has everything to do with keeping my mail server safe and delivering messages. If a virus outbreak causes my /var/ partition to fill, that's a denial of service. If virus-infected computers are hammering my server so hard that the CPU is pegged or are making the head of my hard drive be in too many places at once, mail won't get delivered.
From my viewpoint as a sysadmin, it's all about how much time I spend dealing with exceptional events.
I got into qmail in the 90's. I loved the speed, the lack of buffer overflows, the modularity and the simplicity of configuration over sendmail.
I got out of qmail around the time netsky and mydoom turned up -- I switched to Postfix.
Was Postfix influenced by qmail? Yes! That's why I liked it so much. qmail ~was~ the best mail server of it's time when it first came out. If djb had kept maintaining it, or had allowed other people to maintain it, I might still be using qmail today.
True of any program, just that lots to know on BSD.