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

qmail doesn't need any patches

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

> 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?

to post comments

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.