On 10/5/20 10:51 AM, Wietse Venema wrote:
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).
There was a recent vulnerability in OpenBSD due to libc malfunctioning
in a set-uid-root program under very low resource limits. I would
prefer to minimize the amount of third-party libraries that are used
by postdrop. That said, another option would be to error out if the
resource limits are below what we consider a reasonable minimum.
If you are thinking of skipping the Postfix dictionary API and
crafting your own table lookups, then that is definiitely
not going to happen.
Indeed that would be a bad idea.
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.
Agreed. This also lets us use common code for both ACLs.
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.
That looks good. I do wish there was a way (other than allow
all) to express that Alice can send mail as al...@example.com,
alice+t...@example.com, alice+te...@example.com, etc. I might just
not know of such a method, however, and in any case that is not
related to the current project.
Is the code in smtpd_check.c a good place to start?
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.
Sorry about that. I was using "Reply All" instead of "Reply List"
in Thunderbird.
Wietse
Demi
