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

101–110 of 123 posts

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

#101

Post by geocar »

viraptor wrote: post #96
geocar wrote: post #93

Earlier quoted context omitted.

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 m…

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

Then take a look at § 5.1 of the paper which gives a clearer example with which to draw the distinction.

Eliminating trusted code is what you're doing by decorating uncompress with pledge() with any capability to acquire resources; anything beyond stdio (or seccomp)

Minimizing privilege means focusing on finding some other argument for pledge().

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

#102

Post by joveian »

My favorite quote from that paper is "I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces."

As others have pointed out, one thing left out of the paper is not updating the software. qmail doesn't support SPF or other security extensions, which makes it useless these days without patches.

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

#103

Post by KozmoNau7 »

pixl97 wrote: post #89
KozmoNau7 wrote: post #85

Earlier quoted context omitted.

Odd how this 1930s brick building I'm in right now hasn't crumbled apart, or even cracked from settling to any noticeable degree.

I'm guessing you've not been alive long enough to see the required maintenance that has been preformed on said building. People tend to miss and ignore things that aren't part of their profession

I have bricklayers and carpenters in my friends and family, and I've been on the association board for the building, for the last 10 years.

So I know quite well what kind of maintenance is needed. We replaced the entire 6000sqm tiled roof last year, it was the original roof, 80 years old.

The maintenance needed on a brick building is fraction of what's needed on a wood building.

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

#104

Post by geocar »

irundebian wrote: post #100
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…

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 stri…

DJB is drawing a distinction between two designs in his paper.

1. Netscape had a "dns helper" -- which ostensibly could only do DNS lookups, is designed in the principle of least privilege.

2. Ariel Berkman's xloadimage implementation -- which implements every image loader as a separate filter in a separate process who can do nothing but input image data and output image data (in the "common" format), is designed around eliminating trusted code.

The former could (and did) suffer a bug that affected DNS lookups, and was convinced to perform all sorts of network traffic since, it by definition needed to perform network activity to do it's function, and it could access files like resolv.conf because again, it needed to do that to perform it's function. That it couldn't be exploited to "yield root" wasn't really relevant, since most people didn't run Netscape as root. It could read user files and ship them over the Internet which is frankly bad enough.

The latter, is what DJB is recommending.

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

#105

Post by irundebian »

geocar wrote: post #104
irundebian wrote: post #100

Earlier quoted context omitted.

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 stri…

DJB is drawing a distinction between two designs in his paper. 1. Netscape had a "dns helper" -- which ostensibly could only do DNS lookups, is designed in the principle of least privilege. 2. Ariel Berkman's xloadimage implementation -- which implements every image loader as a separate filter in a separate process who can do nothing but input image data and output image data (in the "common" format), is designed aro…

I would argue that both are designed following the principle of least privilege. Netscape haven't had the luck of having correct code. So what would have helped in Netscapes case? How would eliminating trusted code work in this case? Netscape has to do DNS lookups. I'm not sure if there was much more left to do as writing secure correct code. And of course you should prioritize writing secure correct code over implementation of least privilege. That doesn't make the principle of least privilege fundamentally wrong.

My opinion is that if you design your software securely threat modeling should result in the decision of implementing the least privilege principle and whether it makes sense and benefits (complexity vs benefit) or not. Of course you better eliminate trusted code so that there are less case where you have to get to these decisions. I assume that soon or later, there are situation, where you can't eliminate trusted code and it makes sense to implement least privilege.

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

#106

Post by geocar »

irundebian wrote: post #105
geocar wrote: post #104

Earlier quoted context omitted.

DJB is drawing a distinction between two designs in his paper. 1. Netscape had a "dns helper" -- which ostensibly could only do DNS lookups, is designed in the principle of least privilege. 2. Ariel Berkman's xloadimage implementation -- which implements every image loader as a separate filter in a separate process who can do nothing but input image data and output image data (in the "common" format), is designed aro…

I would argue that both are designed following the principle of least privilege. Netscape haven't had the luck of having correct code. So what would have helped in Netscapes case? How would eliminating trusted code work in this case? Netscape has to do DNS lookups. I'm not sure if there was much more left to do as writing secure correct code. And of course you should prioritize writing secure correct code over implem…

> I would argue that both are designed following the principle of least privilege.

Okay, but that's not what DJB means, and attempting to read his words with the definitions in your head, instead of the definitions in his head won't help you understand him.

I'm not going to humour an argument about mere semantics: For the purposes of this discussion they are not both the "principle of least privilege".

> So what would have helped in Netscapes case?

Writing the DNS client correctly.

DJB's point is that absolutely nothing else would help: You can't realistically put a box around buggy code as long as the code needs privileges.

And all that effort in writing that sandbox? A waste of time; fundamentally the wrong thing to focus on. Writing a DNS client is far less work.

> I assume that soon or later, there are situation, where you can't eliminate trusted code and it makes sense to implement least privilege.

That was what DJB assumed when he wrote Qmail, however he is now convinced that was wrong. His paper gives some explanation why.

If you can't eliminate trusted code, and it's still big enough you think there might be bugs hiding inside, you should rethink your design.

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

#107

Post by geocar »

vidarh wrote: post #71
geocar wrote: post #29

Earlier quoted context omitted.

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…

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/

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

#108

Post by jlgaddis »

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.

Yep. With a few exceptions, Postfix is the MTA I've used pretty much everywhere for the last 10 years or so.

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

#109

Post by vidarh »

geocar wrote: post #107
vidarh wrote: post #71

Earlier quoted context omitted.

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…

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 stood out) which made it great for Maildir's.

We also eventually used a small daemon to poll backends for which server a user belonged to, which had a mechanism to let us mark a user as "busy" so that we could balance accounts between backends by marking it as "busy" on both servers, sync the files over, and then mark it as available again without triggering errors anywhere. qmail on our MX's was modified to look up the right server that way.

The biggest changes were the POP modifications I mentioned. The ones I remember off the top of my head were:

* We modified qmail-local and the pop server to append size changes (from writing a new message or deleting one) to a file used to manage quotas. We appended rather than rewrite because it reduced the need for file locking (we took care to do single writes). We'd lock and coalesce the changes when the file got over a certain size.

* qmail-local was also changed to append the message size, and read-status to the filename. That let us avoid stat() calls for the files for the filesize, and opening and reading the files for unread counts etc. It was one of the first optimizations we did.

* Then we added a cache file that contained subject, sender, size, attachment status etc., for the web frontend, which would be dynamically re-generated automatically as needed.

* We made "+[something]" sort directly into folder "something".

* When we sold it I was most of the way through adding Sieve support to our qmail-local replacement.

These changes were quite small, and each successive changes lowered IO load dramatically (we handled about 2 million accounts before it was sold). Today, we could probably handle the IO load and storage we had with a single NVMe card...

The web frontend would try to use our extended POP3 command, and then fall back to scan the messages (and store a cache locally on the frontend) if it wasn't available, so we could use it as a POP3 client for other backends too. (The frontend is a story in itself - C++ CGI statically linked to shorted load time (it made a big difference at the time) and with "delete" only for really large allocations, to avoid wasting time on deallocation since we knew each process would at most live for a few seconds.

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

#110

Post by technion »

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?

qmail won't even compile on modern glibc without the errno patches - you must have at least some patching done.
Post reply on HN