On 07/21/2015 01:52 PM, David Herrmann wrote: > Hi > > On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer <fwei...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel