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

[Florian Weimer]

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?

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

Good to know.

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

I'm stuck with SELinux and the unconfined_t user, so I don't think I can
set an LSM ACL on the port.

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

-- 
Florian Weimer / Red Hat Product Security