Thorsten Kukuk via Postfix-users: > Hi, > > Several Linux distributions work on enabling NoNewPrivs > (https://docs.kernel.org/userspace-api/no_new_privs.html) system wide > during boot, which disables the setuid and setgid bits. > > For most applications in a standard base system, solutions to replace > setuid/setgid binaries already exist, or people are working on them. > One problem is postfix, which includes three setgid binaries. > > I have some questions and ideas about this: > > 1. postlog: What was the reason for hiding its socket in a restricted > directory and allowing access only via a setgid binary? Why wasn't the > socket moved into a readable/writable directory? > Ok, I think this is the most un-important binary. Logging on Linux is > mostly done via journald today, and some big Linux distributions don't > even set the bit.
The postlog client enforces a policy (who can call postlog). It also limits the number of concurrent requests by the number of postlog processes that an attacker may run (one request per process). With a world-writable socket, it would be trivial to DOS the postlogd. > 2. postdrop > The postdrop binary needs to be setgid maildrop to store emails in the > queue under /var/spool/postfix. It's only called by the sendmail > wrapper and communicates via stdin/stdout over a pipe. It's simple to > extend this to be called by a systemd socket, there is a minimal > invasive PoC: > https://github.com/thkukuk/postfix/commit/f4ecc0f02e82ac8c1e6d1823bafde05c699a29f8 postdrop enforces sanity checks on the queue file record stream; enforces the message size limit; enforces policies on who can submit mail and what envelope sender they can specify; it informs the pickup daemon of new mail; and it limits the number of concurrent requests by the number of postdrop processes that an attacker may run (one request per process). With a world-writable maildrop directory and pickup socket it would be trivial for any user to send mail as anyone, to DOS the Postfix queue, and to DOS the pickup daemon. > 3. postqueue > The postqueue command is only called directly by users, by mailq, or > by the sendmail wrapper. Or did I miss something? > The setgid is needed to access the sockets for the postfix daemons. > This is only required, since the ACL check for users is done in > postqueue and not in the daemons itself. Was there ever a discussion > to move that ACL check into the daemon (e.g. on Linux via SO_PEERCRED, > I think BSD has something similar). That would avoid the problem, > that an admin didn't setup the permissions correct or somebody finds > an exploitable bug in the setgid binary. postqueue enforces policies for who can view the mail queue or who can flush the mail queue. It limits what information may be sent to a Postfix daemon, and limits the number of concurrent requests by the number of postqueue processes that an attacker may run (one request per process). With a world-writable socket, it would be trivial to DOS the showq and flush daemons. That's off the top of my head. There may be more reasons. There's also some preliminary text on the security model in https://www.postfix.org/UNPRIVILEGED_README.html Wietse _______________________________________________ Postfix-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
