Re:Dear Linux, Privileged Ports Must Die
by philsnow on Thursday September 01, 2022 @01:11AM
(#32672256)
> There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner
True, but you can also proxy through a named unix domain socket on the filesystem and control access to it that way. At least nginx, haproxy, and caddy can all use a unix domain socket as an upstream.
Re:Dear Linux, Privileged Ports Must Die
by rascul on Thursday September 01, 2022 @07:09AM
(#32674735)
This should generally be preferred when reverse proxying to localhost, as you get to adjust permissions on the socket. Unfortunately people aren't always doing this, and sometimes the upstream app isn't capable.
Re:Dear Linux, Privileged Ports Must Die
by XorNot on Wednesday August 31, 2022 @11:48PM
(#32671706)
When you get right down to it the issue is port numbers just plain don't work for this. SELinux had some concept of sending SELinux security contexts over the network so you could get positive claims about what you were talking to, but it was never developed into a full system AFAIK.
Which is ultimately what you want: TLS "I'm securely talking to the controller of this domain name" and then a secondary "within that controllers namespace, I'm definitely talking to the service I think I am".
There are plenty of cases where a web server is just a reverse proxy to :8080 or some other non-privileged port that could potentially be taken over in such a manner.