On Tue, 21.07.15 16:39, Florian Weimer (fwei...@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 <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?
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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
