这是一个创建于 1451 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近开发的运维平台，在平台上提交 shell 脚本，然后在远程主机上跑。
现在需求是要对提交的 shell 脚本进行高危操作检查，例如 rm -rf /*之类的。
假如发现，不予以提交。
考虑了好久，目前实现思路是按行读取提交的 shell 脚本，然后用正则识别 rm -rf /*之类的语句。
不知道有没有其他更好的检测方案。
第 1 条附言 · 2020-12-02 16:49:23 +08:00
感谢大家的回复
其实我对这个需求也很困惑，
其实生产主机作为研发是碰不到的，加权限控制范围的操作现在应该也有，不过不是我们研发能控制的。
刚跟上面聊了一下，这个需求还是要做。
现在就是具体怎么实现的问题
用正则表达式去匹配，有点麻烦，我担心在 shell 中各种复杂的写法下特别容易误判。
平台是用 python 做的，不知道 python 下有没有解析 shell 语法的第三方库。
其实我对这个需求也很困惑，
其实生产主机作为研发是碰不到的，加权限控制范围的操作现在应该也有，不过不是我们研发能控制的。
刚跟上面聊了一下，这个需求还是要做。
现在就是具体怎么实现的问题
用正则表达式去匹配，有点麻烦，我担心在 shell 中各种复杂的写法下特别容易误判。
平台是用 python 做的，不知道 python 下有没有解析 shell 语法的第三方库。
 |
1
QBugHunter 2020-12-02 15:01:38 +08:00
？？？？
你设好权限，怕啥？ 脚本没权限能 rm -rf /*? |
 |
2
piaochen0 OP @QBugHunter #1
1.上面要求在提交的时候，就要对危险操作进行拦截。 2.不光是 rm -rf /*这种，还有其他的危险度比较高的操作，例如操作没有加范围，不允许 alias 操作等等。 3.生产主机环境比较复杂，权限什么的，有些不是我们能控制的。 |
 |
3
lvzhiqiang 2020-12-02 15:37:25 +08:00
我觉得还是权限控制比较靠谱， 比如只允许在某个目录区域进行操作（限定在 /app 目录）、只允许执行某些命令（比如 reboot 命令，就不允许普通用户执行）、屏蔽访问某些文件，否则的话，只能用穷举规则匹配咯，比如这种 cat /dev/zero > /dev/sdb ； 反正各种骚操作，只有你想不到，没有做不到。
|
|
4
QBugHunter 2020-12-02 15:42:42 +08:00
@piaochen0
那感觉这个要求有点本末倒置了，就比如 rm,不用-rf /*,运气好 rm 一个文件就足以让服务器嗝屁。 就以 rm 为例，怎么设置呢？，发现有 rm 就判断为危险显然不可能，rm 是 shell 里一个很常见的操作。那就用正则表达式匹配 rm 的文件？貌似也不太现实，你要列出系统里所有不能 rm 的文件名？ 再者,对面脚本会生成一个中间文件，结束前要删除，但这个文件名可能和你系统里某个数据文件相同（用正则表达式匹配相同），然后喜闻乐见你把这个脚本直接判断为危险，然后呢？ 服务器的安全问题，靠检测脚本始终是个不靠谱的行为 |
 |
5
Cbdy 2020-12-02 15:47:08 +08:00
人工 review
|
 |
6
westoy 2020-12-02 15:48:18 +08:00
容器 + selinux/grsecurity/apparmor 之类的做沙盒
识别个蛋蛋啊， 执行三方程序、写到某个 rc 里、替换掉动态连接库 ， 要乱搞， 骚操作多的是 |
 |
7
cmostuor 2020-12-02 15:56:41 +08:00
之前看华为光猫里有个实现方法 用 shell 脚本写个判断参数是否安全脚本去代替危险命令 比如 rm 把原本的文件改名, 用脚本写个判断参数是否安全的脚本 只有参数是安全才调用相应的原本的命令 不安全就返回错误
也可以修改 bash 或 zsh 在其 applet 里添加参数是否安全的风控代码 |
 |
8
lululau 2020-12-02 17:07:43 +08:00
什么样的命令属于危险的操作，这个是需求吧，让提需求的人给出来个列表来啊
|
 |
9
timi 2020-12-02 17:34:26 +08:00
如果是控制别人，可用堡垒机，也可用强制访问控制软件，保护重要数据
|
 |
10
37Y37 2020-12-02 17:53:52 +08:00
脚本任何人都能提交，但需要审核，审核过的脚本才能执行
so 审核一下 |
 |
11
thedrwu 2020-12-02 19:29:11 +08:00 via Android
楼主试过 `rm -rf $H0ME/*` 吗
|
 |
12
ajinwu 2020-12-02 21:19:48 +08:00 via Android
除了权限，其他防住很难，因为 payload 可以自行组合，很难识别
|
 |
13
linux40 2020-12-02 21:23:47 +08:00 via Android  1
缺个搞 shell 程序分析的。其实程序分析的需求很大，就是不怎么招人。招这种职位的只有几个大厂。
正则表达式太弱了，你需要带有语义的分析工具。 |
 |
16
freeair 2020-12-03 09:52:31 +08:00
运维上，shell 应该经过测试才正式运行吧，版本应该是受控的。
楼主的问题感觉不是运维这个纬度的，更像是安全层面的，代码扫描，像是要重新造轮子，仅能作为权宜之计。 |
 |
18
aloxaf 2020-12-03 14:48:07 +08:00
你这玩意儿看上去是给自己人用的，
那就不需要考虑故意构造复杂的 payload 来攻击的情况了，不然你这项目肯定是没法做的。 既然这样你随便糊弄一下，啊不，检查一下就行了，比如直接扔给 shellcheck 。 |
 |
19
lamesbond 2020-12-03 16:27:27 +08:00
这需求真迷惑，上份工作运维，上面要求在生产主机上操作尽量别用脚本，把命令先复制到记事本，前面加上#号，再粘贴到命令行窗口，能用 tail 或 head 就不用 cat，能用 cat 就别用 vim，修改文件前先备份文件等等，这就不是代码能检测出来的。
生产环境别让开发上手最好，要就做好权责划分，出问题谁背锅先说好 |
 |
20
Sterne 2020-12-03 17:21:07 +08:00
直接提交脚本这种操作方向错了。
正确的做法是把常用的脚本固定下来，添加参数支持，研发只能传入参数去调用。 |
Select Language