使用seteuid临时删除root权限是否有缺陷 [英] Is it flawed to use seteuid to drop root privilege temporarily

查看:41
本文介绍了使用seteuid临时删除root权限是否有缺陷的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我从一些书中读到 seteuid 与 euid 和保存的 UID 一起可以用来临时删除 root 权限.案例是:

I read from some books that the seteuid together with euid and saved UID can be used to drop root privilege temporarily. The case is:

  1. 将 euid 设置为非 root 用户.
  2. 做一些不需要 root 权限的事情.
  3. 再次将 euid 设置为 root(这样做有效,因为 root 仍然是保存的 UID).

我认为这是有缺陷的.在第 2 步中,一些恶意代码也可以调用 seteuid 到 root,因此这种丢弃 root 权限的方法并不能阻止劫持代码获得 root 权限.我的分析正确吗?如果是这样,seteuid-on-saved-UID 可以用来做什么?

I think this is flawed. During step 2, some malicious code could also invoke seteuid to root so this method of dropping root privilege doesn't prevent hijacking code from gain root privilege. Is my analysis correct? If so, what could seteuid-on-saved-UID be used for?

推荐答案

您担心恶意代码也可能将有效 UID 恢复到保存的 UID 是合理的.如果您对此感到担忧,也许您一开始就不应该使用 setuid root 程序.(LD_PRELOAD 和其他类似的东西通常令人担忧;当程序以 setuid 权限运行时,它们也会受到限制.)

Your concern that the malicious code might also restore the effective UID to the saved UID is legitimate. If you are concerned about this, maybe you should not be using a setuid root program in the first place. (LD_PRELOAD and other such things are worrisome in general; they are also restricted when a program is running with setuid privileges.)

但是,该机制通常用于分叉的子进程,子进程将在没有提升权限的情况下执行其他一些进程,因为已执行的进程不会保留保存的 UID.如果恶意代码设法在 exec() 之前接管,那么您仍然有问题.在exec()之后,恶意代码只拥有真实UID的权限,用户可以做任何恶意代码所做的事情.

Often, though, the mechanism is used in a forked child, where the child will execute some other process without the elevated privileges because the saved UID won't be retained by the executed process. If the malicious code manages to take over before the exec(), then you still have problems. After the exec(), the malicious code only has the privileges of the real UID, and the user could have done whatever it is that the malicious code did.

这篇关于使用seteuid临时删除root权限是否有缺陷的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆