qmail doesn't *need* any patches [LWN.net]

qmail doesn't need any patches

Posted Nov 3, 2007 21:04 UTC (Sat) by CyberDog (guest, #29668)
In reply to: qmail doesn't *need* any patches by charlieb
Parent article: Daniel Bernstein: ten years of qmail security

> Use qpsmtpd instead of qmail-smtpd.

Well... then you're not really using qmail's code, at least in part.  So any benefits inherent
in the codebase would seem a bit moot, no?

to post comments

qmail doesn't need any patches

Posted Nov 4, 2007 0:31 UTC (Sun) by njs (subscriber, #40338) [Link] (2 responses)

Esp. since qpsmtpd, though it's written in Perl, appears to be built on Apache -- so you have
another big chunk of C code talking to the network.  (Apache's C is far better than
traditional sendmail's C, but it still in no way comes close to meeting DJB's requirements.)

qmail doesn't need any patches

Posted Nov 4, 2007 1:23 UTC (Sun) by xanni (subscriber, #361) [Link] (1 responses)

qpsmtpd is not "built on Apache".  One supported mode of operation is to run it under Apache
on the basis that many sites are already running Apache anyway and it is well-understood and
supported, but qpsmtpd has always had and continues to support several other modes of
operation including running under djb's daemontools or even under xinetd.

qmail doesn't need any patches

Posted Nov 4, 2007 5:52 UTC (Sun) by njs (subscriber, #40338) [Link]

FWIW, I didn't mean 'built on Apache' as in 'runs as part of an Apache HTTPD'; Apache is in
part a very nice framework for writing generic server apps these days.  (Maybe this is
technically part of APR, I haven't followed where exactly they're drawing that boundary.)

On a further look, though, I see that you're right, when qpsmtpd is not running under httpd,
it uses a different home-brew network framework rather than APR.  I was misled by looking at
the first anti-malware plugin linked on their homepage:
  http://svn.perl.org/qpsmtpd/trunk/plugins/check_earlytalker
which contains a bunch of code using APR -- but it turns out that's because there are two
copies of all that code, one that works when being run under Apache and one that works with
the home-brew.  I don't know how typical this is of qpsmtpd's codebase, but it doesn't strike
me as The DJB Way either.

(If I were them, I'd consider just using Apache in all cases, even if it is a big hunk of
scary C that makes baby DJB cry, but I don't actually know what I'm talking about so *shrug*.)

qmail doesn't need any patches

Posted Nov 4, 2007 3:08 UTC (Sun) by charlieb (guest, #23340) [Link] (2 responses)

> So any benefits inherent in the codebase would seem a bit moot, no?

No. The only benefits which would be moot would be those which reside only in qmail-smtpd.
Logic 101, no?

qmail doesn't need any patches

Posted Nov 4, 2007 5:30 UTC (Sun) by CyberDog (guest, #29668) [Link] (1 responses)

The "benefit" alluded to here was djb's secure codebase.  As soon as your arrangement requires
[original codebase] + [random 3rd party codebase(s) tacked on], the security of the final
product becomes only as secure as the weaker of the two (or three or more) codebases.  It
could even be argued that a product which incorporates all the required features into a single
codebase, if written by even moderately competent programmers, could be less risky than
merging multiple products into one.

qmail doesn't need any patches

Posted Nov 4, 2007 14:04 UTC (Sun) by alankila (guest, #47141) [Link]

Interestingly, djb's paper talks about maintaining security expectations even in the face of
having to run untrusted, random codebases as part of secure application.

The basic idea is compartmentalization: for each component (especially those from a third
party) you should clearly define the input, the output, and set up access and resources
restrictions in which the component must operate. Finally, after it does its job, you
shouldn't trust it but do some validation to check the sanity of the result.

For instance, if the purpose of the component were to extract recipient address of the email,
then the component can only read the email, produce one string as response, not access
anything outside that email and have to run in limited time and memory. Once something comes
out, it must look like an email, for instance match the famous rfc822 pattern.

To achieve this, one might have to run untrusted components under a virtual machine and/or use
the operating system's primitives to constraint cpu, memory, available system calls, etc. I'm
not sure how well Linux can do these things, but the basic idea is that it should be possible
to run even completely random code safely provided that these relatively simple constraints
are worked out first.