Thorsten Kukuk via Postfix-users:
> And the question remains: why must this be handled on the client side
> and not on the server side?
This deserves a more detailed answer than previously given.
The difference is by making a socket world-writable it moves a
security boundary from unprivileged user territory into the Postfix
core.
Let's look a this from a damage-control perspective.
- With the present implementation, client-side enforcement of
policies (admission, data formatting, data content) happens in
code that runs with the attacker's privileges. The attacker cannot
modify the program flow because the program is set-gid; each
client process counts against the attacker's resource limit quota
which constrains the attacker.
- It is OK if client-side enforcement terminates (fatal, panic)
when it does not like the input. It does not have to recover
from parsing etc. errors.
- With the present implementation, server-side enforcement happens
in code that runs with 'postfix' privileges. If the program has
an error, it can do more damage than is possible with client-side
enforcement.
- For damage control purposes, I suppose that one could run
hypothetical user-interfacing services with a dedicated UID
(perhaps the one associated with the postdrop group).
- It may not be OK if server-side code terminates (fatal, panic)
when it does not like the input. t would have to recover
from parsing etc. errors. This totally changes error handling.
- But I suppose that systemd supports one-shot jobs and that it
can be told not to blindly throttle a service that is under
attack.
Moving enforcement from a set-gid program to server-side code is
not just moving the enforcement. It moves the security boundary
into the Postfix core.
And there still is the lack of constraints on how many concurrent
requests an attacker can make if they are not limited by process
quota.
Wietse
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
