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

[Lennart Poettering]

On Tue, 21.07.15 16:39, Florian Weimer (fweimer at redhat.com) wrote:

> On 07/21/2015 01:52 PM, David Herrmann wrote:
> > 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).
> 
> Thanks.  Would it make sense to fix this in some way, so that the socket
> sticks around?

I don't think that would be a good idea. If you restart a .socket
unit, then we really should do that, because the user asked us to do
so. The restart operation does not do anything besides closing the
sockets and reopning it with the new configuration. If the user asks
us to restart we should hence do that.

> > 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.
> 
> unconfined_t unfortunately has this right for port numbers larger than
> 1023, unfortunately.

We are working on hooking up the firewall with systemd units, so that
you can write firewall rules that apply specifically to certain
units. That sounds like a better way to lock certain services to
specific ports.

Lennart

-- 
Lennart Poettering, Red Hat