Linux支持支持更细粒度权限的功能，而不仅仅是“此应用程序以根用户身份运行”。其中一个功能是CAP_NET_BIND_SERVICE，它是关于绑定到特权端口(<1024)的。

不幸的是，我不知道如何利用它来运行一个应用程序作为非根，同时仍然给它CAP_NET_BIND_SERVICE(可能使用setcap，但肯定有一个现有的解决方案)。

在libcap网站上有一个文件共享库链接到非特权应用程序的实例。最近在回答一个关于向共享库添加功能的问题时提到了它。

出于某种原因，没有人提到降低sysctl net.ipv4。Ip_unprivileged_port_start到您需要的值。 示例:我们需要将应用程序绑定到443端口。

sysctl net.ipv4.ip_unprivileged_port_start=443

有些人可能会说，存在潜在的安全问题:非特权用户现在可能绑定到其他特权端口(444-1024)。 但是你可以用iptables通过阻塞其他端口轻松解决这个问题:

iptables -I INPUT -p tcp --dport 444:1024 -j DROP
iptables -I INPUT -p udp --dport 444:1024 -j DROP

与其他方法的比较。这个方法:

from some point is (IMO) even more secure than setting CAP_NET_BIND_SERVICE/setuid, since an application doesn't setuid at all, even partly (capabilities actually are). For example, to catch a coredump of capability-enabled application you will need to change sysctl fs.suid_dumpable (which leads to another potential security problems) Also, when CAP/suid is set, /proc/PID directory is owned by root, so your non-root user will not have full information/control of running process, for example, user will not be able (in common case) to determine which connections belong to application via /proc/PID/fd/ (netstat -aptn | grep PID). has security disadvantage: while your app (or any app that uses ports 443-1024) is down for some reason, another app could take the port. But this problem could also be applied to CAP/suid (in case you set it on interpreter, e.g. java/nodejs) and iptables-redirect. Use systemd-socket method to exclude this problem. Use authbind method to only allow special user binding. doesn't require setting CAP/suid every time you deploy new version of application. doesn't require application support/modification, like systemd-socket method. doesn't require kernel rebuild (if running version supports this sysctl setting) doesn't do LD_PRELOAD like authbind/privbind method, this could potentially affect performance, security, behavior (does it? haven't tested). In the rest authbind is really flexible and secure method. over-performs iptables REDIRECT/DNAT method, since it doesn't require address translation, connection state tracking, etc. This only noticeable on high-load systems.

根据具体情况，我将在sysctl、CAP、authbind和iptables-redirect之间进行选择。我们有这么多选择真是太好了。

TLDR:对于“答案”(如我所见)，跳到这个答案中的>>TLDR<<部分。

好吧，我已经想明白了(这次是真的)，这个问题的答案，我的这个答案也是一种道歉的方式，因为我推广了另一个我认为是“最好的”的答案(在这里和推特上)，但在尝试之后，发现我错了。孩子们，从我的错误中吸取教训吧:在你自己真正尝试过之前，不要推销任何东西!

我在这里复习了所有的答案。我已经尝试了其中的一些(而选择不尝试其他的，因为我不喜欢这些解决方案)。我认为解决方案是使用systemd及其Capabilities=和capactiesbindingset = settings。在思考了一段时间后，我发现这不是解决方案，因为:

功能旨在限制根进程!

正如OP所明智地指出的那样，最好避免这种情况(如果可能的话，对于所有守护进程!)。

You cannot use the Capabilities related options with User= and Group= in systemd unit files, because capabilities are ALWAYS reset when execev (or whatever the function is) is called. In other words, when systemd forks and drops its perms, the capabilities are reset. There is no way around this, and all that binding logic in the kernel is basic around uid=0, not capabilities. This means that it is unlikely that Capabilities will ever be the right answer to this question (at least any time soon). Incidentally, setcap, as others have mentioned, is not a solution. It didn't work for me, it doesn't work nicely with scripts, and those are reset anyways whenever the file changes.

在我微薄的辩护中，我确实说过(在我现在删除的评论中)，詹姆斯的iptables建议(OP也提到了)是“第二优解决方案”。: - p

> > TLDR < <

解决方案是将systemd与动态iptables命令结合起来，就像这样(取自DNSChain):

[Unit]
Description=dnschain
After=network.target
Wants=namecoin.service

[Service]
ExecStart=/usr/local/bin/dnschain
Environment=DNSCHAIN_SYSD_VER=0.0.1
PermissionsStartOnly=true
ExecStartPre=/sbin/sysctl -w net.ipv4.ip_forward=1
ExecStartPre=-/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=-/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStartPre=/sbin/iptables -A INPUT -p udp --dport 5333 -j ACCEPT
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
ExecStopPost=/sbin/iptables -D INPUT -p udp --dport 5333 -j ACCEPT
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 5333
User=dns
Group=dns
Restart=always
RestartSec=5
WorkingDirectory=/home/dns
PrivateTmp=true
NoNewPrivileges=true
ReadOnlyDirectories=/etc

# Unfortunately, capabilities are basically worthless because they're designed to restrict root daemons. Instead, we use iptables to listen on privileged ports.
# Capabilities=cap_net_bind_service+pei
# SecureBits=keep-caps

[Install]
WantedBy=multi-user.target

在这里，我们完成了以下工作:

守护进程侦听5333，但是由于iptables，连接成功地在53上被接受 我们可以将命令包含在单元文件本身中，从而为人们省去了麻烦。Systemd为我们清理防火墙规则，确保在守护进程未运行时删除它们。 我们从不以根用户身份运行，并且使特权升级成为不可能(至少systemd声称是这样)，即使守护进程被破坏并设置uid=0。

不幸的是，Iptables仍然是一个相当丑陋且难以使用的实用工具。例如，如果守护进程正在侦听eth0:0而不是eth0，则命令略有不同。

我知道这是一个老问题，但是现在有了最新的(>= 4.3)内核，这个问题终于有了一个很好的答案——环境能力。

快速的答案是从git中获取libcap的最新(尚未发布的)版本的副本并编译它。将生成的progs/capsh二进制文件复制到某个地方(/usr/local/bin是一个不错的选择)。然后，作为根用户，使用

/usr/local/bin/capsh --keep=1 --user='your-service-user-name' \
    --inh='cap_net_bind_service' --addamb='cap_net_bind_service' \ 
    -- -c 'your-program'

按顺序，我们是

声明当切换用户时，我们希望保持当前的功能集 切换用户和组到“your-service-user-name” 将cap_net_bind_service功能添加到继承的&环境集 派生bash -c 'your-command'(因为capsh会自动用——后面的参数启动bash)

这里隐藏着很多秘密。

Firstly, we are running as root, so by default, we get a full set of capabilities. Included in this is the ability to switch uid & gid with the setuid and setgid syscalls. However, ordinarily when a program does this, it loses its set of capabilities - this is so that the old way of dropping root with setuid still works. The --keep=1 flag tells capsh to issue the prctl(PR_SET_KEEPCAPS) syscall, which disables the dropping of capabilities when changing user. The actual changing of users by capsh happens with the --user flag, which runs setuid and setgid.

The next problem we need to solve is how to set capabilities in a way that carries on after we exec our children. The capabilities system has always had an 'inherited' set of capabilities, which is " a set of capabilities preserved across an execve(2)" [capabilities(7)]. Whilst this sounds like it solves our problem (just set the cap_net_bind_service capability to inherited, right?), this actually only applies for privileged processes - and our process is not privileged anymore, because we already changed user (with the --user flag).

新的环境能力集解决了这个问题——它是“在一个没有特权的程序的执行中保存的一组能力。”通过将cap_net_bind_service放在环境集中，当capsh exec执行我们的服务器程序时，我们的程序将继承此功能，并能够将侦听器绑定到低端口。

如果您有兴趣了解更多信息，功能手册页详细解释了这一点。通过strace运行capsh也是非常有用的!

或者修补内核并删除检查。

(最后的选择，不推荐)。

在net/ipv4/af_inet.c中，删除读取的两行

      if (snum && snum < PROT_SOCK && !capable(CAP_NET_BIND_SERVICE))
              goto out;

内核将不再检查特权端口。