21 ms·

Dear Linux, Privileged Ports Must Die

235 points by rcarmo 4y ago

egberts1 4y ago
Starting with process ID 1, this daemon (who shall not be named) should have zero active network capability but should be able to mete out such a privilege. Oh wait, that’s no longer the desired case.
anyfoo 4y ago
True. If you don't understand why that was ever a thing: This comes from a time where in networks (and, to some degree at some point, the entire Internet), basically only non-administrator users were not trusted. Besides this weird idea of "privileged ports" that would prevent a non-administrator user to pose as a system service to other computers, it was also entirely common to just use IP address ranges for authentication. It was an entirely different world. The thought that someone rogue could plug in an entire malicious machine into a network, rather than just being a random student having user-level access, was present, but often not considered a serious enough threat. And it may not have been, given what a lot of networks--and computers--were used for back then, compared to today.
- ggm 4y ago
  This is also half the story in some ways. SRV records didn't exist because the DNS didn't exist. Email "was" port 25 because that was the assigned port. It was uplifted into the WKS (well known services) model as IANA port allocations, and then rei-ified by "ask IANA for a port" and low number assignment implicitly meant a service daemon which had to setuid() to the user for specific delivery events (most things were store-and-forward) Once SRV records were invented, at the cost of 2+ DNS RTT you can ask "hey, where do I talk SMTP to this place" and be told what port to bind to. But lots of stuff was godfathered in, great-grandfathered in. Too many people think SSH is on 22 and don't want to incur the DNS costs. before this, its 25 for mail. 110 for POP, 123 for NTP for pretty good reasons: we didn't have anything else, except inter-host agreement which ports bound to which service, and the services were almost exclusively launched by root from init process. The trend to dropping effective UID came pretty damn quickly after people realized SMTP as root meant remote actors sending Subject: "|bad stuff; even worse" subject lines to exec() calls which did implicit shell uplift. (I am eliding this a bit) I run SSH on a shifted port. If I could convince myself that URLs with :port embedded were "cool" I'd move off 443 and 80.
  - api 4y ago
    SRV record support is still very inconsistent. Loads and loads of stuff just always hard codes the port.
    - ggm 4y ago
      yep. its one of those "we could but we don't" moments. We could stop using WKS if we were willing to try.
  - anyfoo 4y ago
    Not sure, I think it was more complex than that. The "tcpmux" port 1 in /etc/services hints to some of the story. And wasn't there an early competing name system (called NAMES maybe?) that included the port as well, which lost out against DNS for... some reason? I think there were some nuances that are long forgotten.
  - wahern 4y ago
    Before SRV records existed, there was portmap for RPC services like NFS. Most system and network administrators hated portmap, still hate portmap, and the requirement for portmap was removed from NFSv4, at least for querying the target port of remote services. People are too accustomed to relying on firewall rules. We can't have nice things like SRV not because they're too difficult to use, but because they're too difficult to control with simple, static, external ACLs lower down the networking stack.
  - voltagex_ 4y ago
    OpenSSH doesn't support SRV records by default - it would make things easier to move if it did.
- duxup 4y ago
  Heck I remember when whitehouse.gov had an open mail relay. Th internet was a very trusting place once. I sent a lot of mail through there…
- kazinator 4y ago
  TCP and UDP communication doesn't just go over a network. If you're talking to a service on the same machine, and the port number is in the privileged range, then (in theory) you have the assurance that it's a root process and that sending messages to it is as secure as passing data to the kernel.
  - anyfoo 4y ago
    Should probably better use a UNIX domain socket for that, which honors POSIX permissions on its file.
    - kazinator 4y ago
      Unix domain socket permissions are quagmire of portability, aren't they? It adds complexity to the app if the app also does speak over the network. It's more than just changing how you create the sockets, and a few details around that. You will find that the detailed semantics of some of the socket operations will be different here and there. E.g. exactly how a non-blocking connect works over a AF_UNIX versus AF_INET in all the cases that may arise; things like that. The configuration may be exposed to the user who may have to learn to specify a Unix socket for the local case or else an IP address. If there is some configuration language, it may have to be tweaked to indicate the address type. (Could be as simple as a hack somewhere that if there is a leading slash, it's AF_UNIX).
- deleted 4y ago
  [deleted]
sitkack 4y ago
sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary
- rochacon 4y ago
  Saw the title and came here to post this; simple and effective. I use this in combination with `kubectl port-forward` and `/etc/hosts` almost daily to easily proxy to internal services.
- silisili 4y ago
  I believe this has been the recommendation for quite some time. It's how users are able to use ping, for example. That said, I kinda agree with the author that it feels weird today. And the vast majority of people will just reach for the sudo hammer instead of researching to find setcap, which is a security nightmare. I'd probably argue keeping the idea of privileged ports, but not having it enabled by default anymore, I guess.
  - bombcar 4y ago
    Unix is strange in that the vast majority of computers running it are single user, but still have everything for multiuser support laying around.
    - Beltalowda 4y ago
      Most systems do tend to use different users for running services though; so while there's a single "human user", the multi-user support is being used quite a lot.
      - bombcar 4y ago
        Which is another bandaid - "system users" is a hack that should be better handled by a system designed to handle permissions, etc in a more granular method than "this is a user".
- ninefathom 4y ago
zajio1am 4y ago
IMHO privileged ports are still useful to distinguish ports assigned by system administrator and ports assigned by any user. Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely preventable failure of the system service. The minor issue with privileges is already solved by CAP_NET_BIND_SERVICE, the init system could just give this capability to every system service, instead of disabling privileged ports system-wide.
- Brian_K_White 4y ago
  Perhaps services could have different priorities, and if the wonderful systemd starts a rando user service before the system service, the system service starts anyway and the existing user service gets booted off the port.
  - zibby8 4y ago
    What if the port is only opened on demand? Like if system service is in state X, it is listening to port Y, otherwise it is not listening to port Y.
    - dinosaurdynasty 4y ago
      Systemd has socket units that could support this, though it requires cooperation from the listening program.
      - nirimda 4y ago
        In case anyone wonders what the cooperation is, normally when you start a program on Linux you get three open file handles: standard input, standard output and standard error. But if you use systemd socket activation, then when your program starts you get an additional open file handle per port. So rather than binding to a port, you ask your webserver library to listen for requests on the extra file handle. De facto, this means the application author needs cooperation from their webserver library - it needs to have been written so that it has the option to listen from an open file handle rather than binding to a port and listening to the file handle it gets as a result of that bind. But since this is a reasonably common usecase, and basically just half of the normal process, you might discover that the library you're already using has support for it. On the other hand, AFAIK docker doesn't support socket activation, so if you use docker to provide your runtime it's game over.
kazinator 4y ago
Dear Complainer, Write an updated RFC, get it published and send me the number. Yours Truly, Tux
GauntletWizard 4y ago
I'm in the opposite camp, not because I think that you should be forced to do the privileged ports dance, but because I think you should bind to higher ports and it should be your load balancer's work to do the translation. Everyone is running some form of load balancer, whether it be a NAT box, Nginx, Kube-proxy, etc. The low-numbered internet ports are useful to avoid binding so that your machine that's only a shell host isn't used as an exploit server when a single user on it is compromised. It's useful to provide a minor barrier to understanding how a server works and port allocations are made before someone deploys their cool WebApp on a random ec2 machine. Probably good advice if you're maintaining a base image for a k8s cluster or on the load balancer box itself or whatever to simply set the minimum port to 1, though.
- fomine3 4y ago
  What prevents port 3000 isn't used for exploit server? I argue opposite. Possibly newbie would run `sudo node` to run webapp on port 80, that is nightmare.
  - GauntletWizard 4y ago
    Nothing prevents that. Your average newbie is more likely to notice the port in the URL, though, that it's not an "Official" bank link or whatever. If you've got root, you will misconfigure no matter what you do. I'm not arguing against a root user - I'm arguing about machines you don't administer.
- worthless-trash 4y ago
  So tcpmux has to run as root, why you hating on that ?
Karellen 4y ago
> The workaround > > On modern Linux systems, you can configure privileged ports using sysctl: Or you could just run your service on a non-privileged port - you don't have to stick to 80/443. (If you really must have access to the service on the standard ports, you could set up an iptables/firewall rule to forward packets headed to port 80/443 to whatever port you're actually running your service on.)
- Skunkleton 4y ago
  IMO using socket activation via systemd is a reasonable approach. I don't see any reason a non-service account should be running a service on port 80.
throwaway09223 4y ago
If you want to disable priviliged ports on linux you can simply run this command, or add it to /etc/sysctl.conf: # echo 0 > /proc/sys/net/ipv4/ip_unprivileged_port_start As others have said, CAP_NET_BIND_SERVICE already solves this issue without root, as do the myriad of other configurable options in the linux networking stack. You can configure different port handling rules on a per-container basis, such as granting CAP_NET_BIND_SERVICE for the entire container -- and the network namespace will prevent tomfoolery on interfaces which aren't part of the container. The argument against privileged ports is mostly a collection of straw men. It's true they can't create remote trust (because you can't trust the integrity of the remote system), but this doesn't mean privileged ports are useless: They still guarantee no reservation issues among system processes. For example, privileged ports prevent a user from crashing sshd and then screwing around and binding their own process to port 22. This is a rant written by someone with just enough understanding to be dangerous, but not quite enough wisdom to know why things are still the way they are. Most of the complaints raised are subtly inaccurate. I would absolutely not trust running the kitten webserver after reading this article.
- chungy 4y ago
  > I would absolutely not trust running the kitten webserver after reading this article. Indeed, after it points out that the installer changes a sysctl automatically, that's shockingly poor practice for someone that claims to like security. It's fair to disagree and critique an aspect of operating system design. It's even fair to recommend to users to perform the configuration task themselves, after understanding any risks involved. It's a whole other league to just take the initiative to alter system configuration without even informing the user! This fact alone makes me put Kitten firmly in the untrustworthy category. A shame or not? I don't know, I hadn't even heard about it before this article.
- BeefWellington 4y ago
  Yeah, the argument (effectively) that most systems aren't multi-user flies in the face of well, everything modern too, the author just doesn't realize it.
- Beltalowda 4y ago
not2b 4y ago
As the issue is easily worked around (in several ways mentioned in the comments) it isn't worth changing.
- fomine3 4y ago
  Default is very important. If there's no limitation, modern Well known server daemons (like http server) were implemented without requiring root.
  - not2b 4y ago
    There are billions of Linux systems in the world. They have a default. If you change the default for your own distribution, you're the oddball, and the fact that there are two different values for the default can itself be an issue. It's not possible to change the default everywhere and have everyone adopt your new default. The kernel developers are very careful not to make breaking changes. Just the same, you can write your non-root server and arrange to be launched by a service manager that turns on the appropriate capability to allow it to bind low-numbered ports, but nothing else.
    - fomine3 4y ago
      Yes change it for the next 15 year. Anyway already there's a mitigation by CAP.
    - Maursault 4y ago
      > There are billions of Linux systems in the world. There are not billions of Linux servers, desktops and phones, probably high single digit millions or low double digit millions, but I suppose if you include microcontrollers, perhaps. One should be able to configure Linux to reconfigure itself any which way one wants it on reboot without making fundamental changes to all Linux systems everywhere. OP really can't figure a way to run a custom configuration script on reboot? RLY?? I would consider this academic on BSD. Is this something that systemd broke, that one can't pump the special settings back in, and they are just lost on every reboot? Then never reboot. Problem solved. Otherwise, init ftw.
zokier 4y ago
I've thought about this and I think it would be neat if you could define permissions for a user/group to bind to some specific port (without going all in with selinux or something). If listen ports would be represented as named objects in filesystem tree, then you could manage them by simple chmod, but I guess even something cludgier would be good enough (and more linuxy..).
- thayne 4y ago
  I've thought about that too. Then you could say the apache user can bind to port 80 and 443, the ssh user can bind to port 22, the bind user can bind to port 53, etc.
lathiat 4y ago
You can use linux capabilities to grand the CAP_NET_BIND_SERVICE privilege only. You can do this either by launchign with "capsh" and should also be able to configure a systemd service to do it. There seems some gotchas though so I haven't tested it with systemd but some references: https://serverfault.com/questions/916807/net-bind-capability-with-systemd https://serverfault.com/questions/916807/net-bind-capability... https://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-on-linux https://stackoverflow.com/questions/413807/is-there-a-way-fo... If you were to disable/lower privileged ports entirely you need to also realise there are, as always, a bunch of implicit security boundaries related to this that you need to account for. As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially do something nefarious - depending on the protocol you raced it may give you some privileges to deceive a remote host etc. Which is not to say you shouldn't do it in general but one must be aware of these implications when you want to change a literally decades old design decision that like all good bugs, many people depend on.
- wang_li 4y ago
  >As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address. Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks.
  - BeefWellington 4y ago
    > Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. SELinux can effectively do this via the 'semanage port' options[1] -- so you could configure it and then set privileged ports to 0 and achieve what you're looking for. Admittedly this seems like using a crane and wrecking ball to hang a painting. [1]: https://www.man7.org/linux/man-pages/man8/semanage-port.8.html https://www.man7.org/linux/man-pages/man8/semanage-port.8.ht...
zokier 4y ago
> And for the three folks in Finland who administer multi-user Linux instances and rely on privileged ports for their mainframe-era security properties, they can always run sysctl and set their port limit to 1024 as it was before. What is this reference to? Feels like a cheap snipe at something...
- orphean 4y ago
  It’s just a joke. It’s referencing the fact that no matter how obsolete or obscure something is somebody out there likes things How They Are.
  - db48x 4y ago
    I have a fork that reimplements spacebar heating.
    - bobnamob 4y ago
      Reference xkcd: https://xkcd.com/1172 https://xkcd.com/1172
  - v7n 4y ago
    Considering the origins of Linux I don't think joke is all there is to it. It would not surprise me at all if there were multiple such systems still maintained in Finnish universities; quite the opposite.
donatj 4y ago
> macOS removed them as of Mojave What… huh. I tried it and sure enough. I had … no idea. I don't like that, mostly because it flies in the face of my "But I need sudo access as a developer" arguments. Still can't edit /etc/hosts though
Ferret7446 4y ago
Privileged ports can be grabbed by a designated service and then handed off to an application. The application itself does not have to start as root. I believe systemd does this. The point is to prevent a literal nobody user on the system from grabbing 22 and MITM SSH or some similar shenanigans.
- ReaLNero 4y ago
  If some person has the ability to control ports and execute code, you are one kernel vulnerability away from complete disaster.
  - School-Cotton 4y ago
    Yes, but that’s not a good argument for removing layers of defense.
    - _ph_ 4y ago
      It is a good argument against keeping bad layers of defense, if it is trivial to make better ones.
      - sph 4y ago
        It's not a bad layer, it's quite effective. If you do not have root, there is no way to access 1-1024 period.
        _ph_ 4y ago
        It is not effective, if this is not the type of "attack" you have to defend against vs. plugging a Raspberry Pi with some nefarious software into the same network. But yes, I think preventing random users from opening ports listening to the world is a good idea, I don't think it should be done this way. First of all, it possibly should affect all ports and there should be a configuration file which regulates which user can open which port. Tying that privilege to the root id is the worst possible way, as discussed. The right way is to define a mapping, which userid may open a port below 1024 or at all. That would also ban e.g. a malware to operate a backdoor server on a non-privileged port. And would mean that no service requires to have root rights. These things you could do to improve, not weaken the initial concept.
MrStonedOne 4y ago
kayodelycaon 4y ago
Doesn’t systemd allow you to hand off sockets to a process?
- thayne 4y ago
  Yes, but it needs cooperation from the process. Specifically, the process needs to know how to get the file descriptor from the environment variable and use that rather than binding to the port itself. And not all services are set up to do that.
fortran77 4y ago
Mainframe? Unix's origins were on minicomputers not on mainframes.
Brian_K_White 4y ago
I was actually with them until "In fact, the Kitten installer does just this." You wanna make an argument that things should work differently, fine, you wanna even make a custom distro with brave new behavior, fine, but a package installer should not be changing such a default system behavior that will from then-on affect unknown other services. This violates least surprise in a big way and is not excused merely because the package author thinks that crufty old behavior is stupid. Even if there's a confirmation that's just more wrong than the wrong they're complaining about. I don't think it should even offer to so much as add a firewall rule just for the single port it wants to use, let alone make a change that changes the behavior and breaks universal assumptions about all ports. To give a user that level of unthinking unknowing convenience, do that in the form of a container image. Otherwise just directions, and directions that say how to configure a firewall rule not advice to change a default behavior across the board. If the user does not already know enough to ignore the bad advice and arrange for the listening mechanism themselves, or follow it but fully educated and conscious, then they are trusting you not to do bad things and take liberties with their system.
- makeva 4y ago
  The installer makes unexpected change that you wouldn't know how to revert (and that you would need to) unless you read at the code. It feels like we have gone back to the Windows 95's regedit era. I resent that these kinds of installer have become the norm.
  - choeger 4y ago
    That's the equivalent of "just run with sudo". People don't want to deal with different configurations, policies, etc. So to provide a "one-click" Installation, they'll just change the whole environment to whatever they think they need. Good luck installing multiple such programs.
    - Brian_K_White 4y ago
      It's like homebrew making /usr/local itself and everything in it all owned by whatever user installed homebrew for years until Apple finally just took over the directory. "most macs are really single user anyway" Really? That's the excuse? I'm supposed to feel good about software coming from this quality engineering?
quickthrower2 4y ago
Oh, I never even knew! Oblivious because I have used Windows when using 80 locally, or 8080/3000 when using Linux, or 3000/whatever or something like that in a container. I guess most projects end up working around the problem - and I only use 80 locally when it is the default by whatever set that up - usually Visual Studio (not code). Been a while since I set up a server with nginx and all that. I don't recall having to do anything special, maybe nginx runs privileged. In any case it typically reverse proxies into your app running on a higher port.
- kayodelycaon 4y ago
  The nginx master process runs as root, but the worker processes don’t. You can set the user those processes in nginx.conf
deleted 4y ago
[deleted]
a-dub 4y ago
no, i disagree. privileged ports should not be removed from linux to make a javascript webserver more secure or easier to setup.
pressurefree 4y ago
hsbauauvhabzb 4y ago
Windows leverages some services on predefined ports. Namely smb on 445. Responder abuses weak auth via poisoning attacks which trigger smb on 445. Permitting standard users on a Linux machine to open 445 has security impacts for windows machines, and enables low priv system compromises being directly leveraged (e.g. without privesc) to move laterally. There are many other edge cases which rely on existing behaviour that would make changing this a dangerous change.
- acdha 4y ago
  This is a good example of the antiquated security model we need to put firmly in the past. If you’re depending on Linux’s privileged port mechanism to protect your Windows boxes, many things have already failed: 1. Your network should be segmented and authenticated: a Linux box listening on port 445 shouldn’t matter because it’s not in a network group which receives that. 2. Your Windows boxes should have their firewalls enabled since they shouldn’t normally be making SMB connections to your Linux servers. 3. Your Linux boxes should have their firewalls configured. 4. Your Windows boxes shouldn’t be accepting requests from strangers to connect over SMB. Another way to think about it: if there’s a major Windows vulnerability, is it more likely that it’ll be attacked by a Linux box or someone in accounting clicking on the wrong PDF? Ultimately you just can’t trust the client - the percentage of times where someone can run code on your Linux box but can’t get root or attack something on a different port is just not enough to rely on for anything. Since you already know you need to protect against those other things, just focus on doing that.
  - deleted 4y ago
    [deleted]
  - sph 4y ago
    No one is depending on it. Security is an onion. The more layers, the better. I still haven't read a good argument on why that layer has to be removed at all.
    - acdha 4y ago
nu11ptr 4y ago
I agree with the article and that this is archaic, but find it very strange how this person gets on a soap box... only to screw over everyone in the end using ports under 80 in the proposal (I guess nobody needs SSH?). If anyone is going to go through this work of changing the default unprivileged port start point hopefully they would just start at 0.
aidenn0 4y ago
While there are issues with certain WKP being also privileged, this entire article ignores the fact that multi user machines still exist (and multi user Unix machines were mostly not mainframes). In such systems, having ports that are known to be administrator-only still has a use.
- rosnd 4y ago
  > this entire article ignores the fact that multi user machines still exist In the same way the Pyramids still exist.
exabrial 4y ago
Privileged ports can't die until we start using SRV records. As a bonus that would probably negate the need for ipv6, since we'd extend the ipv4 space to essentially 48 bits.
- kevincox 4y ago
  You still need privileged ports to ensure that the right service binds the port. SRV records are great because I can run on any port but if any compromised process on the system can bind that port you have greatly increased your attack surface. This can maybe be mitigated by dynamically updating the SRV record but that adds complexity and has caching issues.
exabrial 4y ago
Authbind exists and it's easy to use.
gmiller123456 4y ago
I didn't see any explanation why it was so important his server run on port 80. Allowing any user level process to listen on any of the common ports will result in security holes. E.g. A process could constantly attempt to bind to port 22 (SSH). If the SSH process dies or is restarted for any reason, the user level process can harvest usernames and passwords.
- philsnow 4y ago
  > If the SSH process dies or is restarted for any reason, the user level process can harvest usernames and passwords. That wouldn't work because the user level process wouldn't have read access to the machine's host keys in /etc/ssh/*_key, so when things connect, they would get known_hosts warnings and nobody clicks through those
  - kevincox 4y ago
    It is still a DoS attack. And of course SSH is usually TOFU so that isn't a strong defense. Imagine this at a company network. 1. The attacker compromises an application process on one machine and manages to get code execution. 2. They wait for SSH to restart (updates, trigger a crash, OOM?) then bind port 22. 3. Wait for some developer to connect to this machine for the first time. They (unexpectedly) see a new host key so accept it. Now if that developer has forwarding enabled you can log into other machines (probably with root/sudo access). You have just escalated your privileges from a non-root user on one machine to the entire network.
- Dwedit 4y ago
  Not related, but I've seen some restrictive firewalls that block outgoing connections to most ports. But it did allow connections to http or https.
cestith 4y ago
You can run your service on a local Unix port and proxy to it. That way only the proxy needs to bind to a IP port. Or, you know, run it in a container and use the Docker proxying. Or use an orchestrated ingress. Or proxy from a separate load balancer to high ports where the service runs. Why is it important to expose the application server directly to the edge in this day and age anyway? The author wants to talk security but wants to put every random application on a reachable public port?
yaur 4y ago
this is terrible advice given by someone that doesn't understand why privileged ports exist.
antimeme 4y ago
This article is nonsense. Privileged ports are a security feature. They have literally nothing to do with mainframes. On multi-user systems, they're incredibly important because they give external clients confidence that the services provided on them are authorized by the system and not just by any user -- some of whom may not be as trustworthy as others. Most systems in this era of cheap hardware are single user, BUT NOT ALL SYSTEMS. It's fine for Windows and Mac OS to do without them and it's fine to configure your own Linux system to disable them if that's what you want, but it's completely insane to argue that they're a security flaw because some people work around them using insecure practices. There are plenty of secure ways to work around them, most obviously by USING A NON-PRIVILEGED PORT. Start your service on port 8080, for example, and give out a URL like http://example.com:8080/path http://example.com:8080/path. It's really that simple. Take the time to understand the actual purpose of a feature before urging others to abolish it.
- _nalply 4y ago
  You mean that you don't want all users who can login on your system to start something that listens on a port below 1024. I can understand that.
- threatripper 4y ago
  One example I can think of is a local server handling some sensitive stuff. E.g. a webserver for a CNC machine that takes a password to log in. If that webserver is offline another user could start their own webserver with a fake login prompt. Other users who go to http://localhost http://localhost as usual would not notice.
- im3w1l 4y ago
  Now anyone can snipe 8080 and steal the url you "gave out". How is that secure?
  - antimeme 4y ago
    Did you... actually read the article this comment responded to? Or even the comment you're replying to? The original article proposed making all ports non-privileged because most systems serve a single user in practice. Are you really going to argue that changing the port to 8080 is insecure because someone could snipe it but making all ports non-privileged is better because... now someone can snipe 80 as well?
b409ba0801cd21 4y ago
When I first learned about how privileged ports worked, I thought a better system would be to have per port security that resembles filesystem security. That is, each port would have an owner that can decide which users may use the port. A program could run before starting network services that would load the security information into the kernel, and equivalents to chown and chmod would be available to update the persistence file and the kernel in tandem (or separately).
- BossingAround 4y ago
  Sounds very similar to SELinux.
waynesonfire 4y ago
why don't you submit a systemd patch?
KingMachiavelli 4y ago
A better default may be making ports for the 127.0.0.1/8 address space completely unprivileged (excluding 127.0.0.1). Using alternative localhost addresses is very useful for development. It's more convenient than using random ports since /etc/hosts can be used to give each address a fake domain name and this way HTTPS certificates work fine and page redirects don't break your manually entered port number. I'm not sure if it's possible to make the unprivileged ports configurable per listening address; I just think not all listening addresses have identical security concerns. That said it's simple to add the "cap_net_bind_service+eip" capability to any program in question; on NixOS it's just the "security.wrappers" module option.
- znpy 4y ago
  > A better default may be making ports for the 127.0.0.1/8 address space completely unprivileged I might be remembering the wrong thing, but it seems to me that I’ve read that there were discussions about fractioning that address apace for use on the public internet, since it’s enormous and basically wasted when allocated to localhost.
time4tea 4y ago
I have just set my services to run on 8080 and port mapped 80 to 8080 with iptables. Been doing this for years and never had any issue. Is this a bad idea?
_ph_ 4y ago
This is one of the things I never really understood why it wasn't fixed. The privileged ports always looked at a somewhat working hack from the times, when there were only a few machines on the net and the typical network services were few and well known. And it was a time, when having a root user as an active user account was normal. But things have changed since those times, even in the 90ies, it wasn't really reasonable any more - and solutions like sudo were implemented to give more reasonable access to higher privileges. Why wasn't anything done to the ports? I don't like the proposals presented in the article. It is perfectly fine to have a port range, which isn't available to every user on the system, but for those ports there should be a clear mechanism to configure, who is allowed to open them. So why not have an /etc/ports, where there is a port:uid mapping or a special directory (somewhere in /dev ?) where you have a file for each reserved port with only the owner of that file being able to open that port.
kevincox 4y ago
This is missing the whole point of privileged ports. The problem is that I tell you "connect to my webserver on port 80" you want to connect to the actual webserver that I expect to be there. If port 80 isn't privileged any user on the system can bind that port before the webserver starts or if it crashes. Even with TLS this is a DoS attack. What I really want is to be able to delegate specific ports to different processes. CAP_NET_BIND_SERVICE can be used to allow a process to bind any port but I want to be able to allow it to bind just a single port. My webserver can bind 80 and 443 but not 25. The MTA can bind 25 but not 80. Currently there are two main approaches to this. 1. Socket activation/passing. This has a huge number of other benefits as well. The service manager can keep the socket open across restarts, crashes or even do on-demand startup to save resources without losing a single connection. 2. A proxy that binds the privileged ports and then proxies to UNIX sockets or other things. This is fairly similar to 1 expect that it doesn't necessarily have to spawn the program. This way only a single process has the permission to bind all of these ports, every other service just creates a UNIX socket which is bound by filesystems privileges. The real model I want isn't privileged and unprivileged, it is "assigned" and "ephemeral" ports. Assigned ports can only be bound by services that were explicitly granted access to that port. ephemeral ports are always random addresses and never collide with assigned ports. But the privileged/unprivileged split is close enough.
- fbhabbed 4y ago
  > allow a process to bind any port but I want to be able to allow it to bind just a single port 3. SELinux
bArray 4y ago
> The fix is easy: ship Linux distributions so that privileged ports start from 80 to begin with. net.ipv4.ip_unprivileged_port_start=80 But then this could potentially break other security models the author is not aware of that are built on this assumption. I think the middle ground here would be to have a setting to de-root a specific port. Or whitelist a specific process for binding. Or create a server user (www is often used) that's purpose is only to have root for the sake of binding, and nothing else. Better yet, it would only be able to access resources within a tightly restricted range (file directories, ports, RAM, CPU, etc). I don't see how unrestricted 80-1024 is actually the best answer here, given the legacy cruft that will take time to deal with.
suprjami 4y ago
"Change all Linux distributions to ship a setting that our specific software needs" How about no.
axilmar 4y ago
The design error is that the applications that bind to privileged ports should be privileged as well. It is correct design to guard ports with privileges. Not every application should be able to write out to any port and read from any port. The correct approach to security is to have apps granted access to ports manually, as is done with firewalls.

235 points by rcarmo 4y ago

Starting with process ID 1, this daemon (who shall not be named) should have zero active network capability but should be able to mete out such a privilege. Oh wait, that’s no longer the desired case.

anyfoo 4y ago

True. If you don't understand why that was ever a thing: This comes from a time where in networks (and, to some degree at some point, the entire Internet), basically only non-administrator users were not trusted. Besides this weird idea of "privileged ports" that would prevent a non-administrator user to pose as a system service to other computers, it was also entirely common to just use IP address ranges for authentication. It was an entirely different world. The thought that someone rogue could plug in an entire malicious machine into a network, rather than just being a random student having user-level access, was present, but often not considered a serious enough threat. And it may not have been, given what a lot of networks--and computers--were used for back then, compared to today.

ggm 4y ago
This is also half the story in some ways. SRV records didn't exist because the DNS didn't exist. Email "was" port 25 because that was the assigned port. It was uplifted into the WKS (well known services) model as IANA port allocations, and then rei-ified by "ask IANA for a port" and low number assignment implicitly meant a service daemon which had to setuid() to the user for specific delivery events (most things were store-and-forward) Once SRV records were invented, at the cost of 2+ DNS RTT you can ask "hey, where do I talk SMTP to this place" and be told what port to bind to. But lots of stuff was godfathered in, great-grandfathered in. Too many people think SSH is on 22 and don't want to incur the DNS costs. before this, its 25 for mail. 110 for POP, 123 for NTP for pretty good reasons: we didn't have anything else, except inter-host agreement which ports bound to which service, and the services were almost exclusively launched by root from init process. The trend to dropping effective UID came pretty damn quickly after people realized SMTP as root meant remote actors sending Subject: "|bad stuff; even worse" subject lines to exec() calls which did implicit shell uplift. (I am eliding this a bit) I run SSH on a shifted port. If I could convince myself that URLs with :port embedded were "cool" I'd move off 443 and 80.
- api 4y ago
  SRV record support is still very inconsistent. Loads and loads of stuff just always hard codes the port.
  - ggm 4y ago
    yep. its one of those "we could but we don't" moments. We could stop using WKS if we were willing to try.
- anyfoo 4y ago
  Not sure, I think it was more complex than that. The "tcpmux" port 1 in /etc/services hints to some of the story. And wasn't there an early competing name system (called NAMES maybe?) that included the port as well, which lost out against DNS for... some reason? I think there were some nuances that are long forgotten.
- wahern 4y ago
  Before SRV records existed, there was portmap for RPC services like NFS. Most system and network administrators hated portmap, still hate portmap, and the requirement for portmap was removed from NFSv4, at least for querying the target port of remote services. People are too accustomed to relying on firewall rules. We can't have nice things like SRV not because they're too difficult to use, but because they're too difficult to control with simple, static, external ACLs lower down the networking stack.
- voltagex_ 4y ago
  OpenSSH doesn't support SRV records by default - it would make things easier to move if it did.
duxup 4y ago
Heck I remember when whitehouse.gov had an open mail relay. Th internet was a very trusting place once. I sent a lot of mail through there…
kazinator 4y ago
TCP and UDP communication doesn't just go over a network. If you're talking to a service on the same machine, and the port number is in the privileged range, then (in theory) you have the assurance that it's a root process and that sending messages to it is as secure as passing data to the kernel.
- anyfoo 4y ago
  Should probably better use a UNIX domain socket for that, which honors POSIX permissions on its file.
  - kazinator 4y ago
    Unix domain socket permissions are quagmire of portability, aren't they? It adds complexity to the app if the app also does speak over the network. It's more than just changing how you create the sockets, and a few details around that. You will find that the detailed semantics of some of the socket operations will be different here and there. E.g. exactly how a non-blocking connect works over a AF_UNIX versus AF_INET in all the cases that may arise; things like that. The configuration may be exposed to the user who may have to learn to specify a Unix socket for the local case or else an IP address. If there is some configuration language, it may have to be tweaked to indicate the address type. (Could be as simple as a hack somewhere that if there is a leading slash, it's AF_UNIX).
deleted 4y ago
[deleted]

sitkack 4y ago

sudo setcap CAP_NET_BIND_SERVICE=+eip /path/to/binary

rochacon 4y ago
Saw the title and came here to post this; simple and effective. I use this in combination with `kubectl port-forward` and `/etc/hosts` almost daily to easily proxy to internal services.
silisili 4y ago
I believe this has been the recommendation for quite some time. It's how users are able to use ping, for example. That said, I kinda agree with the author that it feels weird today. And the vast majority of people will just reach for the sudo hammer instead of researching to find setcap, which is a security nightmare. I'd probably argue keeping the idea of privileged ports, but not having it enabled by default anymore, I guess.
- bombcar 4y ago
  Unix is strange in that the vast majority of computers running it are single user, but still have everything for multiuser support laying around.
  - Beltalowda 4y ago
    Most systems do tend to use different users for running services though; so while there's a single "human user", the multi-user support is being used quite a lot.
    - bombcar 4y ago
      Which is another bandaid - "system users" is a hack that should be better handled by a system designed to handle permissions, etc in a more granular method than "this is a user".
ninefathom 4y ago

zajio1am 4y ago

IMHO privileged ports are still useful to distinguish ports assigned by system administrator and ports assigned by any user. Otherwise some user service can (inadvertently) take some port before a system service that was supposed to use that port started and cause completely preventable failure of the system service. The minor issue with privileges is already solved by CAP_NET_BIND_SERVICE, the init system could just give this capability to every system service, instead of disabling privileged ports system-wide.

Brian_K_White 4y ago
Perhaps services could have different priorities, and if the wonderful systemd starts a rando user service before the system service, the system service starts anyway and the existing user service gets booted off the port.
- zibby8 4y ago
  What if the port is only opened on demand? Like if system service is in state X, it is listening to port Y, otherwise it is not listening to port Y.
  - dinosaurdynasty 4y ago
    Systemd has socket units that could support this, though it requires cooperation from the listening program.
    - nirimda 4y ago
      In case anyone wonders what the cooperation is, normally when you start a program on Linux you get three open file handles: standard input, standard output and standard error. But if you use systemd socket activation, then when your program starts you get an additional open file handle per port. So rather than binding to a port, you ask your webserver library to listen for requests on the extra file handle. De facto, this means the application author needs cooperation from their webserver library - it needs to have been written so that it has the option to listen from an open file handle rather than binding to a port and listening to the file handle it gets as a result of that bind. But since this is a reasonably common usecase, and basically just half of the normal process, you might discover that the library you're already using has support for it. On the other hand, AFAIK docker doesn't support socket activation, so if you use docker to provide your runtime it's game over.

kazinator 4y ago

Dear Complainer, Write an updated RFC, get it published and send me the number. Yours Truly, Tux

GauntletWizard 4y ago

I'm in the opposite camp, not because I think that you should be forced to do the privileged ports dance, but because I think you should bind to higher ports and it should be your load balancer's work to do the translation. Everyone is running some form of load balancer, whether it be a NAT box, Nginx, Kube-proxy, etc. The low-numbered internet ports are useful to avoid binding so that your machine that's only a shell host isn't used as an exploit server when a single user on it is compromised. It's useful to provide a minor barrier to understanding how a server works and port allocations are made before someone deploys their cool WebApp on a random ec2 machine. Probably good advice if you're maintaining a base image for a k8s cluster or on the load balancer box itself or whatever to simply set the minimum port to 1, though.

fomine3 4y ago
What prevents port 3000 isn't used for exploit server? I argue opposite. Possibly newbie would run `sudo node` to run webapp on port 80, that is nightmare.
- GauntletWizard 4y ago
  Nothing prevents that. Your average newbie is more likely to notice the port in the URL, though, that it's not an "Official" bank link or whatever. If you've got root, you will misconfigure no matter what you do. I'm not arguing against a root user - I'm arguing about machines you don't administer.
worthless-trash 4y ago
So tcpmux has to run as root, why you hating on that ?

Karellen 4y ago

> The workaround > > On modern Linux systems, you can configure privileged ports using sysctl: Or you could just run your service on a non-privileged port - you don't have to stick to 80/443. (If you really must have access to the service on the standard ports, you could set up an iptables/firewall rule to forward packets headed to port 80/443 to whatever port you're actually running your service on.)

Skunkleton 4y ago
IMO using socket activation via systemd is a reasonable approach. I don't see any reason a non-service account should be running a service on port 80.

throwaway09223 4y ago

If you want to disable priviliged ports on linux you can simply run this command, or add it to /etc/sysctl.conf: # echo 0 > /proc/sys/net/ipv4/ip_unprivileged_port_start As others have said, CAP_NET_BIND_SERVICE already solves this issue without root, as do the myriad of other configurable options in the linux networking stack. You can configure different port handling rules on a per-container basis, such as granting CAP_NET_BIND_SERVICE for the entire container -- and the network namespace will prevent tomfoolery on interfaces which aren't part of the container. The argument against privileged ports is mostly a collection of straw men. It's true they can't create remote trust (because you can't trust the integrity of the remote system), but this doesn't mean privileged ports are useless: They still guarantee no reservation issues among system processes. For example, privileged ports prevent a user from crashing sshd and then screwing around and binding their own process to port 22. This is a rant written by someone with just enough understanding to be dangerous, but not quite enough wisdom to know why things are still the way they are. Most of the complaints raised are subtly inaccurate. I would absolutely not trust running the kitten webserver after reading this article.

chungy 4y ago
> I would absolutely not trust running the kitten webserver after reading this article. Indeed, after it points out that the installer changes a sysctl automatically, that's shockingly poor practice for someone that claims to like security. It's fair to disagree and critique an aspect of operating system design. It's even fair to recommend to users to perform the configuration task themselves, after understanding any risks involved. It's a whole other league to just take the initiative to alter system configuration without even informing the user! This fact alone makes me put Kitten firmly in the untrustworthy category. A shame or not? I don't know, I hadn't even heard about it before this article.
BeefWellington 4y ago
Yeah, the argument (effectively) that most systems aren't multi-user flies in the face of well, everything modern too, the author just doesn't realize it.
Beltalowda 4y ago

not2b 4y ago

As the issue is easily worked around (in several ways mentioned in the comments) it isn't worth changing.

fomine3 4y ago
Default is very important. If there's no limitation, modern Well known server daemons (like http server) were implemented without requiring root.
- not2b 4y ago
  There are billions of Linux systems in the world. They have a default. If you change the default for your own distribution, you're the oddball, and the fact that there are two different values for the default can itself be an issue. It's not possible to change the default everywhere and have everyone adopt your new default. The kernel developers are very careful not to make breaking changes. Just the same, you can write your non-root server and arrange to be launched by a service manager that turns on the appropriate capability to allow it to bind low-numbered ports, but nothing else.
  - fomine3 4y ago
    Yes change it for the next 15 year. Anyway already there's a mitigation by CAP.
  - Maursault 4y ago
    > There are billions of Linux systems in the world. There are not billions of Linux servers, desktops and phones, probably high single digit millions or low double digit millions, but I suppose if you include microcontrollers, perhaps. One should be able to configure Linux to reconfigure itself any which way one wants it on reboot without making fundamental changes to all Linux systems everywhere. OP really can't figure a way to run a custom configuration script on reboot? RLY?? I would consider this academic on BSD. Is this something that systemd broke, that one can't pump the special settings back in, and they are just lost on every reboot? Then never reboot. Problem solved. Otherwise, init ftw.

zokier 4y ago

I've thought about this and I think it would be neat if you could define permissions for a user/group to bind to some specific port (without going all in with selinux or something). If listen ports would be represented as named objects in filesystem tree, then you could manage them by simple chmod, but I guess even something cludgier would be good enough (and more linuxy..).

thayne 4y ago
I've thought about that too. Then you could say the apache user can bind to port 80 and 443, the ssh user can bind to port 22, the bind user can bind to port 53, etc.

lathiat 4y ago

You can use linux capabilities to grand the CAP_NET_BIND_SERVICE privilege only. You can do this either by launchign with "capsh" and should also be able to configure a systemd service to do it. There seems some gotchas though so I haven't tested it with systemd but some references: https://serverfault.com/questions/916807/net-bind-capability-with-systemd https://serverfault.com/questions/916807/net-bind-capability... https://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-on-linux https://stackoverflow.com/questions/413807/is-there-a-way-fo... If you were to disable/lower privileged ports entirely you need to also realise there are, as always, a bunch of implicit security boundaries related to this that you need to account for. As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially do something nefarious - depending on the protocol you raced it may give you some privileges to deceive a remote host etc. Which is not to say you shouldn't do it in general but one must be aware of these implications when you want to change a literally decades old design decision that like all good bugs, many people depend on.

wang_li 4y ago
>As a most simple example, if you can trigger a local DoS to force a process to exit then you can race to bind it's port and potentially Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. Give me some path in /sys where I can write a message of some kind, or an ioctl, which allows me to say "user httpd can bind to port 80". Or even as specific as user, port, protocol (TCP/UDP/etc) and ip address. Requiring that I have to be root to set CAP_NET_BIND_SERVICE every time I replace my web server executable sucks.
- BeefWellington 4y ago
  > Which is why what we really need is the ability to set properties on each network port and have those persist across reboots. SELinux can effectively do this via the 'semanage port' options[1] -- so you could configure it and then set privileged ports to 0 and achieve what you're looking for. Admittedly this seems like using a crane and wrecking ball to hang a painting. [1]: https://www.man7.org/linux/man-pages/man8/semanage-port.8.html https://www.man7.org/linux/man-pages/man8/semanage-port.8.ht...

zokier 4y ago

> And for the three folks in Finland who administer multi-user Linux instances and rely on privileged ports for their mainframe-era security properties, they can always run sysctl and set their port limit to 1024 as it was before. What is this reference to? Feels like a cheap snipe at something...

orphean 4y ago
It’s just a joke. It’s referencing the fact that no matter how obsolete or obscure something is somebody out there likes things How They Are.
- db48x 4y ago
  I have a fork that reimplements spacebar heating.
  - bobnamob 4y ago
    Reference xkcd: https://xkcd.com/1172 https://xkcd.com/1172
- v7n 4y ago
  Considering the origins of Linux I don't think joke is all there is to it. It would not surprise me at all if there were multiple such systems still maintained in Finnish universities; quite the opposite.

donatj 4y ago

> macOS removed them as of Mojave What… huh. I tried it and sure enough. I had … no idea. I don't like that, mostly because it flies in the face of my "But I need sudo access as a developer" arguments. Still can't edit /etc/hosts though

Ferret7446 4y ago

Privileged ports can be grabbed by a designated service and then handed off to an application. The application itself does not have to start as root. I believe systemd does this. The point is to prevent a literal nobody user on the system from grabbing 22 and MITM SSH or some similar shenanigans.

ReaLNero 4y ago
If some person has the ability to control ports and execute code, you are one kernel vulnerability away from complete disaster.
- School-Cotton 4y ago
  Yes, but that’s not a good argument for removing layers of defense.
  - _ph_ 4y ago
    It is a good argument against keeping bad layers of defense, if it is trivial to make better ones.
    - sph 4y ago
      It's not a bad layer, it's quite effective. If you do not have root, there is no way to access 1-1024 period.
      - _ph_ 4y ago
        It is not effective, if this is not the type of "attack" you have to defend against vs. plugging a Raspberry Pi with some nefarious software into the same network. But yes, I think preventing random users from opening ports listening to the world is a good idea, I don't think it should be done this way. First of all, it possibly should affect all ports and there should be a configuration file which regulates which user can open which port. Tying that privilege to the root id is the worst possible way, as discussed. The right way is to define a mapping, which userid may open a port below 1024 or at all. That would also ban e.g. a malware to operate a backdoor server on a non-privileged port. And would mean that no service requires to have root rights. These things you could do to improve, not weaken the initial concept.

MrStonedOne 4y ago

kayodelycaon 4y ago

Doesn’t systemd allow you to hand off sockets to a process?

thayne 4y ago
Yes, but it needs cooperation from the process. Specifically, the process needs to know how to get the file descriptor from the environment variable and use that rather than binding to the port itself. And not all services are set up to do that.

fortran77 4y ago

Mainframe? Unix's origins were on minicomputers not on mainframes.

Brian_K_White 4y ago

I was actually with them until "In fact, the Kitten installer does just this." You wanna make an argument that things should work differently, fine, you wanna even make a custom distro with brave new behavior, fine, but a package installer should not be changing such a default system behavior that will from then-on affect unknown other services. This violates least surprise in a big way and is not excused merely because the package author thinks that crufty old behavior is stupid. Even if there's a confirmation that's just more wrong than the wrong they're complaining about. I don't think it should even offer to so much as add a firewall rule just for the single port it wants to use, let alone make a change that changes the behavior and breaks universal assumptions about all ports. To give a user that level of unthinking unknowing convenience, do that in the form of a container image. Otherwise just directions, and directions that say how to configure a firewall rule not advice to change a default behavior across the board. If the user does not already know enough to ignore the bad advice and arrange for the listening mechanism themselves, or follow it but fully educated and conscious, then they are trusting you not to do bad things and take liberties with their system.

makeva 4y ago
The installer makes unexpected change that you wouldn't know how to revert (and that you would need to) unless you read at the code. It feels like we have gone back to the Windows 95's regedit era. I resent that these kinds of installer have become the norm.
- choeger 4y ago
  That's the equivalent of "just run with sudo". People don't want to deal with different configurations, policies, etc. So to provide a "one-click" Installation, they'll just change the whole environment to whatever they think they need. Good luck installing multiple such programs.
  - Brian_K_White 4y ago
    It's like homebrew making /usr/local itself and everything in it all owned by whatever user installed homebrew for years until Apple finally just took over the directory. "most macs are really single user anyway" Really? That's the excuse? I'm supposed to feel good about software coming from this quality engineering?

quickthrower2 4y ago

Oh, I never even knew! Oblivious because I have used Windows when using 80 locally, or 8080/3000 when using Linux, or 3000/whatever or something like that in a container. I guess most projects end up working around the problem - and I only use 80 locally when it is the default by whatever set that up - usually Visual Studio (not code). Been a while since I set up a server with nginx and all that. I don't recall having to do anything special, maybe nginx runs privileged. In any case it typically reverse proxies into your app running on a higher port.

kayodelycaon 4y ago
The nginx master process runs as root, but the worker processes don’t. You can set the user those processes in nginx.conf

deleted 4y ago

[deleted]

a-dub 4y ago

no, i disagree. privileged ports should not be removed from linux to make a javascript webserver more secure or easier to setup.

pressurefree 4y ago

hsbauauvhabzb 4y ago

Windows leverages some services on predefined ports. Namely smb on 445. Responder abuses weak auth via poisoning attacks which trigger smb on 445. Permitting standard users on a Linux machine to open 445 has security impacts for windows machines, and enables low priv system compromises being directly leveraged (e.g. without privesc) to move laterally. There are many other edge cases which rely on existing behaviour that would make changing this a dangerous change.

acdha 4y ago
This is a good example of the antiquated security model we need to put firmly in the past. If you’re depending on Linux’s privileged port mechanism to protect your Windows boxes, many things have already failed: 1. Your network should be segmented and authenticated: a Linux box listening on port 445 shouldn’t matter because it’s not in a network group which receives that. 2. Your Windows boxes should have their firewalls enabled since they shouldn’t normally be making SMB connections to your Linux servers. 3. Your Linux boxes should have their firewalls configured. 4. Your Windows boxes shouldn’t be accepting requests from strangers to connect over SMB. Another way to think about it: if there’s a major Windows vulnerability, is it more likely that it’ll be attacked by a Linux box or someone in accounting clicking on the wrong PDF? Ultimately you just can’t trust the client - the percentage of times where someone can run code on your Linux box but can’t get root or attack something on a different port is just not enough to rely on for anything. Since you already know you need to protect against those other things, just focus on doing that.
- deleted 4y ago
  [deleted]
- sph 4y ago
  No one is depending on it. Security is an onion. The more layers, the better. I still haven't read a good argument on why that layer has to be removed at all.
  - acdha 4y ago

nu11ptr 4y ago

I agree with the article and that this is archaic, but find it very strange how this person gets on a soap box... only to screw over everyone in the end using ports under 80 in the proposal (I guess nobody needs SSH?). If anyone is going to go through this work of changing the default unprivileged port start point hopefully they would just start at 0.

aidenn0 4y ago

While there are issues with certain WKP being also privileged, this entire article ignores the fact that multi user machines still exist (and multi user Unix machines were mostly not mainframes). In such systems, having ports that are known to be administrator-only still has a use.

rosnd 4y ago
> this entire article ignores the fact that multi user machines still exist In the same way the Pyramids still exist.

exabrial 4y ago

Privileged ports can't die until we start using SRV records. As a bonus that would probably negate the need for ipv6, since we'd extend the ipv4 space to essentially 48 bits.

kevincox 4y ago
You still need privileged ports to ensure that the right service binds the port. SRV records are great because I can run on any port but if any compromised process on the system can bind that port you have greatly increased your attack surface. This can maybe be mitigated by dynamically updating the SRV record but that adds complexity and has caching issues.

exabrial 4y ago

Authbind exists and it's easy to use.

gmiller123456 4y ago

I didn't see any explanation why it was so important his server run on port 80. Allowing any user level process to listen on any of the common ports will result in security holes. E.g. A process could constantly attempt to bind to port 22 (SSH). If the SSH process dies or is restarted for any reason, the user level process can harvest usernames and passwords.

philsnow 4y ago
> If the SSH process dies or is restarted for any reason, the user level process can harvest usernames and passwords. That wouldn't work because the user level process wouldn't have read access to the machine's host keys in /etc/ssh/*_key, so when things connect, they would get known_hosts warnings and nobody clicks through those
- kevincox 4y ago
  It is still a DoS attack. And of course SSH is usually TOFU so that isn't a strong defense. Imagine this at a company network. 1. The attacker compromises an application process on one machine and manages to get code execution. 2. They wait for SSH to restart (updates, trigger a crash, OOM?) then bind port 22. 3. Wait for some developer to connect to this machine for the first time. They (unexpectedly) see a new host key so accept it. Now if that developer has forwarding enabled you can log into other machines (probably with root/sudo access). You have just escalated your privileges from a non-root user on one machine to the entire network.
Dwedit 4y ago
Not related, but I've seen some restrictive firewalls that block outgoing connections to most ports. But it did allow connections to http or https.

cestith 4y ago

You can run your service on a local Unix port and proxy to it. That way only the proxy needs to bind to a IP port. Or, you know, run it in a container and use the Docker proxying. Or use an orchestrated ingress. Or proxy from a separate load balancer to high ports where the service runs. Why is it important to expose the application server directly to the edge in this day and age anyway? The author wants to talk security but wants to put every random application on a reachable public port?

yaur 4y ago

this is terrible advice given by someone that doesn't understand why privileged ports exist.

antimeme 4y ago

This article is nonsense. Privileged ports are a security feature. They have literally nothing to do with mainframes. On multi-user systems, they're incredibly important because they give external clients confidence that the services provided on them are authorized by the system and not just by any user -- some of whom may not be as trustworthy as others. Most systems in this era of cheap hardware are single user, BUT NOT ALL SYSTEMS. It's fine for Windows and Mac OS to do without them and it's fine to configure your own Linux system to disable them if that's what you want, but it's completely insane to argue that they're a security flaw because some people work around them using insecure practices. There are plenty of secure ways to work around them, most obviously by USING A NON-PRIVILEGED PORT. Start your service on port 8080, for example, and give out a URL like http://example.com:8080/path http://example.com:8080/path. It's really that simple. Take the time to understand the actual purpose of a feature before urging others to abolish it.

_nalply 4y ago
You mean that you don't want all users who can login on your system to start something that listens on a port below 1024. I can understand that.
threatripper 4y ago
One example I can think of is a local server handling some sensitive stuff. E.g. a webserver for a CNC machine that takes a password to log in. If that webserver is offline another user could start their own webserver with a fake login prompt. Other users who go to http://localhost http://localhost as usual would not notice.
im3w1l 4y ago
Now anyone can snipe 8080 and steal the url you "gave out". How is that secure?
- antimeme 4y ago
  Did you... actually read the article this comment responded to? Or even the comment you're replying to? The original article proposed making all ports non-privileged because most systems serve a single user in practice. Are you really going to argue that changing the port to 8080 is insecure because someone could snipe it but making all ports non-privileged is better because... now someone can snipe 80 as well?

b409ba0801cd21 4y ago

When I first learned about how privileged ports worked, I thought a better system would be to have per port security that resembles filesystem security. That is, each port would have an owner that can decide which users may use the port. A program could run before starting network services that would load the security information into the kernel, and equivalents to chown and chmod would be available to update the persistence file and the kernel in tandem (or separately).

BossingAround 4y ago
Sounds very similar to SELinux.

waynesonfire 4y ago

why don't you submit a systemd patch?

KingMachiavelli 4y ago

A better default may be making ports for the 127.0.0.1/8 address space completely unprivileged (excluding 127.0.0.1). Using alternative localhost addresses is very useful for development. It's more convenient than using random ports since /etc/hosts can be used to give each address a fake domain name and this way HTTPS certificates work fine and page redirects don't break your manually entered port number. I'm not sure if it's possible to make the unprivileged ports configurable per listening address; I just think not all listening addresses have identical security concerns. That said it's simple to add the "cap_net_bind_service+eip" capability to any program in question; on NixOS it's just the "security.wrappers" module option.

znpy 4y ago
> A better default may be making ports for the 127.0.0.1/8 address space completely unprivileged I might be remembering the wrong thing, but it seems to me that I’ve read that there were discussions about fractioning that address apace for use on the public internet, since it’s enormous and basically wasted when allocated to localhost.

time4tea 4y ago

I have just set my services to run on 8080 and port mapped 80 to 8080 with iptables. Been doing this for years and never had any issue. Is this a bad idea?

_ph_ 4y ago

This is one of the things I never really understood why it wasn't fixed. The privileged ports always looked at a somewhat working hack from the times, when there were only a few machines on the net and the typical network services were few and well known. And it was a time, when having a root user as an active user account was normal. But things have changed since those times, even in the 90ies, it wasn't really reasonable any more - and solutions like sudo were implemented to give more reasonable access to higher privileges. Why wasn't anything done to the ports? I don't like the proposals presented in the article. It is perfectly fine to have a port range, which isn't available to every user on the system, but for those ports there should be a clear mechanism to configure, who is allowed to open them. So why not have an /etc/ports, where there is a port:uid mapping or a special directory (somewhere in /dev ?) where you have a file for each reserved port with only the owner of that file being able to open that port.

kevincox 4y ago

This is missing the whole point of privileged ports. The problem is that I tell you "connect to my webserver on port 80" you want to connect to the actual webserver that I expect to be there. If port 80 isn't privileged any user on the system can bind that port before the webserver starts or if it crashes. Even with TLS this is a DoS attack. What I really want is to be able to delegate specific ports to different processes. CAP_NET_BIND_SERVICE can be used to allow a process to bind any port but I want to be able to allow it to bind just a single port. My webserver can bind 80 and 443 but not 25. The MTA can bind 25 but not 80. Currently there are two main approaches to this. 1. Socket activation/passing. This has a huge number of other benefits as well. The service manager can keep the socket open across restarts, crashes or even do on-demand startup to save resources without losing a single connection. 2. A proxy that binds the privileged ports and then proxies to UNIX sockets or other things. This is fairly similar to 1 expect that it doesn't necessarily have to spawn the program. This way only a single process has the permission to bind all of these ports, every other service just creates a UNIX socket which is bound by filesystems privileges. The real model I want isn't privileged and unprivileged, it is "assigned" and "ephemeral" ports. Assigned ports can only be bound by services that were explicitly granted access to that port. ephemeral ports are always random addresses and never collide with assigned ports. But the privileged/unprivileged split is close enough.

fbhabbed 4y ago
> allow a process to bind any port but I want to be able to allow it to bind just a single port 3. SELinux

bArray 4y ago

> The fix is easy: ship Linux distributions so that privileged ports start from 80 to begin with. net.ipv4.ip_unprivileged_port_start=80 But then this could potentially break other security models the author is not aware of that are built on this assumption. I think the middle ground here would be to have a setting to de-root a specific port. Or whitelist a specific process for binding. Or create a server user (www is often used) that's purpose is only to have root for the sake of binding, and nothing else. Better yet, it would only be able to access resources within a tightly restricted range (file directories, ports, RAM, CPU, etc). I don't see how unrestricted 80-1024 is actually the best answer here, given the legacy cruft that will take time to deal with.

suprjami 4y ago

"Change all Linux distributions to ship a setting that our specific software needs" How about no.

axilmar 4y ago

The design error is that the applications that bind to privileged ports should be privileged as well. It is correct design to guard ports with privileges. Not every application should be able to write out to any port and read from any port. The correct approach to security is to have apps granted access to ports manually, as is done with firewalls.