3 ms·

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_

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
> 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. Author seems aware of CAP_NET_BIND_SERVICE: https://source.small-tech.org/site.js/app/-/issues/169 https://source.small-tech.org/site.js/app/-/issues/169 and https://github.com/istanbuljs/nyc/issues/1281 https://github.com/istanbuljs/nyc/issues/1281 – the "side effects" are NodeJS explicitly checking for it, so that's a NodeJS thing and not a Linux thing. Yet curiously it's completely unmentioned in this article, in spite that this is probably what started the author's dislike of privileged ports. I guess it was inconvenient as it got in the way of angrily ranting.
- throwaway09223 4y ago
  I think more than a few of the author's complaints are deliberately disingenuous. For example, the nonsense about making a sysctl setting look as difficult and obscure as possible. The side effect with node he mentions is actually a setuid binary issue and is related to filesystem capabilities, not CAP_NET_BIND_SERVICE itself. When a setuid binary is run, including executables with capabilities set in xattrs, the loader does things a bit differently to preserve a secure execution environment. In this case it ignores some environment variables that would otherwise let the user modify the program's behavior - in particular LD_LIBRARY_PATH. The right way to do this is to launch node from whatever process launcher is in use, for example by setting capabilities in the systemd service file. There shouldn't be any need to set extended filesystem attributes on the binary itself.
dannyobrien 4y ago
I think the deal here is that the author, Aral Balkan, frequently sees these kind of topics as amenable to solution through activism: raising the issue in a public statement, garnering widespread attention, and then using that to put pressure on those best-placed to fix the issue. You can seem more of this approach in his earlier blog posts, and on his Mastodon feed: https://mastodon.ar.al/@aral https://mastodon.ar.al/@aral I don't entirely disagree with this as an approach in some circumstances, but you definitely need to have a clear idea of your target, and what incentives they have. I'm not sure what the target here is, though it's possible that he will change enough minds among distribution builders to shift things so that the default for privileged ports will be dropped to 80. The fact that Macs don't have this limit any more was certainly new to me.
deleted 4y ago
[deleted]

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

> 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. Author seems aware of CAP_NET_BIND_SERVICE: https://source.small-tech.org/site.js/app/-/issues/169 https://source.small-tech.org/site.js/app/-/issues/169 and https://github.com/istanbuljs/nyc/issues/1281 https://github.com/istanbuljs/nyc/issues/1281 – the "side effects" are NodeJS explicitly checking for it, so that's a NodeJS thing and not a Linux thing. Yet curiously it's completely unmentioned in this article, in spite that this is probably what started the author's dislike of privileged ports. I guess it was inconvenient as it got in the way of angrily ranting.

throwaway09223 4y ago
I think more than a few of the author's complaints are deliberately disingenuous. For example, the nonsense about making a sysctl setting look as difficult and obscure as possible. The side effect with node he mentions is actually a setuid binary issue and is related to filesystem capabilities, not CAP_NET_BIND_SERVICE itself. When a setuid binary is run, including executables with capabilities set in xattrs, the loader does things a bit differently to preserve a secure execution environment. In this case it ignores some environment variables that would otherwise let the user modify the program's behavior - in particular LD_LIBRARY_PATH. The right way to do this is to launch node from whatever process launcher is in use, for example by setting capabilities in the systemd service file. There shouldn't be any need to set extended filesystem attributes on the binary itself.

dannyobrien 4y ago

I think the deal here is that the author, Aral Balkan, frequently sees these kind of topics as amenable to solution through activism: raising the issue in a public statement, garnering widespread attention, and then using that to put pressure on those best-placed to fix the issue. You can seem more of this approach in his earlier blog posts, and on his Mastodon feed: https://mastodon.ar.al/@aral https://mastodon.ar.al/@aral I don't entirely disagree with this as an approach in some circumstances, but you definitely need to have a clear idea of your target, and what incentives they have. I'm not sure what the target here is, though it's possible that he will change enough minds among distribution builders to shift things so that the default for privileged ports will be dropped to 80. The fact that Macs don't have this limit any more was certainly new to me.

deleted 4y ago

[deleted]