11

Lots of solutions to this problem e.g. here and here but in order to decide which is best I'd need to know more about the security implications of each solution (or at least in general).

My context: I'm looking into running a rootless Docker/Podman Nginx container (on an Ubuntu Server 20.04 LTS host). Podman gives the following solution with this error message Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024).

Stuart Hodgson
  • 121
  • 1
  • 5
  • 10
    "Privileged ports" is a bit of an antiquated ("trust-based") security mechanism... note that Windows doesn't impose limitations on listening to low ports and manages to limp along semi-securely :) – gowenfawr Jan 03 '21 at 20:25
  • Found in the linked SO topic: http://www.staldal.nu/tech/2007/10/31/why-can-only-root-listen-to-ports-below-1024/ – Bergi Jan 04 '21 at 16:43
  • "Risk" to my mind is from fact that non-root user can impersonate or launch well known services. A server compromise in such scenario does not require privilege escalation to, for example, start SSH server for attacker to persist. There are other mechanisms to circumvent this (like using higher port) but if a third network allows only port based traffic (more common than you think), then attacker cannot use compromised server as C&C or for proliferation if he listens on port 5000 for SSH or incoming web requests. – RedBaron Jan 05 '21 at 04:39
  • ```authbind``` (http://manpages.ubuntu.com/manpages/xenial/man1/authbind.1.html) didn't work for me resulting in the same error for the Podman executable on Ubuntu (from man page: ```authbind is ineffective with setuid programs```?) – Stuart Hodgson Jan 07 '21 at 15:31
  • ```setcap cap_net_bind_service``` (https://stackoverflow.com/a/414258/4023953) also didn't work for me, same result as authbind (don't knwo why). Shame because to me it looks like the Linux best practice option when combined with limiting execution privileges using ```chown``` and ```chmod``` (limits privileged port exposure to a program and user). – Stuart Hodgson Jan 07 '21 at 15:36
  • ```iptables``` (https://stackoverflow.com/a/1762807/4023953) has a performance penalty and is essentially making a privileged port non-privileged which is very similar to the Podman solution above – Stuart Hodgson Jan 07 '21 at 15:40

2 Answers2

14

When you're using rootless Docker/Podman, the risks of allowing users to bind ports < 1024, generally depend on what else is happening on the system.

TBH the old restriction on low ports doesn't really apply that much any more, as loads of sensitive ports are over 1024 (e.g. Docker itself which will default to listening on 2375 or 2376).

There could be a risk where, for example, you had a sensitive service which you wanted to listen on a low port, and you were concerned that a user launched service would clash with it, or if you have multiple users who may want to bind a port on a host, and a malicious user could try to get access to it, before the "expected" user.

However where that's not the case, you're probably fine to allow this. Docker's recommended solution here is to allow this for all low ports, which is less fine grained than the podman recommendation you mention.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
12

It depends on your system.

If it's a multi-user system with multiple users able to run docker, you may fall victim to a race attack, where a malicious docker container is started when your legitimate docker is restarting for some reason.

However, it's worth noting that becoming root if you can access docker is generally trivial, and securing your docker installation is something you should consider if you use it in production.

So allowing docker to bind directly to port below 1024 may be a convenient feature worth the security trade off on a single user system - or you may decide that it's not worth it in other scenarios. One alternative is to set up a web server (e.g. nginx or Apache) as reverse proxy in front of the docker service. The web server will face the world, and can handle tls termination, while the docker doesn't need to care about certificates - and can listen on a unprivileged port.

vidarlo
  • 12,850
  • 2
  • 35
  • 47