Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
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 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
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
On Tue, 21.07.15 13:37, 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? There are things like SO_REUSEADDR that allow privileged apps to bind to addresses/ports that something else is already listening on. Ignoring that, yes, systemd will listen on the socket as long as the .socket unit is up, and that might be longer than the service unit, even if it crashes. If you restart the .socket unit, then there will be window where the socket is not connectable of course, and something else might bind it, even without SO_REUSEADDR. Restarting a .socket window is necessary if you change the settings of .socket unit in any way, maybe to chnage which port or ip address you want it to listen on, or to change a socket parameter. Reloading/reexecing systemd itself will keep all sockets it is listening on open, it will pass the open socket fds from the old to the new systemd process without closing them in between. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
On 07/21/2015 01:52 PM, David Herrmann wrote: > Hi > > On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer 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
Re: [systemd-devel] Does socket activation block a TCP port for listening by other processes?
Hi On Tue, Jul 21, 2015 at 1:37 PM, Florian Weimer 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Does socket activation block a TCP port for listening by other processes?
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? -- Florian Weimer / Red Hat Product Security ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
