It is kind of funny that the first allocated port outside of the "Well-known" (aka below port 1024) range is just a random "network blackjack" entry at port 1025

Also worth reiterating that the concept of "well-known" is a incredibly stupid UNIX-ism that doesn't really deserve to exist today however some extremely fringe (and silly) cases around backwards compatibility (that are depending on authenticating based on a port number)

you can fix the stupidity by setting

sysctl net.ipv4.ip_unprivileged_port_start=23

There is some argument to set it just below SSH (port 22) to prevent some stupid service from being able to bind on to port 22, But anything above that should be fair game lifting this limitation stops you from having to give applications root when they start up, or bless them with some systems capability flag through the file system

@benjojo or you could pass the listen socket to them at startup from some privileged wrapper (xinetd, or systemd, or s6-tcpserver-sockedbinder, etc)

@wolf480pl @benjojo speaking of wrappers and well-known ports, I once discovered about the service assigned TCP port 1, and I'm still angry it never caught on.

@cvtsi2sd @wolf480pl ah yes but you see we have a modern day version of this, port 443 + ALPN ;)

@cvtsi2sd @benjojo
speaking of service names, I'm still mad that getaddrinfo() has the perfect API to transparently resolve SRV records and yet it doesn't, and also I don't know of anyone passing a service name to it

@benjojo The biggest culprit is NFSv3 and NFSv4 in lesser regards. v3 AUTH_SYS regards the UIDs you send as trusted if your source port is in the well-kown/Priviliged port range.

@benjojo How do you restrict which users can bind to certain ports in a better way? (I think it's possible with eBPF, but I don't know how exactly)

@noisytoot does it actually matter which users are binding to the ports?

I generally operate on the rule of thumb that security in a multi-used system is actually dead, if there is a compromise in one of the users, I just assume that root has been compromised as well

Obviously I am not running timeshare systems here or anything similar to that so your mileage may vary

@benjojo on a shared system it definitely matters, but even if you're the only actual user, one of the users being compromised doesn't necessarily mean that root is compromised (or you might as well just run everything as root)

@noisytoot

but even if you're the only actual user, one of the users being compromised doesn't necessarily mean that root is compromised

Yeah but you say a bit of an load bearing "doesn't necessarily" there, I think the only reasonable position to take on multi user systems over the years (at least where there are real stakes) is that a compromise have any user on a multi user system should be treated as a full system compromise. There are just too many variables and they are realistically to hard to verify/assure against, you can try and mitigate them, but assuming your tooling is in place, you should be able to blow away the machine and cycle any rights that box had on it.

(or you might as well just run everything as root)

It's important to consider nuance, just because I don't trust multi user boundaries does not mean that I'm going to actively give away surface for free, at the very least the multi user system permissions help surface bugs sometimes.

@benjojo

just because I don’t trust multi user boundaries does not mean that I’m going to actively give away surface for free

Exactly. It’s still worth restricting which users can bind to which ports just like it’s still worth using separate users for separate services, even if the security of multi-user boundaries is imperfect.

@noisytoot I think the difference between us is that you seem to think that me being able to bind on 443 as a 'random' user is a security risk, when I think not being able to is a bigger risk (because it forces various processes to be root (even if at just the stat) or blessed in a magical way)

@benjojo my preference would be a way of configuring exactly which ports can be bound to by which users (which I've been told is possible with eBPF), but I don't think CAP_NET_BIND_SERVICE is any more of a security risk than setting net.ipv4.ip_unprivileged_port_start to 0 (arguably it is more of a security risk than setting it to 23 though)