Setuid 与 GTK+

发布于 2024-10-12 10:00:58 字数 170 浏览 2 评论 0原文

我正在尝试编写一个程序并将其与使用 Gtk+ 构建的 gui 集成。然而，由 GUI 调用的 exe 已设置了 setuid 位。但是 gtk 不允许此 exe 按照 gtk 社区的指定运行。然而他们说我们必须编写单独的帮助程序等等。我真的不明白这意味着什么。任何人都可以阐明如何克服这个问题吗？我真的需要一个立即的解决方案。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

拥醉 2024-10-19 10:00:58

第一个问题：为什么你的程序是setuid？编写 setuid 程序不适合自称 Linux 新手的人玩。他们很危险。它们很有用——不要误会我的意思。但它们很危险并且难以安全地写入。

GTK+ 项目在“GTK+ - 使用 setuid”中非常直率地阐述了他们对 setuid 程序的看法。他们给出了自己的理由——很好的理由。它们指出了如何避免问题：

GTK+团队认为，编写具有图形用户界面的setuid程序的唯一正确方法是拥有一个setuid后端，通过管道等机制与非setuid图形用户界面进行通信，并且认为它收到的输入是不可信的。

既然您应该编写一个帮助程序，您是否寻找过示例？他们很可能是被给予的。你的程序本身是一个GUI应用程序吗？

我需要root权限[...]来打开一些外围设备，读取其内存中的可用数据，然后关闭它们...如果没有root权限，这是无法完成的...读取的数据也会被处理并且使用GTK同时显示。

所以，这正是 GTK+ 团队所描述的场景。您需要一个由 GUI 启动的小型 setuid root 程序，并通过管道或 Unix 域套接字或某种类似技术与其连接。

当您需要来自外设的数据时，您的主应用程序向守护程序/帮助程序写入请求，然后等待包含数据的响应。

概括地说，您的 GUI 中将包含以下代码：

LaunchDaemon()：这将创建管道（管道或套接字）、分叉，并且子进程将在启动守护进程之前整理文件描述符（关闭不需要的内容）过程。
RequestDaemon()：这将打包对守护进程/帮助程序的请求，将信息写入守护进程，并读回响应。
TerminateDaemon()：这将关闭与守护程序/帮助程序的连接；它会知道它没有更多的工作要做并将退出。

同时，您的守护程序/帮助程序将：

进入一个舒适的循环：
- 从标准输入读取请求
- 检查其有效性
- 执行请求
- 格式化响应（错误或正常）
- 将其写回主 GUI
- 重复
当从输入中获取 EOF 时，它终止。
如果可能的话，它将打开设备一次，然后放弃 root 权限。
- 这可以最大限度地减少遭受攻击的风险。
- 如果程序不再以 root 身份运行，则不能滥用它来执行只有 root 才能执行的操作。
- 文件打开后，不会再次检查权限（因此，以 root 身份运行的守护进程可以打开该文件，如果不重新打开该文件，则放弃其 root 权限）。

您仍然应该查看外围设备上的权限是否正确 - 或者为什么您需要从只有 root 才能读取的数据中读取数据。

First question: why is your program setuid? Writing setuid programs is not a game that should be played by self-professed Linux newbies. They're dangerous. They're useful - do not get me wrong. But they are dangerous and difficult to write securely.

The GTK+ project states their view on setuid programs very forthrightly at 'GTK+ - Using setuid'. They give their reasons - good ones. They indicate how to avoid problems:

In the opinion of the GTK+ team, the only correct way to write a setuid program with a graphical user interface is to have a setuid backend that communicates with the non-setuid graphical user interface via a mechanism such as a pipe and that considers the input it receives to be untrusted.

Since you're supposed to write a helper program, have you looked for examples? It is likely that they're given. Is your program itself a GUI application?

I need root privileges [...] to open some peripheral devices, read the data available in their memory, and then close them...this cannot be done without root perms...also the data read is processed and displayed simultaneously using GTK.

So, this is exactly the sort of scenario that the GTK+ team describe. You need a small setuid root program that is launched by your GUI, and that is connected to it by pipes or a Unix-domain socket, or some similar technique.

When you need data from the peripheral, your main application writes a request to the daemon/helper and then waits for a response containing the data.

In outline, you will have code in your GUI to:

LaunchDaemon(): this will create the plumbing (pipes or socket), fork, and the child will sort out the file descriptors (closing what it does not need) before launching the daemon process.
RequestDaemon(): this will package up a request to the daemon/helper, writing the information to the daemon, and reading back the response.
TerminateDaemon(): this will close the connections to the daemon/helper; it will know that it has no more work to do and will exit.

Meanwhile, your daemon/helper program will:

Settle into a nice comfy loop that:
- reads a request from standard input
- checks it for validity
- executes the request
- formats a response (error, or normal)
- writes that back to the main GUI
- repeats
When it gets EOF from the input, it terminates.
If at all possible, it will open the device once, and then drop root privileges.
- This minimizes the exposure to attack.
- If the program is no longer running as root, it cannot be abused into doing things that only root can do.
- Once a file is open, the permissions are not checked again (so the daemon running as root can open the file, and then throw away its root privileges, if it won't reopen the file).

You should still look at whether the permissions on the peripheral are correct - or why you are needing to read data from something that only root is supposed to be able to read from.

回复收藏 0 原文

厌倦 2024-10-19 10:00:58

我认为，当 GTK+ 团队在这里警告不要在 setuid 中使用 GTK+ 时，他们的心是对的。程序。但我有两个观察结果和一个解决方法。

首先，警告这种做法是一回事，而让这种做法看似不可能则完全是另一回事。想到那些设计师说“用户没有正当理由去做 XXX”，然后又不遗余力地让 XXX 变得不可能，这让我很恼火。警告风险，让用户承担风险。

其次，GTK+团队混淆了“setuid”和“setuid root”。下面的例子说明了这种区别的重要性。在这个例子中，我不想扩大使用 GTK+ 的程序的权限，而是减少它们。在某些情况下，我希望能够运行 Firefox（好吧，iceweasel，但它基本上是相同的），使其只能查看本地文件，而没有网络功能。因此，我在 Linux 系统中设置了 iptables，以便特定的（人为创建的）用户无法访问外部世界。我希望能够以该用户身份运行 Firefox，无论我实际上是哪个用户。假设受限用户的uid和gid为1234，则以下总体思路将起作用。将其构建为 setuid root。希望这有帮助。

编辑 2014-02-22 15:13 UTC

我忘了提到你可以用 0 代替每个 1234，然后你就获得了 root 权限。有人可能会说这是一个完全糟糕的主意，我想我可以理解这一点。

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main(int    ar_argc,
     char **ar_argv
    )
{
  setenv("HOME","/u/wally",1);

  /* Set other environment variables as appropriate. */

  if(setgid(1234))
  {
    fprintf(stderr,"setgid() fail\n");
    exit(1);
  };
  if(setuid(1234))
  {
    fprintf(stderr,"setuid() fail\n");
    exit(1);
  };

  /* Use execl() and friends, or system(), to do what you want here. */

  return 0;
}

I think that the GTK+ team's heart is in the right place when they warn here against using GTK+ in setuid programs. But I have two observations, and a workaround.

First, it is one thing to warn against such a practice, and another thing entirely to make such a practice seemingly impossible. It irritates me to think of designers who say "There is no valid reason for users to do XXX", and then go out of their way to make XXX impossible. Warn of the risk, and let the user take the risk.

Second, the GTK+ team confuses "setuid" with "setuid root". Here's an example of where the distinction is important. In this example, I want not to expand the privileges of a program using GTK+, but to reduce them. Under certain circumstances, I want to be able to run Firefox (well, iceweasel, but it's basically the same) crippled so it can look at only local files, with no network capability. So I've set up iptables in my Linux system so that a particular (artificially created) user has no access to the outside world. I want to be able to run Firefox as that user, no matter which user I actually am. Assuming that the restricted user's uid and gid are 1234, the following general idea will work. Build it as setuid root. Hope this helps.

EDIT 2014-02-22 15:13 UTC

I neglected to mention that you can substitute 0 for each 1234, and you've got root. One could argue that this would be a totally bad idea, and I guess I can understand that point.

#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main(int    ar_argc,
     char **ar_argv
    )
{
  setenv("HOME","/u/wally",1);

  /* Set other environment variables as appropriate. */

  if(setgid(1234))
  {
    fprintf(stderr,"setgid() fail\n");
    exit(1);
  };
  if(setuid(1234))
  {
    fprintf(stderr,"setuid() fail\n");
    exit(1);
  };

  /* Use execl() and friends, or system(), to do what you want here. */

  return 0;
}

回复收藏 0 原文