Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: comp.unix.programmer Subject: Re: MacOS TCP port permissions Date: Fri, 17 Apr 2026 14:04:20 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10rtel4$jrs$1@reader1.panix.com> References: <10rq7hc$1b1bt$1@dont-email.me> <10rqsr8$1bra1$1@dont-email.me> <10rt267$1eh57$1@dont-email.me> Injection-Date: Fri, 17 Apr 2026 14:04:20 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="20348"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com comp.unix.programmer:17077 In article <10rt267$1eh57$1@dont-email.me>, wrote: >On Thu, 16 Apr 2026 20:29:37 +0100 >Richard Kettlewell gabbled: >>boltar@caprica.universe writes: >>> Geoff Clare gabbled: >>>>boltar wrote: >>>> >>>>> I've just discovered that the current version of MacOS I'm running >>>>> (15.7.5) doesn't seem to enforce restricted TCP ports below 1024 and >>>>> a process without root permission seems to be able to open a >>>>> listening socket on any port it pleases. I'm using a standard user >>>>> account without AFAIK any special priviledges given to it. >>>>> >>>>> Perhaps MacOS never enforced this, anyone know? >>>> >>>> Apparently it changed in MacOS Mojave to match how iOS behaves. >>>> >>>> See https://developer.apple.com/forums/thread/674179 >>> >>> Cheers for that. Whoever "DTS Engineer" is he clearly doesn't >>> understand the reasons the restriction was put in in the first place - >>> ie that the services on low ports are the real deal and not maybe some >>> credential snatcher spun up by a user. eg, running a hacked version of >>> sshd on port 22. >> >>Aside from loopback, you never had that assurance anyway. >> >>In the case of SSH, the defence is host key verification, not which port >>it runs on. > >A hacked version of ssh could save or forward everything it receives. Not if it can't read the host key because it doesn't have permissions to open the file the key is stored in, and so it cannot prove to clients that it is the real SSH server (and users wisely refrain from further interactions with it when their SSH client spits out an error telling them this). >Crypto is only useful outside of the process, inside its irrelevant. "Crypto" in this case is about authentication, not just privacy. Part of the SSH protocol is mutually authenticating both the client _and_ the server using a cryptographically secured key exchange. There is an argument that this is irrelevant for a user who has never connected to that host before, and hence does not know what the host key _should_ be. That's a valid point, but this is not new: it has been known since SSH first arrived on the scene decades ago. The solution has generally been to publish the host public key widely. But running the server as "root" doesn't solve that problem, if "root" on the destination machine has been compromised. - Dan C.