postdrop user maps

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

postdrop user maps

Pali Rohár
Hello!

Is there any option for postdrop which may be equivalent to
smtpd_sender_login_maps option used for sasl?

I have postfix submission configured with
-o smtpd_sender_restrictions=reject_sender_login_mismatch,permit
-o smtpd_sender_login_maps=hash:/my/file
to ensure that authenticated user can use only allowed MAIL FROM
addresses.

And I want something similar to enforce also for postdrop, when email is
not sent via TCP submission port, but rather locally via postdrop or via
/usr/sbin/sendmail wrapper. To ensure that logged unix user can use only
MAIL FROM addresses which are allowed for him.

Is there any such option?

And similarly, is there sender_bcc_maps option for postdrop, but based
on unix user which invoked /usr/bin/sendmail wrapper? E.g. for specified
(system/daemon) unix user ensure that every email is automatically
bcc-ed to some other email address (e.g. root@localhost) independently
of sender email address.

--
Pali Rohár
[hidden email]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Viktor Dukhovni
> On Jan 12, 2019, at 1:50 PM, Pali Rohár <[hidden email]> wrote:
>
> Is there any option for postdrop which may be equivalent to
> smtpd_sender_login_maps option used for sasl?

No, because there's no workable way to reject local submission, so
all you can do is accept and perhaps rewrite.  Also any such mechanism
would break .forward files and similar data flows where local submission
is used is process and re-inject external email for delivery.

If you have untrusted local users, on a machine that also accepts email
via SMTP, you'd need multiple postfix instances, with a null-client
used for local submission, and the real MTA using a separate instance.
In the null-client you could define a content-filter that rewrites the
envelope sender based on the uid recorded by postdrop in the topmost
received header.  You could even rewrite the From: header, but ideally
taking "Resent-From" into account, and rewriting that instead when
present.  I use "mutt", whose "bounce" feature resends a message to
a new recipient, while keeping the "From:" header, and adding a
"Resent-From".

> Is there any such option?

No, but you can apply content filters or milters to local submission.

> And similarly, is there sender_bcc_maps option for postdrop, but based
> on unix user which invoked /usr/bin/sendmail wrapper?

No, but content filters or milters can modify the message envelope.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Pali Rohár
On Saturday 12 January 2019 16:48:24 Viktor Dukhovni wrote:
> > On Jan 12, 2019, at 1:50 PM, Pali Rohár <[hidden email]> wrote:
> >
> > Is there any option for postdrop which may be equivalent to
> > smtpd_sender_login_maps option used for sasl?
>
> No, because there's no workable way to reject local submission, so
> all you can do is accept and perhaps rewrite.

postdrop already supports authorized_submit_users, so it already deals
with rejecting local submission.

So I thought that some allowed sender map could be supported by
postdrop and rejection would be done in same way as for option
authorized_submit_users.

> Also any such mechanism
> would break .forward files and similar data flows where local submission
> is used is process and re-inject external email for delivery.
>
> If you have untrusted local users, on a machine that also accepts email
> via SMTP, you'd need multiple postfix instances, with a null-client
> used for local submission, and the real MTA using a separate instance.
> In the null-client you could define a content-filter that rewrites the
> envelope sender based on the uid recorded by postdrop in the topmost
> received header.  You could even rewrite the From: header, but ideally
> taking "Resent-From" into account, and rewriting that instead when
> present.  I use "mutt", whose "bounce" feature resends a message to
> a new recipient, while keeping the "From:" header, and adding a
> "Resent-From".
>
> > Is there any such option?
>
> No, but you can apply content filters or milters to local submission.
>
> > And similarly, is there sender_bcc_maps option for postdrop, but based
> > on unix user which invoked /usr/bin/sendmail wrapper?
>
> No, but content filters or milters can modify the message envelope.
If you mean external content filters, I wanted to avoid using them.

And it is really possible for milter to get unix user who invoked
postdrop or sendmail wrapper? If yes, how? Because I thought that milter
operates on SMTP where is no unix user anymore...

--
Pali Rohár
[hidden email]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Viktor Dukhovni


> On Jan 12, 2019, at 5:31 PM, Pali Rohár <[hidden email]> wrote:
>
> If you mean external content filters, I wanted to avoid using them.

Sometimes you need to bring out the sledgehammer.

> And it is really possible for milter to get unix user who invoked
> postdrop or sendmail wrapper? If yes, how? Because I thought that milter
> operates on SMTP where is no unix user anymore...

Postfix supports non-SMTP milters.  The user's UID is recorded by
pickup(8) in the topmost "Received" header.

   http://www.postfix.org/MILTER_README.html#non-smtp-milters

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Pali Rohár
On Saturday 12 January 2019 17:38:23 Viktor Dukhovni wrote:

> > On Jan 12, 2019, at 5:31 PM, Pali Rohár <[hidden email]> wrote:
> >
> > If you mean external content filters, I wanted to avoid using them.
>
> Sometimes you need to bring out the sledgehammer.
>
> > And it is really possible for milter to get unix user who invoked
> > postdrop or sendmail wrapper? If yes, how? Because I thought that milter
> > operates on SMTP where is no unix user anymore...
>
> Postfix supports non-SMTP milters.  The user's UID is recorded by
> pickup(8) in the topmost "Received" header.
>
>    http://www.postfix.org/MILTER_README.html#non-smtp-milters
Ok. So milter needs to parse Received header and find UID, then convert
UID to unix user and implement postfix "map" logic (either hashmap or
external database lookup)...

Seems like too complicated.

Is there already such milter which can do that?


Meanwhile I decoded postdrop protocol and come up with more easier
solution:

I renamed postdrop binary to postdrop.real and implemented simple
postdrop wrapper which reads stdin, injects "R" command and pass it to
postdrop.real binary.

And email address for injected "R" command comes from:
postmap -q `id -un` 'regexp:/my/file'
(so my file is in postfix regexp format, like other postix configs)

I do not know how stable or documented is that binary postdrop protocol,
but seems that my wrapper is working fine and is really fast. Is there
anything which could be broken by usage of wrappers around postfix
binaries?


Would not you consider implementing this unix user bcc map for postdrop?
I think this could benefit and simplify implementation of feature "put
into my mailbox copy of every email which I sent". Because if you specify
different (envelope or email) sender, then it is hard (without above
content/milter filter) to check who really sent email.

--
Pali Rohár
[hidden email]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Viktor Dukhovni
> On Jan 12, 2019, at 6:02 PM, Pali Rohár <[hidden email]> wrote:
>
> Meanwhile I decoded postdrop protocol and come up with more easier
> solution:
>
> I renamed postdrop binary to postdrop.real and implemented simple
> postdrop wrapper which reads stdin, injects "R" command and pass it to
> postdrop.real binary.

Your untrusted users can invoke "postdrop.real" directly.  What's your
threat model?  Are you hosting users, or just sloppy software you can't
easily fix that emits the wrong envelope sender?

To enforce use of your wrapper, you'd have to move the setgid bit from
the real postdrop(8) to your wrapper, and make sure your wrapper is
sufficiently robust to not admit exploits.

The supported way to handle the rewrites you're looking for is via a
content-filter or milter.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Pali Rohár
On Saturday 12 January 2019 18:14:39 Viktor Dukhovni wrote:

> > On Jan 12, 2019, at 6:02 PM, Pali Rohár <[hidden email]> wrote:
> >
> > Meanwhile I decoded postdrop protocol and come up with more easier
> > solution:
> >
> > I renamed postdrop binary to postdrop.real and implemented simple
> > postdrop wrapper which reads stdin, injects "R" command and pass it to
> > postdrop.real binary.
>
> Your untrusted users can invoke "postdrop.real" directly.  What's your
> threat model?  Are you hosting users, or just sloppy software you can't
> easily fix that emits the wrong envelope sender?
Currently I'm using it just for adding additional bcc. Not for removing
or modifying email content. I know that postdrop.real can be invoked
directly, but it is not a problem -- just additional bcc is not added --
and it is not a security problem.

First thing for which I'm using it is storing all sent emails into
mailbox. I'm using more email clients and basically every one needs
IMAP configuration for ability to store sent email. Via this wrapper
option I do not need any IMAP, because 'R' command (REC_TYPE_RCPT) is
injected with local address and postfix deliver this local email.

Second thing is getting copy of emails generated by different running
software on server. Every software has its own specific configuration
and for sending emails can in most cases use /usr/sbin/sendmail binary.
And for monitoring purposes unmodified bcc copy of emails is sent to
admins (watchers). From time to time, it is needed to change bcc address
so it is needed to modify configuration of every software (need to
remember every one config file where it is etc...)
So easier solution is to let do this work for mail server -- postfix.
Configuration of bcc address is on one place, so it simplify
configuration and administration.

> To enforce use of your wrapper, you'd have to move the setgid bit from
> the real postdrop(8) to your wrapper, and make sure your wrapper is
> sufficiently robust to not admit exploits.

Yes, this is truth, but as I described above I do not need disallowing
usage or real postdrop.

> The supported way to handle the rewrites you're looking for is via a
> content-filter or milter.

So.. does it mean that postdrop binary protocol is subject to change? Or
just it mean that "preferred way is to use milter"? Because if postdrop
protocol is not going to be changed, there should not be problem, right?

--
Pali Rohár
[hidden email]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Wietse Venema
In reply to this post by Pali Rohár
Pali Roh?r:
> Meanwhile I decoded postdrop protocol and come up with more easier
> solution:

That is an internal protocol. Programs that depend on this
are NOT SUPPORTED and will break.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Wietse Venema
Wietse Venema:
> Pali Roh?r:
> > Meanwhile I decoded postdrop protocol and come up with more easier
> > solution:
>
> That is an internal protocol. Programs that depend on this
> are NOT SUPPORTED and will break.

Why not add the extra recipient on the SENDMAIL command line?

Example: install this as /usr/sbin/sendmail.

    #!/bin/sh
    exec /usr/sbin/sendmail.real "$@" [hidden email]

Why tinker with internal protocols, when you can use
documented features?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Pali Rohár
On Saturday 12 January 2019 18:55:32 Wietse Venema wrote:

> Wietse Venema:
> > Pali Roh?r:
> > > Meanwhile I decoded postdrop protocol and come up with more easier
> > > solution:
> >
> > That is an internal protocol. Programs that depend on this
> > are NOT SUPPORTED and will break.
>
> Why not add the extra recipient on the SENDMAIL command line?
>
> Example: install this as /usr/sbin/sendmail.
>
>     #!/bin/sh
>     exec /usr/sbin/sendmail.real "$@" [hidden email]
>
> Why tinker with internal protocols, when you can use
> documented features?
Hm... that you for a hint. This wrapper is easier to implement as
wrapper for postdrop.

I chose postdrop as I understood that this is the last application in
"pipeline" which has information about unix before email is put into
queue.

Are there any other binaries which calls postdrop? Or /usr/sbin/sendmail
is the only one binary which uses postdrop?

--
Pali Rohár
[hidden email]

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Wietse Venema
Pali Roh?r:

> > Example: install this as /usr/sbin/sendmail.
> >
> >     #!/bin/sh
> >     exec /usr/sbin/sendmail.real "$@" [hidden email]
> >
> > Why tinker with internal protocols, when you can use
> > documented features?
>
> Hm... that you for a hint. This wrapper is easier to implement as
> wrapper for postdrop.
>
> I chose postdrop as I understood that this is the last application in
> "pipeline" which has information about unix before email is put into
> queue.

It's almost the last program :-) The pickup daemon determines UNIX
info from the maildrop queue file owner, as it prepares the information
for the Received: message header.

Preparing the header in the pickup daemon is safer than doing it
in the set-gid postdrop program, because the time conversion library
relies on environment variables.

> Are there any other binaries which calls postdrop? Or /usr/sbin/sendmail
> is the only one binary which uses postdrop?

At this time, only the Postfix sendmail program depends on postdrop.

If you take the script solution, be sure to use "$@" (with quotes)
and not $* (without quotes).

Right: exec /usr/sbin/sendmail.real "$@" [hidden email]
Wrong: exec /usr/sbin/sendmail.real $* [hidden email]

The wrong solution mis-handles arguments that contain whitespace.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: postdrop user maps

Pali Rohár
On Sunday 13 January 2019 11:32:33 Wietse Venema wrote:

> Pali Roh?r:
> > > Example: install this as /usr/sbin/sendmail.
> > >
> > >     #!/bin/sh
> > >     exec /usr/sbin/sendmail.real "$@" [hidden email]
> > >
> > > Why tinker with internal protocols, when you can use
> > > documented features?
> >
> > Hm... that you for a hint. This wrapper is easier to implement as
> > wrapper for postdrop.
> >
> > I chose postdrop as I understood that this is the last application in
> > "pipeline" which has information about unix before email is put into
> > queue.
>
> It's almost the last program :-) The pickup daemon determines UNIX
> info from the maildrop queue file owner, as it prepares the information
> for the Received: message header.
>
> Preparing the header in the pickup daemon is safer than doing it
> in the set-gid postdrop program, because the time conversion library
> relies on environment variables.
Thanks for info.

> > Are there any other binaries which calls postdrop? Or /usr/sbin/sendmail
> > is the only one binary which uses postdrop?
>
> At this time, only the Postfix sendmail program depends on postdrop.

Ok.

> If you take the script solution, be sure to use "$@" (with quotes)
> and not $* (without quotes).

I know :-)

> Right: exec /usr/sbin/sendmail.real "$@" [hidden email]
> Wrong: exec /usr/sbin/sendmail.real $* [hidden email]
>
> The wrong solution mis-handles arguments that contain whitespace.
>
> Wietse

--
Pali Rohár
[hidden email]

signature.asc (201 bytes) Download Attachment