Analysis of lookup map security model, making an untrusted mapper trusted

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

Analysis of lookup map security model, making an untrusted mapper trusted

Fred Morris
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.

Based on past reception I have no intention of continuing the discussion
here, if you have issues with the analysis you're welcome to open an
issue.
https://github.com/m3047/trualias/blob/master/install/table_security_analysis.md

--

Fred Morris



Reply | Threaded
Open this post in threaded view
|

Re: Analysis of lookup map security model, making an untrusted mapper trusted

Wietse Venema
Fred Morris:
> Based on past reception I have no intention of continuing the discussion
> here, if you have issues with the analysis you're welcome to open an
> issue.
> https://github.com/m3047/trualias/blob/master/install/table_security_analysis.md

I'm not going to argue with this. Instead, I will take a well-deserved beer.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Analysis of lookup map security model, making an untrusted mapper trusted

Wietse Venema
Wietse Venema:
> Fred Morris:
> > Based on past reception I have no intention of continuing the discussion
> > here, if you have issues with the analysis you're welcome to open an
> > issue.
> > https://github.com/m3047/trualias/blob/master/install/table_security_analysis.md
>
> I'm not going to argue with this. Instead, I will take a well-deserved beer.

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.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Analysis of lookup map security model, making an untrusted mapper trusted

Viktor Dukhovni
In reply to this post by Fred Morris
On Fri, Feb 21, 2020 at 01:01:45PM -0800, Fred Morris wrote:

> Based on past reception I have no intention of continuing the discussion
> here, if you have issues with the analysis you're welcome to open an
> issue.
> https://github.com/m3047/trualias/blob/master/install/table_security_analysis.md

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.

--
    Viktor.