Some thoughts on security after ten years of Qmail 1.0 • Hacker News Board

Re: Some thoughts on security after ten years of Qmail 1.0

#111

Post by JdeBP » Thu, Jan 18, 2018, 7:34 AM UTC

SwellJoe wrote: post #22

jlgaddis wrote: post #3

Damn, it's been nearly 20 years since qmail 1.03 was released (June 1998)? It sure doesn't seem like that long! I recall setting up qmail "toasters" on FreeBSD to do virtual hosting. Maybe I was just too much of a "n00b" but I remember it being a big PITA to get all the services to play well together. There was this hip new outfit named Yahoo! that was using it for their new webmail service, though -- as opposed to s…

While qmail has faded in popularity as it has been sporadically maintained by a random bunch of folks over the years, there has been at least one other MTA written by someone with excellent security cred, and that has been continually maintained and has an excellent security record. We don't really need to mourn what could have been with qmail; we have Postfix, and it's really very good.

Making a world-readable, world-searchable, and world-writable drop directory because of a decision to have no set-UID and set-GID executables in Postfix, even appropriate ones; failing to learn the even then well-known lessons of the batch job (at), UUCP, and printing (lpr) subsystems when it comes to world-accessible input directories; was a fairly large blot.

* https://cr.yp.to/maildisasters/postfix.19981221

* https://cr.yp.to/maildisasters/postfix.html

* https://groups.google.com/forum/#!msg/mailing.postfix.users/...

Re: Some thoughts on security after ten years of Qmail 1.0

#112

Post by geocar » Thu, Jan 18, 2018, 10:53 AM UTC

vidarh wrote: post #109

geocar wrote: post #107

Earlier quoted context omitted.

That's great. Do you still have details of it? I did a webmail "based on qmail" as well. It's still running[1] if you're curious. [1]: http://demo.internetconnection.net/netmail/

I have an ancient "backup" sitting somewhere. It was a provider called Nameplanet which provided vanity addresses (lastname.[assorted TLDs] for example), and morphed into Global Name Registry when we launched the .name TLD... The webmail system itself was sold to NetIdentity in 2001 or 2002... It had a few interesting details - we ran it on ReiserFS for the fast/efficient small file support (at the time it really sto…

Neat!

It's a shame that more people don't develop software with this kind of... change-for-purpose.

Re: Some thoughts on security after ten years of Qmail 1.0

#113

Post by pas » Thu, Jan 18, 2018, 10:54 AM UTC

cuckcuckspruce wrote: post #60

cageface wrote: post #18

Earlier quoted context omitted.

Follow the money. If people were willing to commit to a specification with the same level of precision as a civil engineering blueprint and then stick to that specification then you’d see a dramatic uptick in software quality, along with a dramatic uptick in price and time to develop. But since hardly anybody wants to commit to that kind of precise design or pay the cost we get what we have today instead. Come to SE…

There are software engineering fields where people commit to precise specifications - they typically interface with humans on some biological level (medical devices, etc), and they are quite expensive.

Of course, the same goes for military/infrastructure (self-driving trains) software.

And there are solutions for improving software safety, it starts by improving the process of software development. And for that there's at least one sort of official framework: CMMI.

(Even though DoD stopped requiring CMMI, but it still considers it a big plus, and companies for important stuff all use it.)

Of course, it'll be interesting to see what goes on with the F-35, as a lot of testing is now "skipped". (Sure, that is not software testing, but still, I can't imagine the software dev process is in a better shape after all these delays, cost overruns and probably still ongoing requirement changes.)

Re: Some thoughts on security after ten years of Qmail 1.0

#114

Post by pas » Thu, Jan 18, 2018, 11:00 AM UTC

irundebian wrote: post #72

jerf wrote: post #62

Earlier quoted context omitted.

Yeah, I've completely stopped buying this idea that software engineers just need to do what all the other engineers do to improve. Let me know when someone engineers an n-dimensional bridge. For that matter, let me know when your engineers have built something as complex as the AWS infrastructure, by which I mean, every single service they offer, by information content (something like Kolmogorov complexity). There ar…

I think I agree that software engineering is more complex than building bridges if you take two comparable project. But I don't agree that software engineering is more complex than building rockets which requires - besides a lot physics know how - also deep understanding of electronics and hardware systems. And if we look at the Ariane 5, the software engineers failed.

Rockets reliability is largely held back by their extreme trade off toward maintenance vs robustness. When you have to check everything and replace a bunch of things between flights, you're bound to miss something.

And that of course impacts the software side too, the rocket is constantly changing, the software has to change too, bugs are guaranteed.

Re: Some thoughts on security after ten years of Qmail 1.0

#115

Post by pas » Thu, Jan 18, 2018, 11:21 AM UTC

mulmen wrote: post #11

Joeri wrote: post #8

Earlier quoted context omitted.

The difference is that while you can’t make a bridge in your bedroom you can make an app. Should we forbid people from writing code without the proper certification? Should we close down the open internet and replace it with a regulated zone where only compliant software can be run? I agree that we need a higher standard of engineering in software, but I’m not clear on how to achieve it without draconian measures.

I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank. The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nucle…

> This is the difference in maturity between software "engineering" and real engineering disciplines.

That's a difference between contractors, people, groups, teams, projects, etc. It has nothing to do with the "disciple of engineering" software or otherwise.

I've seen shitty mechanical engineering projects, but hey, it was cheap, so I don't blame the customer! (We're fighting the shit someone churned out from the software side.)

No one expects to go to a mechanical engineer and ask for a new car, 4 wheels, blue color, 200 horsepower, and a week later "could you just make it 8 wheeled, thanks" and a week later "could you also make it so it'll be fast even when run on a mix of vomit and vodka", and so on, yet it's the norm in software.

And we somehow compare it to bridges, because a lot of software is "critical infrastructure".

Put the two together, and it's no surprise it seems that software engineering is not mature enough.

It simply means some kid (or a team of expensive consultants), who knew nothing about long term risks of the combination of attention fatigue and shitty UX, said yes. Lowest bidder and all that too. Or because this was mission critical it never occurred to the procurers that a UX guy/gal should look at it.

Re: Some thoughts on security after ten years of Qmail 1.0

#116

Post by peterwwillis » Thu, Jan 18, 2018, 2:40 PM UTC

irundebian wrote: post #95

peterwwillis wrote: post #77

Earlier quoted context omitted.

I don't understand what this has to do with my comment.

> it would then have to find a way to attack the rest of the app (which qmail makes difficult). It's not necessary to attack the rest of the app as soon as user's security requirements are violated. So if an attacker had been able to have an impact on confidentiality, integrity or availability because of your masquerading patch, user's requirements would have been broken. For an impact on availability controlling con…

Yes, you are right. An exploit is still viable even if it doesn't attack other parts of a system.

My point was that with a default of secure design, even small exploits added via plugins are better defended against than my alternative option, which was sendmail (i'm sure Exim wouldn't have been quite as horrible as sendmail, and Postfix wasn't quite mature yet).

Re: Some thoughts on security after ten years of Qmail 1.0

#117

Post by NoGravitas » Thu, Jan 18, 2018, 3:35 PM UTC

aplorbust wrote: post #92

pilif wrote: post #24

Something to keep in mind with regards to qmail is that it's extremely feature-poor and it never got features beyond its initial design goal. This makes it much easier to keep the bugs out, to the point that making software under such constraints is much more similar to traditional construction projects. I mean: Nobody ever tells you after you have built a bridge that they are now going to upgrade gravity to gravity…

"qmail itself is so feature-poor that traditionally, nobody was and is actually running qmail. Instead everybody is running "qmail" which is qmail plus some patches." I ran and continue to run qmail without any patches. The above quoted statements thus cannot be true. But maybe "nobody" and "everybody" are figures of speech?

So...are you running an open SMTP relay, or are you refusing to relay mail for your own users? Because I'm pretty sure that with an unpatched qmail, you've got to be doing one or the other.

Also, how are you dealing with backscatter?

Re: Some thoughts on security after ten years of Qmail 1.0

#118

Post by NoGravitas » Thu, Jan 18, 2018, 3:36 PM UTC

Florin_Andrei wrote: post #94

pilif wrote: post #24

Something to keep in mind with regards to qmail is that it's extremely feature-poor and it never got features beyond its initial design goal. This makes it much easier to keep the bugs out, to the point that making software under such constraints is much more similar to traditional construction projects. I mean: Nobody ever tells you after you have built a bridge that they are now going to upgrade gravity to gravity…

> nobody was and is actually running qmail I had Qmail running circa 1998 and I'm pretty sure it was vanilla, no patches. But after all this time I could be wrong. Anyway, shortly thereafter I discovered Postfix and that was the end of my relationship with Qmail.

In 1998, it was probably reasonable to run qmail without patches. By 2000 or 2001, it definitely wasn't.

Re: Some thoughts on security after ten years of Qmail 1.0

#119

Post by mulmen » Thu, Jan 18, 2018, 8:11 PM UTC

pas wrote: post #115

mulmen wrote: post #11

Earlier quoted context omitted.

I made a lot of bridges and cranes in my bedroom. They all failed spectacularly but GI Joe didn't seem to mind that the shear strength of a Lego pin was inadequate to support his tank. The difference is that I don't then promise a municipality that I can build them a bridge that can take their citizens across a river, even in case of a 100 year event. Or an early warning system that can save their citizens from nucle…

> This is the difference in maturity between software "engineering" and real engineering disciplines. That's a difference between contractors, people, groups, teams, projects, etc. It has nothing to do with the "disciple of engineering" software or otherwise. I've seen shitty mechanical engineering projects, but hey, it was cheap, so I don't blame the customer! (We're fighting the shit someone churned out from the so…

I think you're totally right about this but I also think it still speaks to the maturity of the industry and discipline of software engineering. We still have a lot of lessons to learn about building software, even in the cases where it is bid out like a bridge or built like an airplane. We just don't have as much experience under our belt. It's an oversimplification to say that software engineering is immature but I don't think it's wrong. I also don't think the current state of software engineering is even a bad thing or behind in any way, I just like to think we have a lot more to learn.

Re: Some thoughts on security after ten years of Qmail 1.0

#120

Post by pas » Fri, Jan 19, 2018, 12:05 PM UTC

mulmen wrote: post #119

pas wrote: post #115

Earlier quoted context omitted.

> This is the difference in maturity between software "engineering" and real engineering disciplines. That's a difference between contractors, people, groups, teams, projects, etc. It has nothing to do with the "disciple of engineering" software or otherwise. I've seen shitty mechanical engineering projects, but hey, it was cheap, so I don't blame the customer! (We're fighting the shit someone churned out from the so…

I think you're totally right about this but I also think it still speaks to the maturity of the industry and discipline of software engineering. We still have a lot of lessons to learn about building software, even in the cases where it is bid out like a bridge or built like an airplane. We just don't have as much experience under our belt. It's an oversimplification to say that software engineering is immature but I…

Who is we though?

I mean the problem in other fields were solved by a brutal trade off toward a draconian prohibition. You can't practice medicine/law/civil-engineering without a license in a lot of states/countries.

But of course you can give CPR, you can help your relatives sort out their pills. You can talk about laws/statutes/regulations with anyone.

So where would we draw the line? Maybe official/public procurement projects must have a process requirement clause, describing good engineering discipline (clear problem statement, analysis of the problem, analysis of aspects by the relevant domain experts [such as UI/UX, security, network, hardware, etc.], general specification, implementation plan with risks identified and testing methodology outlined, used development methodology [SCRUM, KanBan, whatever])?

This doesn't require setting up big and bureaucratic a trade guild, but if something bad happens we can look at the [pre]filed papers and determine who fucked up. The procurers, the experts, or the dev team.