home tags events about login
one honk maybe more

benjojo posted 20 Jan 2026 19:32 +0000

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

benjojo replied 20 Jan 2026 19:36 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/NTJ9C1J1G18m467ztP

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 replied 22 Jan 2026 09:39 +0000
in reply to: https://berkeley.edu.pl/objects/12d53216-292c-4719-9253-19b0d0e28289

@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 replied 23 Jan 2026 18:50 +0000
in reply to: https://berkeley.edu.pl/objects/e7755e3a-76df-409a-b1bb-f2108da491a9

@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.

noisytoot@berkeley.e.. replied 26 Jan 2026 18:11 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/Rb6DHJ6716w2R11jBc

@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.

cks@mastodon.social replied 21 Jan 2026 03:15 +0000
in reply to: https://benjojo.co.uk/u/benjojo/h/68534172TctqTdZDXz

@benjojo My biased view is that well known ports are a good thing but privileged ports are a hack (BSD acknowledged it at the time, even). I think the idea of well known ports predates the BSD hack, although the BSD hack likely influenced what ports were assigned.

(These days, maybe it should all be implemented through DNS with a fallback to a default port. But then you have a default port and etc etc.)