Re: [exim] tainted data issues
Am 09.11.20 um 23:27 schrieb Heiko Schlittermann via Exim-users: We're open for suggestions. And intentionally we do not provide suggestions from our side here and now (this doesn't mean that we do not have ideas ;)) My thoughts I'll present here later. The only problem I have with tainting is the lack of documentation. Why is there no single page with just "Hey, external data is now considered tainted. This is how you handle this new stuff:"? Right now the information about tainting is spread all over the documentation so that admins who upgrade have to go through all of this. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
[exim] tainted data issues
Hello,
As many of you may have noticed, with the release of 4.94 we introduced
strict checks for the data Exim uses in expansions. This broke old
configurations that used "tainted" data.
Unfortunately the introduction of these taint checks wasn't communicated
very well, and as not all of you were able to test the release
candidates, we understand that this "breaking" change was unexpected to
a majority of our user base. (Or will be, in case of Debian, which
currently ships 4.92, but having 4.94 already in its backports.)
The traffic on the mailing lists indicated that there are issues with
these taint checks. A good share of the issues was caused by broken
builds. But another share of the issues arose due to suddenly broken
configurations.
Even configurations, simple like in:
begin transports
smtp:
driver = smtp
dkim_domain = $sender_address_domain
dkim_selector = 2020-08-25
dkim_private_key = /etc/exim/dkim/$dkim_selector.$dkim_domain.pem
broke, because the $sender_address_domain is considered to be tainted.
The currently proposed way to make this configuration safe, is to
introduce an additional lookup to verify the $sender_address_domain.
As for example in:
begin transports
smtp:
driver = smtp
dkim_domain = ${lookup{$sender_address_domain}dsearch{/etc/exim/dkim}}
dkim_selector = 2020-08-25
dkim_private_key = /etc/exim/dkim/$dkim_selector.$dkim_domain.pem
We understand that this introduces an additional level of complexity for
the configuration. And we're seeking for better ways, to balance between
a secure and a simple configuration.
We're open for suggestions. And intentionally we do not provide
suggestions from our side here and now (this doesn't mean that we do not have
ideas ;)) My thoughts I'll present here later.
Best regards from Dresden/Germany
Viele Grüße aus Dresden
Heiko Schlittermann
--
SCHLITTERMANN.de internet & unix support -
Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
gnupg encrypted messages are welcome --- key ID: F69376CE -
signature.asc
Description: PGP signature
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
[exim] Trying to understand when $local_part_data is set in ACLs
I thought I understood how to deal with the new rules for tainted data
in Exim, but evidently I don't, and I can't figure out what is going on
from the documentation and from Internet searches.
My starting situation is that we have some simple uses of $local_part
in SMTP RCPT ACLs. We also have a big list of all valid local users in
a file. My initial understanding of the documentation was that I could
add a ACL condition of 'local_parts = /our/userlist/file' and have
$local_part_data defined in the rest of that ACL statement, because we
had successfully done a lookup on $local_part. However, this doesn't
seem to be the case. I've also tried 'lsearch;/our/userlist/file',
following some apparent recipes on the Internet, but it also resulted
in $local_part_data not being defined.
I can definitely see that the condition passes, as I'm using a test
ACL like this:
warn
domains = +local_domains
local_parts =
log_message = local_parts test: $local_part -- $local_part_data
-- ...
When I use a straight file or a lsearch; in the 'local_parts = ...' bit,
I get log messages, and $local_part expands to what I expect it to,
but $local_part_data is blank in the log message (and elsewhere).
What am I supposed to do here? Does this require an explicit use of
${lookup}, not just a lookup in general? What ${lookup} should I
substitute here that has the same matching rules as listing a plain
file?
In this particular situation I can substitute a dsearch condition, and
both
local_parts = ${lookup{${lc:$local_part}} dsearch {/a/directory}}
and
local_parts = dsearch;/a/directory
work to set $local_part_data (for local parts that are already in the
proper case in the second one). This leaves me even more confused
about why 'lsearch;/our/userlist/file' succeeds but doesn't set
$local_part_data.
This is all on Ubuntu 20.04 with Ubuntu's version of 4.93.
Thanks.
- cks
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
