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

91–100 of 123 posts

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

#91

Post by viraptor »

geocar wrote: post #53
viraptor wrote: post #44

I still don't get djb's distinction between untrusted and minimal privilege code. What he calls "not violating security requirements" is effectively a successful least privilege approach. Very few elements can become hacked without breaking security requirements. If you can't gain anything from hacking a piece of software, then why is it even executed? - it obviously didn't deal with anything the user wants. In his e…

Something that can respond to a DNS request can put whatever it wants in the response. If there's a bug in that program, then whoever controls that bug can put whatever they want in the response. The only protection from this is to make the code that does this as small as possible so that us human beings can convince ourselves that it is correct and that the risk of a bug that someone can control is zero (or as close…

Right. I think I see the difference he intends. I see this more of a practice -vs- theory issue. (Or in isolation/in deployment) In theory he can work on designing the correct version of gzip and there's a chance he'll succeed. But in practice, I'm still putting a seccomp/pledge-equivalent on it, because if he fails, I'm stopping local root escalation and potential lateral movement, which he doesn't seem to think are interesting consequences.

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

#92

Post by aplorbust »

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?

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

#93

Post by geocar »

viraptor wrote: post #91
geocar wrote: post #53

Earlier quoted context omitted.

Something that can respond to a DNS request can put whatever it wants in the response. If there's a bug in that program, then whoever controls that bug can put whatever they want in the response. The only protection from this is to make the code that does this as small as possible so that us human beings can convince ourselves that it is correct and that the risk of a bug that someone can control is zero (or as close…

Right. I think I see the difference he intends. I see this more of a practice -vs- theory issue. (Or in isolation/in deployment) In theory he can work on designing the correct version of gzip and there's a chance he'll succeed. But in practice, I'm still putting a seccomp/pledge-equivalent on it, because if he fails, I'm stopping local root escalation and potential lateral movement, which he doesn't seem to think are…

There's a point of subtlety remaining:

DJB isn't advocating against using seccomp or a pledge-equivalent.

DJB is advocating against stopping there.

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

#94

Post by Florin_Andrei »

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.

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

#95

Post by irundebian »

peterwwillis wrote: post #77
irundebian wrote: post #57

Earlier quoted context omitted.

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.

> 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 control flow isn't necessary, you just need to crash components.

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

#96

Post by viraptor »

geocar wrote: post #93
viraptor wrote: post #91

Earlier quoted context omitted.

Right. I think I see the difference he intends. I see this more of a practice -vs- theory issue. (Or in isolation/in deployment) In theory he can work on designing the correct version of gzip and there's a chance he'll succeed. But in practice, I'm still putting a seccomp/pledge-equivalent on it, because if he fails, I'm stopping local root escalation and potential lateral movement, which he doesn't seem to think are…

There's a point of subtlety remaining: DJB isn't advocating against using seccomp or a pledge-equivalent. DJB is advocating against stopping there .

That's definitely not how I understand this DJB quote:

> I have become convinced that this “principle of least privilege” is fundamentally wrong. Minimizing privilege might reduce the damage done by some security holes but almost never fixes the holes. Minimizing privilege is not the same as minimizing the amount of trusted code, does not have the same benefits as minimizing the amount of trusted code, and does not move us any closer to a secure computer system.

By "does not move us any closer" I don't believe he wants us to do it at all.

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

#97

Post by JdeBP »

geocar wrote: post #56
Fnoord wrote: post #54

Earlier quoted context omitted.

Ridiculous example: Qmail refused CRLF e-mails because the headers couldn't be read. It only accepted LF e-mails. In practice, this meant an e-mail client like Outlook did not work. It was solved by a very small fix with a few lines of C, but the patch I found did not apply cleanly either because it was for an older version or because of other patches, so I had to port it. This makes something like autoconf where you…

You have that backwards. Qmail rejected emails with bare LF because it was in violation of the email spec. https://cr.yp.to/docs/smtplf.html

Indeed.

* http://jdebp.eu./FGA/qmail-myths-dispelled.html#MythAboutBar...

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

#98

Post by irundebian »

geocar wrote: post #81
hursortue wrote: post #75

Earlier quoted context omitted.

> 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;i t){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':':…

It could be shorter if I spent some more time on it.

LMFAO

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

#99

Post by JdeBP »

b6 wrote: post #25
pmoriarty wrote: post #13

My biggest takeaway from qmail has nothing to do with security, but rather that excessively restrictive licensing, highly opinionanted/unusual setup, and unwillingness to collaborate on its development squandered its potential. If it wasn't for all that, we might well all be using qmail-based mail servers today, as qmail was really ahead of its time in so many ways. It was kind of like the Amiga of mail servers, back…

I think you're missing something if that's what you got out of qmail. The main idea I internalized was, if you find yourself making programming mistakes, take some time to write an API that does not allow you to make that kind of mistake and commit to using it everywhere. The licensing stuff, I'm not super clear on. If memory serves, DJB did not want to worry about bugs introduced by patches he'd never seen or approv…

The licensing stuff was simple: There wasn't a licence. Some people creatively misinterpreted M. Bernstein's page, explaining what one could do under the law in the U.S. as it stood even without a copyright licence, as a licence. But that was a misinterpretation.

* http://jdebp.eu./FGA/law-licence-free-softwares.html

Daemontools ironically wasn't weird at all, as evidenced by the fact that over the past almost two decades the daemontools world got us changes to softwares, all of those do not daemonize options that have appeared in that time as well as things like removing mysql_safe and other Poor Man's Dæmon Supervisors, that made it a lot easier to use those softwares with other service managers.

* http://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html#Promp...

Some of the things that people use instead of daemontools are not much less reliable. (-:

* http://jdebp.eu./FGA/daemontools-family.html

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

#100

Post by irundebian »

geocar wrote: post #53
viraptor wrote: post #44

I still don't get djb's distinction between untrusted and minimal privilege code. What he calls "not violating security requirements" is effectively a successful least privilege approach. Very few elements can become hacked without breaking security requirements. If you can't gain anything from hacking a piece of software, then why is it even executed? - it obviously didn't deal with anything the user wants. In his e…

Something that can respond to a DNS request can put whatever it wants in the response. If there's a bug in that program, then whoever controls that bug can put whatever they want in the response. The only protection from this is to make the code that does this as small as possible so that us human beings can convince ourselves that it is correct and that the risk of a bug that someone can control is zero (or as close…

That's a great explanation, but I still don't understand why he says that the principle of least privilege is _fundamentally_ wrong. I fully agree that POLP could lead to an illusion of security or doesn't ensure user's security requirements, but that doesn't make it fundamentally wrong. The correct point is, that you shouldn't over prioritize POLP over code correctness. Maybe he is just arguing against the very strict implementation of POLP I could also agree, but in general, I would argue that POLP is fundamentally true and necessary, but that doesn't mean you should implement complex fine-grained solution with a lot of administrative overhead.

As soon as you build non-trivial systems, you have to contain error propagation with POLP, although you are striving to build simple and secure systems.

Post reply on HN