Linux 访问控制机制：利用 POSIX 功能提升权限

参考来源 https://dfir.ch/posts/linux_capabilities/

前情提要

在 Linux 系统中，传统上有两种主要的权限提升机制：SUID（设置用户 ID）和 SGID（设置组 ID）。这些机制允许用户在执行特定二进制文件时临时获得文件所有者或组的权限，通常是 root 用户。然而，这种方法存在安全风险，因为它授予了过多的权限，可能导致系统被滥用。
为了解决这些问题，Linux 引入了 POSIX 能力（Capabilities）机制。该机制允许将 root 用户的权限划分为更小、更具体的单元，这些单元可以单独分配给进程。这种方法提高了系统的安全性，因为它允许仅授予进程所需的最低权限，从而减少了潜在的攻击面。

Capabilities是 Linux 中的一种细粒度访问控制机制，允许比传统超级用户 ( root) 模型更精细的权限。权能将通常与 root 用户关联的权限划分为不同的单元，这些单元可以针对不同的进程单独启用或禁用。这使得权限管理更加安全可控。

例如，某个进程可能需要绑定到特权端口的权限，但不需要任何其他提升的权限。通过使用能力，系统管理员可以更好地控制进程的权限，从而减少潜在的安全风险。
要了解我们的 Linux 主机知道多少功能，我们可以查询目录cap_last_cap内的文件/proc：

1
2

# cat /proc/sys/kernel/cap_last_cap
40

该capsh –print命令显示 shell 或调用该命令的进程的当前功能及相关设置。在我们的 Linux 主机上执行此命令时，我们可以看到完整的功能列表。

1
2
3

# capsh --print
Current: =ep
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore

每种能力都对应一个特定的特权操作。

Python 后门

该命令setcap用于设置可执行文件的文件权限。该cap_setuid权限允许进程对用户 ID (UID) 进行任意操作，包括将 UID 设置为原本受限制的值（例如UID 0root 用户）。该命令setcap接受一组参数，其中

1
2

e：有效表示该功能已激活
p：允许表示可以使用/允许该功能。

综上所述，我们将向cap_setuidPython 二进制文件添加以下功能：

1

# setcap cap_setuid+ep /usr/bin/python3.12

您可以在这里找到支持的功能列表：

1

# cat /usr/include/linux/capability.h

测试
为了测试目的，我们创建了一个新用户（malmoeb）并切换到该用户的上下文（useradd && su）：

1
2
3
4

# useradd -m malmoeb
# su malmoeb
$ id
uid=1000(malmoeb) gid=1000(malmoeb) groups=1000(malmoeb)

使用以下命令行，我们将使用 Python 调用的 bash shell 的 UID 设置为 0 ( UID 0 == root)，从而有效地生成一个 root shell：

1
2
3
4

$ /usr/bin/python3 -c 'import os;os.setuid(0);os.system("/bin/bash")'
# id
uid=0(root) gid=1000(malmoeb) groups=1000(malmoeb)

这种技术令人兴奋的地方在于，我们并没有在二进制文件上设置 suid 位，也没有修改 Python 二进制文件。通过设置权限，我们作为攻击者可以构建一个强大的后门。

应用

传统上，系统管理员和安全专业人员专注于查找SUID（设置用户 ID）和SGID（设置组 ID）文件，因为这些文件可用于在特定条件下提升权限。然而，随着 POSIX 功能的引入，查找设置了功能的文件现在也同样重要，如上所示。

使用以下命令可以枚举所有设置了功能的二进制文件getcap -r

1
2
3
4
5

# getcap -r / 2>/dev/null
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper cap_net_bind_service,cap_net_admin,cap_sys_nice=ep
/usr/bin/mtr-packet cap_net_raw=ep
/usr/bin/ping cap_net_raw=ep
/usr/bin/python3.12 cap_setuid=ep

在 /proc 目录内：

1

# cat /proc/1143966/status | grep Cap

在哪里：

1
2
3
4
5

CapInh= 继承的能力
CapPrm= 允许的能力
CapEff= 有效能力
CapBnd= 边界集
CapAmb= 环境功能设置

利用命令capsh，我们解码功能如下：

1
2

# capsh --decode=0000000000000080
0x0000000000000080=cap_setuid

或者使用命令getpcaps，将 PID 作为参数传递：

1
2

# getpcaps 1143966
Capabilities for `1143966': = cap_setuid+ep

使用以下命令从二进制文件中移除功能setcap -r

1

# setcap -r /usr/bin/python3.12

科学估算服务器资源需求

参考来源 https://mp.weixin.qq.com/s/zklAxdcU6j78QaYwM7CLYA

CPU 资源估算公式和方法

CPU 的估算相对来说比较复杂，因为不同类型的应用对 CPU 的需求差别很大。我总结了一套比较实用的计算方法。

基础 CPU 需求计算公式

1

CPU 核心数 = (并发用户数 × 单用户 CPU 消耗 × 安全系数) / CPU 利用率目标

这里面几个关键参数：

• 并发用户数：同时在线并产生请求的用户数
• 单用户 CPU 消耗：每个用户请求平均消耗的 CPU 时间
• 安全系数：通常取 1.5-2.0
• CPU 利用率目标：建议控制在 70%以下

不同应用类型的 CPU 需求参考表

实际计算示例

假设我们有一个电商网站：

• 预期并发用户：2000 人
• 应用类型：复杂业务系统
• 单用户 CPU 消耗：150ms
• 安全系数：1.8
• CPU 利用率目标：70%
  计算过程：

1

CPU 核心数 = (2000 × 0.15 × 1.8) / 0.7 = 771 / 0.7 ≈ 11 核

所以建议配置 12-16 核 CPU。

内存需求精确计算

内存的估算相对简单一些，但也有一套科学的计算方法。

内存需求计算公式

1

总内存需求 = 系统基础内存 + 应用内存 + 连接内存 + 缓存内存 + 预留内存

各组件内存需求详细表格

连接内存计算公式

1

连接内存 = 最大连接数 × 单连接内存占用

不同服务的单连接内存占用：

• HTTP 连接：2-8KB
• 数据库连接：1-4MB
• WebSocket 连接：4-16KB

实际内存计算案例

还是以电商网站为例：

• 并发用户：2000 人
• 技术栈：Java + MySQL + Redis
• 数据量：用户数据 50 万条，商品数据 10 万条

建议配置 24GB 或 32GB 内存。

存储空间规划计算

存储的估算看起来简单，实际上坑也不少。我整理了一套比较完整的计算方法。

存储需求计算公式

1

总存储需求 = 业务数据 + 日志文件 + 备份空间 + 系统文件 + 增长预留

不同数据类型的存储需求表

日志文件存储计算

1

日志存储需求 = 日请求量 × 单条日志大小 × 保留天数

存储计算实例

电商网站存储需求计算：

建议配置 250GB SSD + 500GB HDD 的组合。

网络带宽需求计算

网络带宽经常被忽视，但其实很重要。看公式！

带宽需求计算公式

1

所需带宽(Mbps) = 并发用户数 × 平均页面大小(MB) × 8 × 安全系数 / 页面加载时间(秒)

不同业务场景的带宽需求表

带宽计算实例

电商网站带宽需求：

• 并发用户：2000 人
• 平均页面大小：5MB
• 目标加载时间：2 秒
• 安全系数：2.0

计算过程：

1

所需带宽 = 2000 × 5 × 8 × 2.0 / 2 = 40,000 Mbps = 40 Gbps

这个结果明显偏高，说明需要优化：

1. 使用 CDN 减少源站压力
2. 图片压缩和懒加载
3. 静态资源缓存

优化后实际需求可能只需要 200-500Mbps。

数据库资源专项计算

数据库的资源需求和应用服务器不太一样，需要单独考虑。

数据库 CPU 计算公式

1

数据库 CPU 需求 = (QPS × 平均查询时间 × CPU 使用率) / 1000

不同数据库的资源需求对比表

数据库类型	CPU 效率	内存需求	存储 IO	适用场景
MySQL	中等	中等	高	通用 OLTP
PostgreSQL	高	中等	中等	复杂查询
MongoDB	中等	高	中等	文档存储
Redis	高	高	低	缓存/会话
Elasticsearch	低	高	高	全文搜索

数据库内存分配建议表

数据库性能基准测试表

注：QPS 数据基于标准 OLTP 场景，实际性能会因查询复杂度而变化

容器化环境资源计算

现在容器化部署越来越流行，资源计算方式也有所不同。

容器资源计算公式

1

容器总资源 = Σ(单容器资源 × 副本数 × 资源超分比)

Kubernetes 资源配置参考表

服务类型	CPU Request	CPU Limit	Memory Request	Memory Limit	副本数建议
Web 前端	100m	500m	128Mi	512Mi	3-5
API 服务	200m	1000m	256Mi	1Gi	3-10
数据库	1000m	2000m	2Gi	4Gi	1-3
缓存服务	100m	500m	512Mi	2Gi	2-3
消息队列	200m	800m	512Mi	2Gi	2-3

容器资源超分配比例表

ROI 计算公式

1

投资回报率 = (收益增长 - 成本增长) / 成本增长 × 100%

比如通过性能优化，响应时间从 3 秒降到 1 秒，转化率提升 20%，月收入增加 10 万，而优化成本只有 2 万，那么 ROI 就是 400%。

监控指标和告警阈值设置

监控系统一定要做好，这是运维的眼睛。我总结了一套完整的监控指标体系。

核心监控指标阈值表

应用层监控指标表

性能测试和容量规划

光有理论计算还不够，性能测试是验证估算准确性的重要手段。

性能测试场景设计表

测试类型	并发用户数	持续时间	目标指标	测试目的
基准测试	10-50	10 分钟	QPS	建立基线
负载测试	预期并发	30 分钟	响应时间	验证正常负载
压力测试	1.5× 预期	15 分钟	系统不崩溃	找到性能瓶颈
峰值测试	3× 预期	5 分钟	快速恢复	验证突发处理
稳定性测试	0.8× 预期	24 小时	无内存泄漏	长期稳定性

性能测试工具对比表

工具	适用场景	并发能力	学习成本	报告质量
JMeter	通用 Web 测试	中等	中等	好
wrk	简单 HTTP 测试	高	低	一般
LoadRunner	企业级测试	很高	高	很好
Artillery	Node.js 友好	中等	低	好
Gatling	高性能测试	很高	中等	很好

实际案例：电商平台完整资源规划

让我用一个完整的案例来演示整个资源估算过程。

业务需求分析
某电商平台预期指标：

• 注册用户：100 万
• 日活用户：10 万
• 峰值并发：5000 人
• 商品数量：50 万
• 日订单量：1 万单
• 图片文件：100 万张

详细资源计算过程

1. Web 服务器资源计算

CPU 需求：

1
2
3
4
5
6

并发用户：5000 人
单用户 CPU 消耗：100ms（复杂业务）
安全系数：1.8
CPU 利用率目标：70%

CPU 核心数 = (5000 × 0.1 × 1.8) / 0.7 = 1286 核

考虑到单机限制，建议配置：8 台 × 16 核 = 128 核

内存需求：

2. 数据库服务器资源计算

预估 QPS：

• 查询 QPS：2000
• 写入 QPS：500
• 总 QPS：2500

根据性能基准表，需要 8 核 16GB 配置，考虑到安全系数，建议 16 核 32GB。

3. 缓存服务器资源计算

Redis 内存需求：

• 用户会话：10 万 × 2KB = 200MB
• 商品缓存：5 万 × 10KB = 500MB
• 查询缓存：预估 1GB
• 总计：1.7GB × 1.5 = 2.6GB

建议配置 4 核 8GB。

4. 存储需求计算

5. 带宽需求计算

使用 CDN 优化后：

• 动态内容：5000 用户 × 100KB × 8 / 2 秒 = 2Gbps
• 考虑安全系数：2Gbps × 1.5 = 3Gbps
• 实际配置：500Mbps（CDN 分担大部分流量）

最终配置方案

动态扩容策略

静态配置往往无法应对业务的快速变化，动态扩容策略很重要。

自动扩容触发条件表

扩容成本效益分析

扩容方式	响应时间	成本增加	适用场景
垂直扩容	5-10 分钟	50-100%	短期突发
水平扩容	2-5 分钟	20-50%	持续增长
预热扩容	即时	10-30%	可预期峰值

写在最后

服务器资源估算确实是个技术活，需要综合考虑业务需求、技术架构、成本预算等多个因素。通过这些公式和表格，我们可以更科学地进行资源规划：

核心要点回顾：

1. CPU 估算：基于并发用户数和单用户消耗计算
2. 内存估算：分组件计算，预留 20%安全空间
3. 存储估算：考虑数据增长和备份需求
4. 带宽估算：结合 CDN 优化，避免过度配置
5. 成本控制：对比不同方案，选择最优性价比

实用建议：

• 基于实际业务需求估算，不要拍脑袋决定
• 预留适当的扩容空间，但不要过度设计
• 重视监控和性能测试，数据说话
• 根据实际运行情况及时调整优化
• 考虑动态扩容，应对业务变化

最重要的是，要有持续优化的意识。系统上线只是开始，后续的监控、调优、扩容才是重头戏。技术在发展，业务在变化，资源配置也要跟着调整。

没有完美的架构，只有合适的架构。资源估算也是一样，关键是要找到性能、成本、可靠性之间的平衡点。

• ngrok下载
• 生成网站证书

  1 2 3 4 5

  openssl genrsa -out rootCA.key 4096 openssl req -x509 -new -nodes -key rootCA.key -subj "/CN=kebyn.cc" -days 36500 -out rootCA.pem openssl genrsa -out device.key 4096 openssl req -new -key device.key -subj "/CN=kebyn.cc" -out device.csr openssl x509 -req -in device.csr -CA rootCA.pem -CAkey rootCA.key -CAcreateserial -out device.crt -days 36500

• 替换 ngrok 默认证书

  1 2 3

  cp rootCA.pem ../assets/client/tls/ngrokroot.crt cp device.crt ../assets/server/tls/snakeoil.crt cp device.key ../assets/server/tls/snakeoil.key

• 非 root 用户

  1

  sudo GOOS=darwin GOARCH=386 make release-all && sudo GOOS=darwin GOARCH=amd64 make release-all &&sudo GOOS=linux GOARCH=386 make release-all && sudo GOOS=linux GOARCH=amd64 make release-all &&sudo GOOS=linux GOARCH=arm make release-all && sudo GOOS=linux GOARCH=arm64 make release-all &&sudo GOOS=windows GOARCH=386 make release-all && sudo GOOS=windows GOARCH=amd64 make release-all

• root 用户

  1

  GOOS=darwin GOARCH=386 make release-all && GOOS=darwin GOARCH=amd64 make release-all && GOOS=linux GOARCH=386 make release-all && GOOS=linux GOARCH=amd64 make release-all && GOOS=linux GOARCH=arm make release-all && GOOS=linux GOARCH=arm64 make release-all && GOOS=windows GOARCH=386 make release-all && GOOS=windows GOARCH=amd64 make release-all

• 在一般 Linux 當機的狀況下，若要重新啟動系統，可以按住 Alt + SysRq 兩個鍵，然後依序按下以下幾個指令鍵：

  1	r e i s u b

  阅读全文 »

Linux下调试串口服务器的命令

1
2
3
4
5
6
7
8
9
10
11

minicom -D /dev/ttyUSB0 -H -w -o

  - -D 指定串口设备

  - -H 使用16进制输出

  - -w 滚屏输出

  - -o 不对设备进行初始化

  - -c on/off 输出开启颜色

Windows 下调试串口服务器的软件

• common

1. Unpack it.

   1 2	tar –xvzf Ocsinventory-Agent-2.0.x.tar.gz cd Ocsinventory-Agent-2.0.x

2. Check perl configuration with the script Makefile.PL. Its looks at the configuration of Perl, machine, libraries … and it generates the Makefile. During this step, we will create a temporary environment variable to install agent non-interactively.

   1	env PERL_AUTOINSTALL=1 perl Makefile.PL

   Exemple :
   Please install Crypt::SSLeay if you want to use SSL.
   Please install nmap or ipdiscover if you want to use the network discover feature.
   Please install Proc::Daemon and Proc::PID::File if you want to use the daemon monde.
3. Compilation

   1 2	make make install

引用

1
2

$ ssh-add ~/.ssh/id_rsa.pub
Could not open a connection to your authentication agent.

You might need to start ssh-agent before you run the ssh-add command:

1
2

eval `ssh-agent -s`
ssh-add ~/.ssh/id_rsa

1
2

ssh -T git@github.com
ssh -Tv git@github.com

github-testing-your-ssh-connection

1
2
3
4

openssl genrsa -des3 -out server.key 2048
openssl rsa -in server.key -out server.key
openssl req -sha256 -new -key server.key -out server.csr -subj '/CN=localhost'
openssl x509 -req -sha256 -days 36500 -in server.csr -signkey server.key -out server.crt

https://stackoverflow.com/questions/10175812/how-to-create-a-self-signed-certificate-with-openssl

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

$ cat cert.pem
-----BEGIN CERTIFICATE-----
MIIDJDCCAgwCCQDIHbBXyn2dyDANBgkqhkiG9w0BAQsFADBTMQswCQYDVQQGEwJD
TjERMA8GA1UEBwwIc2hhbmdoYWkxEDAOBgNVBAoMB3F6c3RlY2gxHzAdBgNVBAMM
FmdpdGxhYi5pbmMucXpzdGVjaC5uZXQwIBcNMTcwODAxMDk1OTA0WhgPMjExNzA3
MDgwOTU5MDRaMFMxCzAJBgNVBAYTAkNOMREwDwYDVQQHDAhzaGFuZ2hhaTEQMA4G
A1UECgwHcXpzdGVjaDEfMB0GA1UEAwwWZ2l0bGFiLmluYy5xenN0ZWNoLm5ldDCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKaAZnlgevlhWR3djmFxZgcX
Pwy2PiWpgr4kXQGAbCMTS2ouiTYvSW6rr9ofRv39G7yxSc7Rah6N1f9y6y9/itR7
C2vMSM/GHMX8zvLt49PFNjhIYv1Nd38VBoXSxz72yp+iagCKooYC9Zn+mEQlmAbJ
/zv9T8UiYTeV9FMHYO3HoTlet/tYeBmWr5ukEncBt5fxfM3yGuipR721qUCD0Hub
mXx3r/YJ5LerSjS6SBug2i8lusSkF6mRJUNyF58ouNAqnj4RFGgmwdwuRZn0TVF7
SWL9kDIB9dxi/pu1AFPBpxq/T7fgxuR6EdCO5Gu/QTZdGDpWoKqN5UgfWQwvzcEC
AwEAATANBgkqhkiG9w0BAQsFAAOCAQEAKivEQXuW3KfxeucuCE2ovCuHgzd5RP6k
RRUTDpufPmD8JH3b1vn0r4lq+u2WppwkFhlx99O89zygzuT19UtefUQ5Fgll0dbQ
vfgICiRvQFoYw427QWUS29Z4wNZM384TkCkWPoh7zzsIz8EBzAbv8a/OcTIcsYYu
QCrozqhqMnetHqhz7D9ShWAxP7rKGgf3lTC0ehpax8b6P24Q1Yuk3BsB6ErrAMCD
FXoIW/a9jy9lgm1oIeBvGSWZCaoVE+4x3JYhtozpx1WlapdRxEYvNxzpcF7o35MS
Ff9AHyLdYUqN4Q4IdwYOmpQnfN/dZhx5aAGjvcs/iQms/Ed92CKs4g==
-----END CERTIFICATE-----

1
2

$ git config --local http.sslCAInfo /path/cert.pem
$ git config --local --unset http.sslCAInfo

1
2

$ git config --local http.sslVerify false #NO NEED TO USE THIS
$ git config --local --unset http.sslverify

• Copy CA cert to /usr/local/share/ca-certificates.

  1 2	sudo update-ca-certificates sudo service docker restart

1. opevpn 服务器开启

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

   port 1194 proto udp dev tun ca ca.crt cert xxx.crt dh dh2048.pem server 10.8.0.0 255.255.255.0 //openvpnIP段 ifconfig-pool-persist ipp.txt //分配的地址记录在ipp.txt client-config-dir ccd //个人单独配置文件 client-to-client //客户端可以互相连接 keepalive 10 120 comp-lzo user nobody group nogroup persist-key persist-tun status /tmp/openvpn-status.log log /tmp/openvpn.log verb 4 mode server //运行模式 tls-server //tls加密 topology subnet //使用服务端子网 push "topology subnet" //通知客户端使用子网 auth-user-pass-verify /etc/openvpn/checkpsw.js via-env //密码认证 client-cert-not-required //不认证证书 username-as-common-name //使用用户名区别不同用户 script-security 3 route 192.168.2.0 255.255.255.0 10.8.0.2 //使用这个子网 push "route 192.168.2.0 255.255.255.0 10.8.0.2" //通知客户端使用子网 route 10.8.0.0 255.255.255.0 10.8.0.1 //使用这个子网 push "route 10.8.0.0 255.255.255.0" //通知客户端使用子网 route 192.168.3.0 255.255.255.0 10.8.0.2 //使用这个子网 push "route 192.168.3.0 255.255.255.0 10.8.0.2" //通知客户端使用子网

2. 连接到openvpn服务器

• 开启路由转发

  1 2 3

  echo 1 > /proc/sys/net/ipv4/ip_forward sudo iptables -A FORWARD -i eth0 -j ACCEPT sudo iptables -A FORWARD -i eth1 -j ACCEPT

3. 配置路由
   • 可以在路由器上配置全局路由
   • 下面是需要连接 openvpn 的单独配置
     • Windows 需要cmd 管理员窗口执行:
       route add 10.8.0.0 mask 255.255.255.0 10.0.0.1
     • Linux 需要sudo 权限执行:
       ip route add 10.8.0.0/24 via 10.0.0.1

可以在各个网络出入口使用 tcpdump 抓包判断网络情况

1. ##403

There are no projects with trackers for which you can create an issue!

1. Issue statuses问题状态
   - 设置问题状态

2. Trackers跟踪标签
   - 设置跟踪标签,跟踪标签中需要设置问题状态

3. Roles and permissions角色和权限
   - 设置跟踪标签的权限，给予new issue权限

   阅读全文 »