Michael Tokarev via Postfix-users:
> 18.12.2024 01:12, Wietse Venema via Postfix-users wrote:
>
> > Just for the record, Postfix requires that a system behaves as
> > defined in POSIX (and ANSI C). That remains the baseline for what
> > calls are expected to succeed, and for what calls are expected to
> > fail.
> This is one of the possible views on this, - treating additional security
> measures as "breaking POSIX". Usually though, people think about this
> as additional layers to work with/within.
Let me phrase it another way. If one were to strace() all the
LEGITIMATE calls that Postfix can make in a POSIX environment, then
those calls must also succeeed or fail with capabilities. That is
my baseline. Postfix does not directly reboot systems, so that call
is not legitimate and it can fail.
**HOWEVER** when Postfix runs a non-Postfix code on behalf of a
user (example: a command in a .forward file) THEN IT WOULD BE A
REAL WTF if that command has different rights than the user. If
the command CAN do something that the user CANNOT do, then that is
a security hole (privilege escalation). If the command CANNOT do
something that the user CAN do, such as rebooting the system, then
that is broken. Again, that is part of my baseline.
(Also, when a Postfix process runs a child process on behalf of a
user, then Postfix must be able to terminate an errant child process.
That means, the Postfix process must temporarily impersonate the
user to send SIGKILL to the process group and reap the process exit
status.)
If you want to implement capabilities in Postfix then I have a few
words of caution.
Architecturally, Postfix encapsulates privilege operations with
setugid(), seteugid(), safe_open(). Managing this with capabilities
must be encapsulated similarly, so that it can be ifdef-ed out.
Said otherwise, just like Postfix does not have raw setuid(),
[f]chown() etc. calls scattered through the code, there must be no
raw capability management calls scattered through Postfix code.
It is easy to introduce major securitys hole in programs with
"exceptional" control flows, for example when a program "jumps"
into a signal handler, or when Postfix code returns through a
longjmp() call. It is easy to execute code with the wrong privileges.
Some may say that systemd already solves all process management and
privilege management problems, we just need a good SMTP and TLS engine.
In that case, it may be more productive to fork off a
Postfix-for-linux-only project and let it evolve separately.
Wietse
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
