有没有办法让非root进程绑定到Linux上的"特权"端口？

简而言之,如果你想保持安全,请使用iptables,如果你想确保这个限制再也不会困扰你,请编译内核.

另外两个简单的可能性

有一个旧的(不合时宜的)解决方案是"一个守护程序,它绑定在一个低端口并将控制权交给你的守护进程".它被称为inetd(或xinetd).缺点是:

您的守护进程需要在stdin/stdout上进行通信(如果您不控制守护进程 - 如果您没有源代码 - 那么这可能是一个showstopper,尽管某些服务可能具有inetd兼容性标志)

为每个连接分叉一个新的守护进程

它是链条中的一个额外链接

优点:

在任何旧UNIX上都可用

一旦你的系统管理员设置了配置,你就可以开始进行开发(当你重新构建你的守护进程时,你可能会失去setcap功能吗？然后你将不得不回到你的管理员那里"请先生...... ".)

守护进程不必担心网络的东西,只需要谈谈stdin/stdout

可以根据请求配置为以非root用户身份执行守护程序

另一个替代方案:从特权端口到一些任意高编号端口的hacked-up代理(netcat甚至更强大的代理),您可以在其中运行目标守护程序.(Netcat显然不是一个生产解决方案,但"只是我的开发盒",对吧？).这样,您可以继续使用支持网络的服务器版本,只需要root/sudo启动代理(启动时),不会依赖复杂/可能脆弱的功能.

我的"标准解决方法"使用socat作为用户空间重定向器:

socat tcp6-listen:80,fork tcp6:8080

请注意,这不会扩展,分叉是昂贵的,但这是socat的工作方式.

Linux支持的功能支持更细粒度的权限,而不仅仅是"此应用程序以root身份运行".其中一项功能是CAP_NET_BIND_SERVICE绑定到特权端口(<1024).

不幸的是,我不知道如何利用它来运行非root用户同时仍然给它CAP_NET_BIND_SERVICE(可能使用setcap,但必然会有一个现有的解决方案).

我知道这是一个老问题,但现在最近(> = 4.3)内核终于有了一个很好的答案 - 环境功能.

快速回答是从git中获取最新(尚未发布)的libcap版本并进行编译.将生成的progs/capsh二进制文件复制到某处(/usr/local/bin是一个不错的选择).然后,以root身份启动您的程序

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

按顺序,我们是

声明当我们切换用户时,我们希望保留当前的功能集

将用户和群组切换为"您的服务用户名"

将cap_net_bind_service功能添加到继承和环境集

分叉bash -c 'your-command'(因为capsh后面的参数自动启动bash --)

引擎盖下有很多内容.

首先,我们以root身份运行,因此默认情况下,我们会获得一整套功能.其中包括使用setuid和setgid系统调用切换uid和gid的功能.但是,通常当一个程序执行此操作时,它会丢失其功能集 - 这样就可以setuid保留原有的root方法.该--keep=1标志告诉capsh发出prctl(PR_SET_KEEPCAPS)syscall,它在更改用户时禁用功能丢弃.用户的实际变化通过capsh与发生的--user标志,它运行setuid和setgid.

我们需要解决的下一个问题是如何以我们exec的孩子之后的方式设置能力.功能系统始终具有"继承"的一组功能,这是"在execve(2)中保留的一组功能"[ capabilities(7) ].虽然这听起来像是解决了我们的问题(只是设置了cap_net_bind_service继承的能力,对吗？),但这实际上只适用于特权进程 - 而且我们的进程不再具有特权,因为我们已经更改了用户(带有--user标志).

新的环境功能集解决了这个问题 - 它是"一组在非特权程序的execve(2)中保留的功能." 通过放入cap_net_bind_service环境集,当capshexec是我们的服务器程序时,我们的程序将继承此功能并能够将侦听器绑定到低端口.

如果您有兴趣了解更多信息,功能手册页将详细解释这一点.运行capsh经过strace也非常丰富!

出于某种原因,没有人提到将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

与其他方法比较.这个方法:

从某些角度来说,(IMO)比设置CAP_NET_BIND_SERVICE/setuid更安全,因为应用程序根本没有setuid,甚至部分(功能实际上是).例如,要捕获启用功能的应用程序的coredump,您需要更改sysctl fs.suid_dumpable(这会导致另一个潜在的安全问题)另外,当设置CAP/suid时,/ proc/PID目录由root拥有,所以您的非root用户将无法获得运行进程的完整信息/控制权,例如,用户将无法(通常情况下)通过/ proc/PID/fd /确定哪些连接属于应用程序(netstat -aptn | grep PID).

有安全劣势:当您的应用程序(或任何使用端口443-1024的应用程序)由于某种原因而关闭时,另一个应用程序可能会占用该端口.但是这个问题也可以应用于CAP/suid(如果你在解释器上设置它,例如java/nodejs)和iptables-redirect.使用systemd-socket方法排除此问题.使用authbind方法仅允许特殊用户绑定.

每次部署新版本的应用程序时都不需要设置CAP/suid.

不需要应用程序支持/修改,如systemd-socket方法.

不需要内核重建(如果运行版本支持此sysctl设置)

没有像authbind/privbind方法那样执行LD_PRELOAD,这可能会影响性能,安全性和行为(是吗？还没有测试过).在其余的authbind中是非常灵活和安全的方法.

过度执行iptables REDIRECT/DNAT方法,因为它不需要地址转换,连接状态跟踪等.这在高负载系统上才会显着.

根据具体情况,我会在sysctl,CAP,authbind和iptables-redirect之间进行选择.我们有很多选择,这很棒.

TLDR:对于"答案"(如我所见),请跳到本答案的>> TLDR <<部分.

好吧,我已经弄明白了(这次是真的),这个问题的答案,我的这个答案也是一种道歉的方式,以促进另一个答案(在这里和在推特上)我认为是"最好的"但是在尝试之后,发现我错了.从我的错误中学习孩子:在你真正尝试过之前不要宣传一些东西!

我再次回顾了这里的所有答案.我尝试了其中一些(并选择不尝试其他人,因为我根本不喜欢这些解决方案).我认为解决方案是使用systemd它Capabilities=和CapabilitiesBindingSet=设置.经过一段时间的摔跤后,我发现这不是解决方案,因为:

功能旨在限制根进程!

由于OP明智地指出,这是总是最好避免(对所有的守护程序如果可能的话!).

您不能使用选项与相关的功能User=,并Group=在systemd单元文件,因为能力总是当复位execev(或任何功能)被调用.换句话说,当systemd分叉并丢弃其权限时,功能将被重置.没有办法解决这个问题,内核中的所有绑定逻辑都是基于uid = 0的基础,而不是功能.这意味着Capabilities不太可能成为这个问题的正确答案(至少在很短的时间内).顺便提一下,setcap正如其他人所提到的,不是解决方案.它对我不起作用,它对脚本不起作用,并且无论何时文件发生变化都会重置.

在我微薄的辩护中,我确实陈述了(在我现在删除的评论中),詹姆斯的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,但是由于53,成功接受了连接 iptables

我们可以将命令包含在单元文件本身中,从而节省人们的头痛.systemd清除我们的防火墙规则,确保在守护程序未运行时删除它们.

我们从未以root身份运行,并且我们无法进行权限提升(至少systemd声称),即使守护程序被泄露并设置也是如此uid=0.

iptables不幸的是,它仍然是一个非常丑陋且难以使用的实用程序.例如,如果守护程序正在侦听,eth0:0而不是eth0命令略有不同.

systemd是一个sysvinit替代品,可以选择启动具有特定功能的守护程序.选项Capabilities =,CapabilityBoundingSet =在systemd.exec(5)联机帮助页中.

端口重定向对我们来说最有意义,但我们遇到了一个问题,我们的应用程序将在本地解析一个也需要重新路由的URL; (这意味着你shindig).

这也将允许您在访问本地计算机上的URL时重定向.

iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080
iptables -A OUTPUT -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080

在启动时:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

然后,您可以绑定到前进的端口.

使用systemd,您只需稍微修改您的服务即可接受预先激活的套接字.

您可以稍后使用systemd socket activate.

不需要功能,iptables或其他技巧.

这是来自简单python http服务器的这个示例的相关systemd文件的内容

文件 httpd-true.service

[Unit]
Description=Httpd true 

[Service]
ExecStart=/usr/local/bin/httpd-true
User=subsonic

PrivateTmp=yes

文件 httpd-true.socket

[Unit]
Description=HTTPD true

[Socket]
ListenStream=80

[Install]
WantedBy=default.target

现代Linux支持/sbin/sysctl -w net.ipv4.ip_unprivileged_port_start=0。