Demi M. Obenour:
> On 2020-10-04 19:55, Wietse Venema wrote:
> > Demi M. Obenour:
> >
> > Checking application/pgp-signature: FAILURE
> > -- Start of PGP signed section.
> >> On 2020-09-30 16:35, Wietse Venema wrote:
> >>> Demi M. Obenour:
> >>>> - If a message arrives via the SMTPS or submission ports, I
> >>>> want to replace the address part of the user-supplied From:
> >>>> header with the envelope From: header. This allows me to use
> >>>> reject-sender-login-mismatch to prevent users from sending messages
> >>>> with forged From: addresses.
> >>>
> >>> There are two parts to this:
> >>>
> >>> 1) Locking down the envelope.from.
> >>>
> >>> With authenticated smtp submission, the envelope.from can be
> >>> constrained by smtpd_sender_login_maps.
> >>>
> >>> With sendmail/postdrop submission the UNIX login name can be
> >>> overidden with "sendmail -f". There is no code in Postfix to
> >>> lock down "sendmail -f", and there is no 'plugin' interface that
> >>> could do this, either. I don't like the idea of adding complex
> >>> logic to the set-gid postdrop command to lock down "sendmail
> >>> -f". Doing the lockdown in the pickup daemon would be more
> >>> secure but has the problem that the 'reject' happens too late.
> >>
> >> I looked at the postdrop source code to see what locking down "sendmail
> >> -f" would entail. Checking that the current user can use `-f` seems
> >> to be just looking up the current username in an ACL, which postdrop
> >> already does for authorized_submit_users. Checking that -f was not
> >> passed looks to just be a string equality check, unless I am missing
> >> something. Of course, converting the same UID to a username three
> >> times is not a good idea performance-wise, but that can be fixed with
> >> some minor refactoring.
> >>
> >> Another option is to emit a good error message from sendmail, and then
> >> do the security check in pickup. If a user calls postdrop directly,
> >> the reject will happen late, but my understanding is that this isn't
> >> supported.
> >>
> >> Would you be interested in a patch that implemented either of these
> >> options?
> >
> > I think that the envelope.from lockdown should be enforced in pickup
> > or before pickup but not both. If it is both then the code in the
> > pickup daemon will be a NOOP. WHen code is usually a NOOP no-one will
> > notice when they break it.
> >
> > If a sender_login_maps feature can be implemented in postdrop
> > without giving an untrusted user control over the programn, then
> > let's try that.
>
> I would be willing to try, but I suggest we only support ?simple?
> maps here. Postfix supports a wide variety of map types, and I would
> rather not expose that much attack surface in postdrop. Furthermore,
> in all of the use cases I can think of, a simple policy is fine.
I have no idea what that means. Postfix has a separation between
lookup mechanisms (hash, pcre) and table-driven mechanisms
(access maps, smtp_sender_login_maps).
If you are thinking of skipping the Postfix dictionary API and
crafting your own table lookups, then that is definiitely
not going to happen.
> What about allowing everyone to send mail as themselves, and having
> a list of users who can send mail as anyone? That is what Sendmail
> provides. If a delimiter is specified in the configuration, it would
> be honored.
By default, a user can send mail as everyone, and that default
behavior cannot be changed. So the question becomes: what is the
behavior? I think it should behave like smtp_sender_login_maps,
because there is no reason to invent new behavior.
This means the search string is the UNIX username, and the lookup
result is a comma-separated list of things (usernames and/or email
addresses) that they may specify as the envelope sender address.
Your 'identity' mapping then looks like this:
/etc/postfix/main.cf:
local_sender_login_maps =
pcre:/etc/postfix/local_sender_logins
/etc/postfix/local_sender_logins
/(.+)/ $1, $1...@example.com
I.e. a user can send mail only if the envelope sender equals their
login name, or usern...@example.com. There will need to be a wildcard
pattern that allows all, as would be needed by a content filter
that re-injects mail using the Postfix sendmail command.
We just need to make sure that maps are opened after postdrop has
stripped the environment, set up signal handlers, and done other
steps against misuse. In that light, I'll move the existing
check_user_acl_byuid() call down, after the comment that says 'End
of initializations".
A note about etiquette: my posts clearly say "Reply-To:
postfix-users@postfix.org". Please fix your MUA and stop sending
your response to my personal email address.
Wietse
