[systemd-devel] Does socket activation block a TCP port for listening by other processes?

[David Herrmann]

Hi

On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer <fweimer at redhat.com> wrote:
> We have quite a zoo of services which listen on localhost, on a fixed
> TCP port, for use by local clients.  The canonical example is PostgreSQL
> on 5432/TCP, for the benefit of Java clients (which cannot use the UNIX
> domain socket).  This has the obvious issue that if a local attacker
> crashes the service, they can impersonate it by binding to the same port.
>
> Does socket activation reliably prevent such impersonation attacks?  Or
> is there race, say during systemd configuration reloading or service
> restarts, where systemd temporarily does not listen to that port?

This "race" *does* exist with socket activation. The sockets may be
re-created if the unit transitions between states (like restart).
However, this is only triggered by actions on the socket-unit, not the
actually activated unit. A crash of the activated service will thus
not trigger state-changes on the socket-unit.

Furthermore, we do not treat "occupying a resource" as security
mechanism. If an attacker has access to bind such a port, we do not
place restrictions to prevent that. Instead, you should place LSM
restrictions to prevent this. And please note, the actual activated
unit usually does *not* have rights to bind the socket. This is done
by pid1. So an attacker would require rights of PID1 for such an
attack.

Thanks
David