Analysis of lookup map security model, making an untrusted mapper trusted
To make a long story short, the security model is strictly opt in on the
part of the map implementation, the code which cares (e.g.
src/local/alias.c) accepts the declarations of the mapper without question:
* An untrusted mapper commits suicide when informed that it is not wanted.
* A trusted mapper sets ->dict.owner.status = DICT_OWNER_TRUSTED
To make an untrusted (e.g. dict_tcp.c) mapper trusted:
* Don't commit suicide; and
* set dict_tcp->dict.owner.status = DICT_OWNER_TRUSTED
Relax, your hair is not on fire. But maybe, like me, you dislike
security theater; I find it confounds the discussion about real issues.
One thing: you're ignoring the possibility of privilege escalation.
If someone compromises the TCP map server (or the userID that it
runs as), then they can escalate privileges when a TCP map is used
for security-sensitive purposes. For example, they can execute
arbitrary shell commands if the map is used in alias_maps, and they
can write files with any UID that they return when a TCP map is
used by virtual_uid_maps.
Good to hear this is not coming back. It is largely misguided. In your
own builds, you are of course free to remove whatever safety features in
Postfix you don't find to your liking. If you share the changes with
others, please let them know that you're providing a modified version
with safety features disabled.