Risks and mitigations

Risks

I’m a C novice.

Most of the code is new, which means it has yet to be reviewed by a wide variety of readers and tested in a wide variety of production environments.

Some of this C novice’s new code runs as root.

The AUTH code is not new: it’s borrowed from patches that were expecting to run as qmaild and I’ve promoted it to run as root.

There are more moving parts.

Mitigations

They’re small, carefully chosen parts.

authup is several hundred lines of code that run as root so that checkpassword can drop to the privileges of the authenticated user. The code is well-worn, derived from qmail-popup and from SMTP AUTH patches in common use, and parses input using DJB’s stralloc library. If there’s a bug, it’s probably not unique to authup.

checknotroot is a couple dozen lines of new code. It calls getuid(). If the result is 0, it records the event in ALL CAPS, then exits rather than run any further programs. The code is so short that there probably is no security hole.

fixsmtpio is several hundred lines of new code. It parses input. It never gets run as root unless there’s a bug in checknotroot. The scope of a security hole is probably constrained to things the user could do with a full shell: delete, change, or copy off their own data. (Which is not nothing. If there is such a hole, I’ll want to fix it ASAP.) fixsmtpio is covered fairly well by automated tests.

qmail-qfilter-addtlsheader is a few dozen lines of new code. It writes its stdin to stdout, prepending a Received: header if certain TLS environment variables are present. The code is so short that there probably is no security hole.