Viktor Dukhovni via Postfix-users:
> On Mon, Jan 05, 2026 at 02:23:49PM +1100, Viktor Dukhovni via Postfix-users
> wrote:
>
> > And of couse also specific master.cf services may override main.cf
> > settings with table references, and the custom tables might again not be
> > visible to proxyread, ...
> >
> > This is a tricky problem: without a robust configuration parser that
> > processes both main.cf and master.cf, but also recurses into nested
> > tables, ... it may be difficult to handle the general case.
It would be good to have that, but I don't think we can have it in
Postfix 3.11.
> A simpler approach may be to authenticate that requests for replacement
> table generation originate from a master(8)-spawned process, by having
> the client pass a file-descriptor that it (as root) opened during its
> pre-jail initialisation, or just a file descriptor that it inhertied
> from master(8) in the first place. The receiving service can check
> that it got a descriptor for the expected (root-only-accessible) file.
> The file could be one end of a pipe, and not even present "on disk".
A file handle to a resource that cannot be 'opened' by a 'rogue'
process. And this so that we can authorize a request to re-index a
table whose name cannot (yet) be identified with static analysis.
Making the solution for Postfix daemons only? That may be acceptable.
- There will be a few tables that must be converted proactively,
such as the authorization tables used by the non-daemon sendmail
and postdrop processes which must be able to receive mail while
Postfix is down.
- Mailman3 invokes postmap in 'create' mode; this should not need
any help from a privileged daemon.
- 'root' can still do 'postmap -q blah proxy:hash:/path/to/file',
as long as they can obtain a file handle to that same resource
that cannot be 'opened' by a 'rogue' process.
> If the request is to build a replacement for an indexed file that would
> have used a ".db" extension, both the source file and the ".db" file
> would have to exist and have matching ownership, and be in a directory
> that is not world-writable.
>
> With that, it may be safe enough to allow requests to generate a ".cdb"
> or ".lmdb" companion, for any extant ".db" file, when the request is
> from an authentic Postfix service.
>
> Admittedly, if a network like smtpd(8) has an RCE vulnerability, it
> might now be able to create ".cdb" and ".lmdb" companions to to
> extant ".db" files that are were not intended for use with Postfix.
> Perhaps that's a bridge too far.
If a hash:/path or btree:/path request matches the proxy_read/write
lists then it should be OK. If that request doesn't match the
proxy_read/write lists, then it needs to be authorized in some
other manner (file handle or otherwise).
> One might therefore limit the files to live in either the Postfix
> configuration or queue directories, or else match one of the
> proxy_read/write table lists. With that, one can perhaps
> reasonably expect to get a good compromise beteen coverage and
> compromise containment.
We could still try to 'flatten' the /file/name entries in mydestination
etc. match lists; tables listed in those files may be more likely
to live in a non-Postfix location.
Authorization by matching master.cf settings would require a new mechanism.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
