Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some thoughts on security after ten years of Qmail 1.0

blog.acolyer.org

Post reply on HN
Print view View original

71–80 of 123 posts

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

#71

Post by vidarh »

geocar wrote: post #29
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…

In contrast, almost nobody runs "exim plus some home-grown patches" or "postfix plus some home-grown patches". Having the correct architecture, and being able to rewrite the subsystems piecemeal means it is possible for users to experiment with new features organically[1]. That's part of why some qmail installations have features not available in any other mail server even today . Or to put another way, software puri…

I built a webmail system on top of Qmail back in the day, and I loved it. We rewrote component by component as our needs changed, but the beauty of Qmail was that we could rewrite component by component by sticking to very simple contracts between them and/or start with the Qmail components themselves that for the most part are extremely simple.

Our web frontend for example worked on top of a slightly modified Qmail POP3 server that relied on encoding some message state in the filename, so we need only scan the Maildir without opening the files to be able to e.g. get message read state, and various flags. We also added caching of metadata etc. The changes were tiny and self-contained, and added one extra non-standard command to the pop3 server to retrieve a message list with much more data. The design of Qmail let us start with just changing the pop3 server, and later some tweaks to local delivery, and know we could test those programs in isolation.

The flexibility of Qmail even got us to use it as a messaging middleware later coupled with tinydns - all the routing and retry logic made it very convenient and extremely simple to troubleshoot.

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

#72

Post by irundebian »

jerf wrote: post #62
LudoA wrote: post #28

Earlier quoted context omitted.

I read an article many many years ago explaining why software engineering can't be compared to mechanical engineering. I can't find it now, but one of its points of comparison was: if a nut isn't tightened enough on a bridge, you can tighten it a bit more -- turn the nut 3 or maybe 6 millimeters more. In software engineering, if you tighten the nut only 3 millimeters instead of 6, one of the bridge's endpoints now en…

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.

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

#73

Post by dchest »

1110001110 wrote: post #52

Interesting article, the only thing I fail to see how this is related to Meltdown and Spectre. Those are not simple 'bugs', it's multiple good features of modern processors combined to yield an attack vector. My opinion is that with any level of process problems like this will arise sooner or later just because the complexity is so high.

They are caused by performance optimizations with disregard to security (likely not intentional, but caused by not considering security aspects of optimizations carefully).

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

#74

Post by gkya »

jerf wrote: post #63
gkya wrote: post #61

Earlier quoted context omitted.

> You don't normally design with someone actively trying to destroy your building in mind. You do, actually. When designing a building, one considers many "attacks" it can be subject to, depending on the geography and demography of the site: what are the precipitation patterns like, what is the situation WRT sysmical activity, how is the soil, what is beneath, what is the crime rate in the area, what kind of animals…

'When designing a building, one considers many "attacks" it can be subject to' Your use of scare quotes is appropriate, because there is a qualitative difference between intelligently-driven and unintelligent attacks. Not to mention the intelligently-driven attacks when the attackers are manifestly more intelligent and skilled than the defenders! If computer security experts didn't have to worry about intelligent att…

I'm no security expert, but this article, and the FastCo article about NASA programmers suggest, at least to me, that computer security is a problem that emerges from incompetence in using tools and designing programs. We're yet to make the differentiation between hacking away amateurishly and building a software solution that will be commercially offered. A showerthough I just though is that only companies registered as software companies should be able to offer software commercially, with relevant regulations implemented on them including mandatory third-party auditing. This is not dissimilar to how any other sector of business works. I don't know US or EU, but in my country, for example if you want to sell foodstuffs, you need a certain certificate; if you want to produce foodstuffs, you need another certificate particularly for that purpose. So if you wanted to open a patissery, you would need a couple licences at least, you'd be subject to some control from the council's related unit, and there are institutions to handle any health problems or bad practices about this sort of commercial entities, however small or big they might be. I can't understand for the life of me why __at least__ the same level of standards are not in place for software that handles my money or my health data or my personal data. It hinders innovation? Well we saw what innovation can do both during the car boom and with Meltdown and Spectre, when nobody's actively, rigidly and methodically thinking about security and integrity.

WRT the house analogy, it's easy to extend that to "intelligent" attackers: intruders of any kind, e.g. robbers, animals, etc. Many install security cams, in my city (Istanbul) many condos have railings that protect the windows of the lower flats, we have locks on doors, alarms, barbed wires, safes, body guards, guard dogs etc., all to stop the intelligent attackers to actually using their intelligence. What's analogous in programming is using the best practices available, and the use thereof must be imposed on any critical systems (e.g. banks, medical institutions, communications tools [e.g. social media] etc.) by the governing bodies.

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

#75

Post by hursortue »

geocar wrote: post #39
oblio wrote: post #32

Earlier quoted context omitted.

> I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later... Can you elaborate?

Which part. The model? The article explained it well enough. I think of it as two main parts: (1) make fewer bugs, and (2) show your users the correct way to do things (which is the inverse of getting the correct requirements). Or are you asking what took me fifteen years to understand? Dan basically planned the whole thing. When the whole thing was too big, he would break off a piece that wasn't and develop it as a…

> learning how to read and write dense code

> and that's what I learned how to do

This is good code?

  for(i=b=0;it){r0(a);poop(f);R 0;}writer(f,kC(a),a->n);r0(a);if(!w)close(f);}if(b==r)R 1;q=0;o=0;a=ktn(11,0),v=ktn(0,0);}else{if((c-m)==10&& !strncasecmp(p+m,"connection",c-m))cf=p[s];js(&a,sn(p+m,c-m));jk(&v,kpn(p+s,e-s));}w=e=g=s=c=0;m=i+1;break;
  case' ':case'\t':case'\r':if(w&&!g)g=i;if(s==(e=i))++s;break;
  case':':if(!c)s=1+(c=i);break;
  case '/':if(!w)w=i+1;case '?':case '&':if(r>=(i+4)&&p[i+1]=='f'&&p[i+2]=='=')o=p[i+3];default: e=0;break;}}if(a)r0(a),r0(v);if(q)r0(q);R b;}

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

#76

Post by pjmlp »

oblio wrote: post #66
pjmlp wrote: post #64

Earlier quoted context omitted.

Most people also cannot afford to buy cars or houses in one go, yet regulations don't get ignored because of them.

There is almost no way we can compare cars and houses with the average CRUD software, in terms of damage they can do to a person. More than that, even in the case where damage does happen, most people would rate physical damage higher than non-physical damage, for example monetary loss.

Surely we can, it is all a matter of what CRUD software is managing.

There are institutions that rate what the damage actually means.

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

#77

Post by peterwwillis »

irundebian wrote: post #57
peterwwillis wrote: post #55

Earlier quoted context omitted.

Oh I'm sure it was bug ridden. But even if my feature introduced a security hole, you would have to find and exploit it, and it would then have to find a way to attack the rest of the app (which qmail makes difficult). It's kind of like using OBSD as your app platform. You can definitely make it insecure! But it's more secure by default than others, perhaps because of a lack of features, as well as very good security…

Are you sure that you understood djb's statement about the principle of least privilege? It's not about attacking the rest of the app, but about violating the user's security requirements.

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

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

#78

Post by ta76567656 »

geocar wrote: post #31
dcow wrote: post #23

Earlier quoted context omitted.

I completely agree. But the vendor situation looks very different for software. Imagine being the sole person responsible for migrating Linux from ip/nftables to ebtables. You don't know how your stuff will be used downstream. So you license it with text in all caps reminding people that your software is provided WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PU…

Those people who build oil pipelines should be able to sue whoever sold them the Linux distribution (probably Red Hat or IBM) which was vulnerable to that weird keepalive message. In that case, a judge (and perhaps a jury) could hear how Red Hat did everything they possibly could to protect from the vulnerability as evidenced by their ISO QA processes and the fact that everyone else was vulnerable to the same "bug" ……

I disagree, unless RedHat certified that the software they're selling is of safety-critical quality. If the oil pipeline company used, let's say, nuts and bolts that didn't meet safety requirements without checking that the parts met the requirements or being assured by the vendor that they did, I would say they're the ones liable and not the vendor.

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

#79

Post by mpweiher »

diafygi wrote: post #4

As we cast about trying to figure out ways to make software more secure or reliable, please remember that in other engineering fields (civil, chemical, mechanical, etc.) prioritizing safety and reliability is a _solved problem_. (1996) https://www.fastcompany.com/28121/they-write-right-stuff > It is perfect, as perfect as human beings have achieved. Consider these stats: the last three versions of the program — each…

How many people die because of software? How many die because of cars?

We could make cars that don't kill people.

We could make software that doesn't break.

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

#80

Post by jcranmer »

minikites wrote: post #45
jballanc wrote: post #35

Earlier quoted context omitted.

You over-estimate the degree to which the other engineering fields you mentioned have solved safety and reliability. Just to name a few: - Tacoma Narrows bridge: https://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge - Thalidomide: https://en.wikipedia.org/wiki/Thalidomide - Hyatt Regency walkway collapse: https://en.wikipedia.org/wiki/Hyatt_Regency_walkway_collapse - Challenger disaster: https://en.wikipedia.org/wiki/S…

The Tacoma Narrows bridge collapse happened 80 years ago, the Hyatt Regency was nearly 40. When did you last read about a software bug?

Phones that suddenly combust came out in 2016. The Big Dig ceiling collapse was 2006. Rana Plaza collapsed in 2013.

Serious engineering failures are still happening. Sure, the most famous ones may be decades old, but those aren't the only ones.

Post reply on HN