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.

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

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.

Thanks,
Thorsten

-- 
Thorsten Kukuk, Distinguished Engineer, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Geschäftsführer: Stefan Gaiser, Jochen Jaser, Abhinav Puri (HRB 36809,
AG Nürnberg)
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to