What is the correct way to allow binding of port 80 and 443?

Help
1

Hello , I am working on a web application which uses caddy. By default Caddy want to bind to port 80 and 443, but that is not allowed on NixOS. I could get around this by using the following command

sudo sysctl -w net.ipv4.ip_unprivileged_port_start=0

However after restarting, this value is reset to 1024 again. I guess this could lead to other security problems as well. So my question is, how can I make my own user or all users able to bind to port 80 and 443?

2

How do you start caddy?

AFAIK services.caddy.* can deal fine with priviliged ports.

https://search.nixos.org/options?channel=23.05&from=0&size=50&sort=relevance&type=packages&query=services.caddy

3

I start it with devenv, so it is run by my user (I suppose)

4

If you run it as your user, you shouldn’t be running it on ports below 1024.

Even though I do not know anything about devenv, but that it requires --impure and therefore is not an option for me, I think it should be possible to make it use some form of privilige (de-)escalation or capability settings and dropping.

5

wow I just did this for me a few hours ago for the first time (Synchronicity???). So, better take advice from more “PRO” “devoppers” :slight_smile:

but what i did was make the server use ports above 1024, and then i added firewall rules like:

iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports xxxx
and
iptables -t nat -I PREROUTING -p tcp --dport 443 -j REDIRECT --to-ports yyyy

where of course, ports xxxx and yyyy are the server’s http and https ports

6

Why shouldn’t I run it on ports below 1024?

But anyway, maybe I should just try to get caddy to run on port 3000 and 3001 or something.

Why is it not an option for you if it uses --impure?

7

Because --impure is a can of worms, which I do not want to open just to be able to fire up a database.

I have choosen flake as my main way to pin inputs rather than niv or anything else, for the fact that the pure evaluation gives some extra benefits. Using --impure then would just be absurd then…

8

Good question! Traditionally, those ports are reserved for root. The idea is that, in theory, when the system boots a non-privileged user may be able to start a service a bit more quickly than root, thereby reserving the port for their application before root has a chance to.

This would result in them being able to launch an ssh server or a web server, and take over the respective services. You can imagine how much of a security nightmare this could be if a malicious user does so. Hence, ports < 1024 are reserved for important services like httpd or sshd.

A lot of system security today relies on encapsulating services under different namespaces, which can do exactly the same thing as an unprivileged user, and are only prevented from doing so by this same security feature.

If you want to start caddy on low ports, I’d suggest giving it the capability (CAP_NET_BIND_SERVICE, probably what the NixOS module does too) to do so instead. This also protects caddy from being taken over by a different unprivileged user, which is probably better than running it on high ports.

That said, on a dev machine this sysctl may be totally valid. I’m not your mom, here’s the scissors, don’t tell me I didn’t warn you if you end up running with them: NixOS Search

2 Likes
9

May be there is something missing in the caddy package.
Should add like this:

systemd.services.caddy = {
    serviceConfig = {
      EnvironmentFile = [
        config.sops.templates."caddy.env".path
      ];
      SecureBits = "keep-caps";
      AmbientCapabilities = "CAP_NET_BIND_SERVICE CAP_NET_ADMIN";
      CapabilityBoundingSet = "CAP_NET_BIND_SERVICE CAP_NET_ADMIN";
    };
  };
10

indeed.

But another option to expand on this tho is NAT, you can setup some NAT rules for your firewall in the nix config to accept connections on port 80/443 and internally redirect to whichever port you want, or visa versa. This would deal with both problems at once without tainting

If not NAT you could also just port forward/redirect to 127.0.0.1

11

—no-pure-eval is “enough” and there was a PR recently that tried to get rid of the impurity entirely.

However AFAIK it is only needed to get the current working directory in order to set the DEVEN_ROOT env variable.

12

I am aware that things changed in the nearly 2 years since my post.

It still is not fully pure. And despite me knowing what the impure part is used for, it doesn’t change, that the mere existence of --impure or --no-pure-eval can cause havoc on improperly written import nixpkgs {} stuations. Those are not always under your control.

As long as devenv is not usable without pure evaluation, it is simply not an option for me, and I will remain concerned about this fact.

I appreciate its value for other poeple though.

1 Like
13

Ah please excuse I missed the date on your reply.

1 Like