请问4.6.1之后，是否意味着需要libcap-ng 和libcap-ng-bin的依赖？
YuenJay opened this issue · comments
感谢作者。已经在我的上古小米R2D路由器（arm5nohardfloat架构，没有openwrt官方支持。厂家万年不更新，提供了古董级的toolchain）上成功运行。
请问能否在依赖中说明bash依赖，因为脚本利用了很多高级的shell语法。比如需要编译哪些bash特性。如果busybox能够兼容的话，需要的busybox最低版本以及make menuconfig选项。我个人是交叉编译了默认选项的bash塞进路由器解决。
我现在运行的是4.6.0.请问如果想选择4.6.1及以后版本，是不是需要libcap-ng和libcap-ng-bin的依赖？这对发行版类linux和官方openwrt应该不成问题。发现我的半残op没有setcap。请问libcap-ng是不是内核级依赖？如果想打补丁，需要同时编译出内核mod和用户空间工具吗？
最后赞一下，把proxy_cmd改为空，脚本只凭端口来侦测服务状态，proxy命令单独操作真的好方便。但我使用4.6.0，脚本需要明确server vps的ip和port,来生成相应的netfilter。server vps和ip和port这本来应该是proxy的设置。所以作者从4.6.1开始利用鉴权来放行数据包，这样脚本和代理工具的耦合性就更低了。
可以通过 suid 权限位来解决（不过我暂时没时间验证是否可行，你可以先试下）
本质上，只是需要 透明代理本地client进程 以给定的user/group身份运行，借此来放行其传出的流量
感谢回复。刚好上午又研究了下。root权限细分cap控制，貌似需要文件系统的SECURITY特性，比如ext4编译内核的时候要config ext4_fs security=y. 即使openwrt最新的官方分支的kmod-fs-ext4这项也是no set。所以setcap在openwrt操作的时候一直显示Failed to set capabilities on file `/usr/bin/ss-redir' (Not supported)。查看您的脚本，脚本本身不关心root权限细分，只利用iptables的owner分流。所以要想个办法让代理进程以非root运行同时又具有socket blind等各种必要权限。这大概就是您说的suid权限位。libcap应该足够官方和优雅，但不知道suid是否丑陋。如果suid同样安全和优雅，脚本也许可以考虑去除libcap依赖。
感谢回复。刚好上午又研究了下。root权限细分cap控制，貌似需要文件系统的SECURITY特性，比如ext4编译内核的时候要config ext4_fs security=y. 即使openwrt最新的官方分支的kmod-fs-ext4这项也是no set。所以setcap在openwrt操作的时候一直显示Failed to set capabilities on file `/usr/bin/ss-redir' (Not supported)。查看您的脚本，脚本本身不关心root权限细分，只利用iptables的owner分流。所以要想个办法让代理进程以非root运行同时又具有socket blind等各种必要权限。这大概就是您说的suid权限位。libcap应该足够官方和优雅，但不知道suid是否丑陋。如果suid同样安全和优雅，脚本也许可以考虑去除libcap依赖。
如果你换个思路, 用 iptables -m cgroup 来 return proxy软件的流量, 那么就不需要创建普通用户, 也就不需要 setcap.
感谢回复。刚好上午又研究了下。root权限细分cap控制，貌似需要文件系统的SECURITY特性，比如ext4编译内核的时候要config ext4_fs security=y. 即使openwrt最新的官方分支的kmod-fs-ext4这项也是no set。所以setcap在openwrt操作的时候一直显示Failed to set capabilities on file `/usr/bin/ss-redir' (Not supported)。查看您的脚本，脚本本身不关心root权限细分，只利用iptables的owner分流。所以要想个办法让代理进程以非root运行同时又具有socket blind等各种必要权限。这大概就是您说的suid权限位。libcap应该足够官方和优雅，但不知道suid是否丑陋。如果suid同样安全和优雅，脚本也许可以考虑去除libcap依赖。
如果你换个思路, 用
iptables -m cgroup来 return proxy软件的流量, 那么就不需要创建普通用户, 也就不需要 setcap.
谢谢指导。我的系统是半开放古董系统，lsmod确实有xt_owner和xt_cgroup_MARK。但不知道是否系统太老了，使用iptables owner分流失败。我再用您说的cgroup试试。菜鸟弱鸡也不太懂怎么跟踪包调试，瞎试嘿嘿。
感谢回复。刚好上午又研究了下。root权限细分cap控制，貌似需要文件系统的SECURITY特性，比如ext4编译内核的时候要config ext4_fs security=y. 即使openwrt最新的官方分支的kmod-fs-ext4这项也是no set。所以setcap在openwrt操作的时候一直显示Failed to set capabilities on file `/usr/bin/ss-redir' (Not supported)。查看您的脚本，脚本本身不关心root权限细分，只利用iptables的owner分流。所以要想个办法让代理进程以非root运行同时又具有socket blind等各种必要权限。这大概就是您说的suid权限位。libcap应该足够官方和优雅，但不知道suid是否丑陋。如果suid同样安全和优雅，脚本也许可以考虑去除libcap依赖。
如果你换个思路, 用
iptables -m cgroup来 return proxy软件的流量, 那么就不需要创建普通用户, 也就不需要 setcap.谢谢指导。我的系统是半开放古董系统，lsmod确实有xt_owner和xt_cgroup_MARK。但不知道是否系统太老了，使用iptables owner分流失败。我再用您说的cgroup试试。菜鸟弱鸡也不太懂怎么跟踪包调试，瞎试嘿嘿。
越是古董系统越是能学东西.
readme已更新，简单测试了下，suid权限位是可行的。
UPDATE：刚在rpi3b上测试了，又好像不行了（上次貌似正常）。。明天再看
UPDATE：研究后发现，如果利用suid位提权，则需要利用group身份放行（反之亦然，只能suid提权，group放行）
我猜iptables-owner模块是以 effective uid/gid 来识别进程身份的，而非 real uid/gid
因为测试和查资料发现，suid/sgid文件权限位，只会影响 effective uid/gid，real uid/gid不会变的