systemd/NoNewPrivileges + postdrop

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

systemd/NoNewPrivileges + postdrop

Matt Saladna

Hi all,

Bit of a pickle here with systemd in CentOS 8. Certain protective directives, such as DynamicUser= or PrivateDevices=yes implicitly sets NoNewPrivileges=true (systemd/systemd #12476). In turn that's blocking setgid with /usr/sbin/postdrop. postdrop hangs indefinitely unable to send its input to Postfix. As an example on CentOS 8 this breaks,

systemd-run -p PrivateDevices=true -p CapabilityBoundingSet=CAP_SETGID -p User=nobody -p Group=nobody /bin/sh -c 'echo "To: root" | /usr/sbin/sendmail -ti'

Consequently, it generates this:

postfix/postdrop[757666]: warning: mail_queue_enter: create file maildrop/58963.757666: Permission denied
sh[757663]: postdrop: warning: mail_queue_enter: create file maildrop/58963.757666: Permission denied
postfix/postdrop[754122]: warning: mail_queue_enter: create file maildrop/329008.754122: Permission denied

What's an appropriate workaround for this? Add postdrop to the list of SupplementaryGroups= for the service, open world write access for /var/spool/postfix/maildrop, or is there a better route? It's a PHP-FPM pool, which I'd like to tamp down as much as possible.

- Matt

Reply | Threaded
Open this post in threaded view
|

Re: systemd/NoNewPrivileges + postdrop

Viktor Dukhovni
On Thu, Jul 23, 2020 at 07:17:19PM -0500, Matt Saladna wrote:

> Bit of a pickle here with systemd in CentOS 8. Certain protective
> directives, such as DynamicUser= or PrivateDevices=yes implicitly sets
> NoNewPrivileges=true (systemd/systemd #12476). In turn that's blocking
> setgid with /usr/sbin/postdrop. postdrop hangs indefinitely unable to
> send its input to Postfix. As an example on CentOS 8 this breaks,

Local mail submission via sendmail(1) *requires* that postdrop(1)
be able to run setgid.  If you're going to prevent that, then you
need to submit email via some other interface, e.g. a sendmail(1)
replacement that submits email via SMTP.  This means that some
email may be lost when the SMTP server is down, but if that's
acceptable, then that's the way to go.

> What's an appropriate workaround for this? Add postdrop to the list of
> SupplementaryGroups= for the service,

No.

> open world write access for /var/spool/postfix/maildrop,

No.

> or is there a better route? It's a PHP-FPM pool, which I'd like to
> tamp down as much as possible.

Replace local submission with some IPC-based mechanism, e.g. SMTP.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: systemd/NoNewPrivileges + postdrop

Matt Saladna
> Replace local submission with some IPC-based mechanism, e.g. SMTP.

If my understanding is correct, submitting via SMTP would require credentials then to avoid anonymity of TCP unless there's a specific service that would work over a UDS so it can pass SO_PEERCRED along to Postfix.

Is there an existing solution that would then act as the following? Something to pass along auth data in the request without requiring ESMTPA.

program => "smtp" binary => unix socket => incoming postdrop manager => postdrop => Postfix

- Matt


On 7/23/2020 7:23 PM, Viktor Dukhovni wrote:
On Thu, Jul 23, 2020 at 07:17:19PM -0500, Matt Saladna wrote:

Bit of a pickle here with systemd in CentOS 8. Certain protective 
directives, such as DynamicUser= or PrivateDevices=yes implicitly sets 
NoNewPrivileges=true (systemd/systemd #12476). In turn that's blocking 
setgid with /usr/sbin/postdrop. postdrop hangs indefinitely unable to 
send its input to Postfix. As an example on CentOS 8 this breaks,
Local mail submission via sendmail(1) *requires* that postdrop(1)
be able to run setgid.  If you're going to prevent that, then you
need to submit email via some other interface, e.g. a sendmail(1)
replacement that submits email via SMTP.  This means that some
email may be lost when the SMTP server is down, but if that's
acceptable, then that's the way to go.

What's an appropriate workaround for this? Add postdrop to the list of 
SupplementaryGroups= for the service,
No.

open world write access for /var/spool/postfix/maildrop,
No.

or is there a better route? It's a PHP-FPM pool, which I'd like to
tamp down as much as possible.
Replace local submission with some IPC-based mechanism, e.g. SMTP.

Reply | Threaded
Open this post in threaded view
|

Re: systemd/NoNewPrivileges + postdrop

Viktor Dukhovni
On Thu, Jul 23, 2020 at 07:36:01PM -0500, Matt Saladna wrote:

>  > Replace local submission with some IPC-based mechanism, e.g. SMTP.
>
> If my understanding is correct, submitting via SMTP would require
> credentials then to avoid anonymity of TCP unless there's a specific
> service that would work over a UDS so it can pass SO_PEERCRED along to
> Postfix.

I don't see why that problem needs to be solved.  The SMTP server would
accept email only from clients on a local network, the sendmail to SMTP
software, would add appropriate trace headers.

Sure if some client broke out of the sandbox, and bypassed the sendmail
wrapper, speaking SMTP directly, its UID would be unauditable, but I am
not convinced this justifies a more complex design.

You could of course populate:

    /var/spool/ccerts/<username>/chain.pem

with mode 0400 individual certs for each authorised submission user, and
the sendmail wrapper could use these to authenticate to the SMTP
service.  Is it worth it?

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: systemd/NoNewPrivileges + postdrop

Matt Saladna

> You could of course populate:
>
>     /var/spool/ccerts/<username>/chain.pem

Thanks, that's perfect. Each PHP pool runs as a separate user and that'd provide equivalent accountability to SO_PEERCRED.

It's never worth it until you get victimized by StealRat or some other piece of malicious code that becomes its own SMTP service or originates locally. In the past you've laid out a very good case why tracking uids on the other end of a TCP connection is unreliable, so I've relied on ESMTPA or the sendmail binary to sift a few thousand users when things go south.

- Matt

On 7/23/2020 8:16 PM, Viktor Dukhovni wrote:
On Thu, Jul 23, 2020 at 07:36:01PM -0500, Matt Saladna wrote:

 > Replace local submission with some IPC-based mechanism, e.g. SMTP.

If my understanding is correct, submitting via SMTP would require 
credentials then to avoid anonymity of TCP unless there's a specific 
service that would work over a UDS so it can pass SO_PEERCRED along to 
Postfix.
I don't see why that problem needs to be solved.  The SMTP server would
accept email only from clients on a local network, the sendmail to SMTP
software, would add appropriate trace headers.

Sure if some client broke out of the sandbox, and bypassed the sendmail
wrapper, speaking SMTP directly, its UID would be unauditable, but I am
not convinced this justifies a more complex design.

You could of course populate:

    /var/spool/ccerts/<username>/chain.pem

with mode 0400 individual certs for each authorised submission user, and
the sendmail wrapper could use these to authenticate to the SMTP
service.  Is it worth it?