Linux非root用户运行服务实践

前言

以前就知道如果Linux服务以非root的方式运行会增强系统的安全性,但如何去实践呢?

Linux安全基础

安全设计原则

  • 最小安全原则
  • 纵深防御,提供多因素防护机制

一般应尽可能缩小权限的授予范围

技术手段

  • 用户隔离
  • rwx读写执行权限
  • capability特权权限
  • PAM体系pam_cap模块
  • ACL等

简单非root用户运行方案

一般的应用,用非root用户做隔离,对于文件仅所有者拥有读写、执行、权限,同组内和其它组的用户可以根据场景,设定合理的权限就可以完成。

原则就是最小安全原则,不过多授予权限!

涉及特权的的方案

粗浅介绍

对于某些需要添加和修改系统的IP,和创建RAW套接字的应用,那么在rwx基础权限和用户隔离的基础上,需要通过setcap操作进行特权授权,但整体上玄机并不多。

可以看到rwx为整个安全控制的基础,与capability特权权限形成权限检查链条,某一环节的卡壳,就会可以造成服务不可用。

简单场景,我们依然将这些需要特权的服务部署在以用户隔离的目录下,并设定合理的rwx权限,然后以root用户身份,通过setcap操作授予特权用户目录下某(些)启动程序获得特权。

即使这些用户具有一些特权,但是,由于是非root用户,对于其它用户的文件资源,并不能偷窃,这也实现了一定程度的安全性。

不过,最好的实践是依赖systemd.service机制,进行外围的包装。

特权集介绍

这个概念纠缠的原因就在于实际上区分了,进程特权集和文件特权集。特别在可继承特权集的设定上,完全是南辕北辙。

  • 进程可继承特权集是南向的,面向下游进程树传播
  • 文件可继承特权集是北向,会与上游进程的南向特权集进行相与判断

进程/线程特权集

  • CapInh = Inheritable capabilities

决定在进程树下如何进行特权继承,注意,此处需要区分是否capabilities aware,后续进程启动二进制文件是否主动进行了setcap授权

  • CapPrm = Permitted capabilities

允许的特权集

  • CapEff = Effective capabilities

当前特权集

  • CapBnd = Bounding set

系统可用特权集

  • CapAmb = Ambient capabilities set

环境特权集,并没有通过setcap授权的连带程序如何自动获得特权的机制

文件特权集

  • e

可以生效的特权集

  • p

允许的特权集

  • i

决定是否从上游继承某些权限

对于文件通过setcap能够借助root用户授予特权属性,又可以看作Linux一切都可以看做文件的深入设计

优先级最高

相对于Ambient capabilities set的自动传播,如果某文件特殊设定了特权集,则以文件中明确设定的为准,见特权生效算法介绍

最佳实践

次优

在服务中存在某个根启动程序,从此启动程序可以创建出一颗进程树出来,但仅需对此根启动程序通过setcap文件特权集进行授予权限,其它涉及的程序并不进行主动设定。

通过根程序进程的Inheritable capabilitiesAmbient capabilities set,在进程树内进行特权权限的传递、传播。

与docker容器特权传递类似,营造成一个环境出来

最佳之systemd.service机制

  • AmbientCapabilities

配置字段可以配置环境特权集

  • User

运行服务的隔离用户

不用特殊实现根启动程序,依赖系统自身初始化启动程序

例子

[Unit]
Description=Check raw socket privilege Using RAW socket
After=network.target

[Service]
Type=simple
User=cap
AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN
ExecStart=/usr/bin/checkraw -s
ExecStop=/bin/kill -HUP $MAINPID
TimeoutStartSec=360
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

ambient环境特权集弱点

相比较于对每个设计文件进行setcap授权,通过Inheritable capabilitiesAmbient capabilities set进行传播特权的方式,相当于粗放管理,但是,部署会比较简便。

在恶意攻击的i情况下,攻破这个进程树的某一个进程,就可以获取到比较多的特权。

补充

PAM的孱弱

通过pam_cap模块,PAM aware程序,例如,susudo程序,见/etc/pam.d/下对应的配置,启动后的进程自动获得在/etc/security/capability.conf中根据用户配置/可继承权限Inheritable capabilities

但是,因为pam_cap模块版本的限制,并不能设置Ambient capabilities set,对于未经setcap授权二进制文件所启动的进程,并不能形成很好的权限传递和传播!

在libcap-2.58+版本支持了Ambient capabilities set的设置

pam_cap失效的一种原因

按照man中的介绍,在/etc/security/capability.conf中配置auth optional pam_cap.so并不能生效的原因是因为,配置在PAM鉴权栈中如果遭遇requisitesufficient很早就提前返回了,并不能将配置生效!

参考链接

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值