☰

虚拟机/操作系统

tag-icon • tag-icon permissions non-root-user jails
虚拟机/操作系统

如果我是 root，我可以简单地创建一个虚拟用户/组，相应地设置文件权限并以该用户身份执行该过程。但我不是，那么有什么方法可以在不root的情况下实现这一点呢？

答案1

更多类似的问题，更多值得关注的答案：

笔记：那里的一些答案指向此处尚未提及的具体解决方案。

实际上，有相当多的监狱工具具有不同的实现，但其中许多工具要么在设计上不安全（例如fakeroot，LD_PRELOAD基于），要么不完整（例如fakeroot-ng，ptrace基于），或者需要root（chroot，或者plash在fakechroot 警告标签）。

这些只是例子；我想将它们全部并排列出，并标明这两个功能（“可以信任吗？”，“需要 root 才能设置？”），也许在操作系统级虚拟化实现。

一般来说，那里的答案涵盖了所描述的全部可能性，甚至更多：

虚拟机/操作系统

内核扩展（如 SELinux）

  • （在这里的评论中提到），

chroot

基于 Chroot 的帮助程序（但是必须是 setUID root，因为chroot需要 root；或者可能chroot可以在隔离的命名空间中工作 - 见下文）：

[详细介绍一下他们！]

已知的基于 chroot 的隔离工具：

跟踪

另一个值得信赖的隔离解决方案（除了seccomp基于a的) 将是通过 的完整系统调用拦截ptrace，如联机帮助页中所述fakeroot-ng:

与以前的实现不同，fakeroot-ng 使用的技术使被跟踪进程无法选择是否使用 fakeroot-ng 的“服务”。静态编译程序、直接调用内核以及操作自己的地址空间都是可以用来绕过基于 LD_PRELOAD 的进程控制的技术，并且不适用于 fakeroot-ng。从理论上讲，可以通过完全控制跟踪过程的方式来塑造 fakeroot-ng。

虽然理论上可行，但尚未实现。 Fakeroot-ng 确实对被跟踪的进程做出了某些“行为良好”的假设，而打破这些假设的进程即使不能完全逃脱，也可能能够绕过 fakeroot 强加给它的一些“假”环境—— ng。因此，强烈警告您不要使用 fakeroot-ng 作为安全工具。声称某个进程可以故意（而不是无意中）逃脱 fakeroot-ng 控制的错误报告将被关闭为“不是错误”或被标记为低优先级。

未来可能会重新考虑这项政策。不过，目前您已收到警告。

不过，正如您所读到的，fakeroot-ng它本身并不是为此目的而设计的。

（顺便说一句，我想知道为什么他们选择seccomp对 Chromium 使用基于 - 的方法而不是ptrace基于 - 的方法......）

对于上面没有提到的工具，我已经注意到了乔尔迪对于我自己来说，因为我喜欢用 Haskell 编写控制程序。

已知的基于 ptrace 的隔离工具：

安全计算

实现隔离的一种已知方法是通过Google Chromium 中使用的 seccomp 沙箱方法。但是这种方法假设您编写了一个帮助程序，它将处理一些（允许的）“拦截的”文件访问和其他系统调用；当然，还要努力“拦截”系统调用并将它们重定向到帮助程序（也许，这甚至意味着在受控进程的代码中替换拦截的系统调用；所以，这听起来并不像很简单；如果您有兴趣，您最好阅读详细信息而不仅仅是我的答案）。

更多相关信息（来自维基百科）：

（如果有人正在 Chromium 之外寻找基于通用seccomp的解决方案，最后一项似乎很有趣。“seccomp-nurse”的作者还有一篇博客文章值得一读：SECCOMP 作为沙盒解决方案？.)

这种方法的说明来自“seccomp-护士”项目:

                      在此输入图像描述

Linux 未来可能出现“灵活”的 seccomp 吗？

2009年也曾出现过给Linux内核打补丁的建议这样seccomp模式就有了更大的灵活性——这样“我们目前需要的许多杂技就可以避免”。 （“杂技”是指编写一个助手必须代表被监禁进程执行许多可能无辜的系统调用以及在被监禁进程中替换可能无辜的系统调用的复杂性。）LWN 文章写到这一点：

提出的一个建议是向 seccomp 添加一种新的“模式”。 API 的设计理念是不同的应用程序可能有不同的安全要求；它包括一个“模式”值，该值指定应实施的限制。仅实现了原始模式，但当然可以添加其他模式。创建一种允许启动进程指定允许哪些系统调用的新模式将使该工具对于 Chrome 沙箱等情况更加有用。

Adam Langley（也是 Google 的）已经发布了一个补丁来实现这一点。新的“模式 2”实现接受描述哪些系统调用可访问的位掩码。如果其中之一是 prctl()，那么沙盒代码可以进一步限制其自己的系统调用（但它无法恢复对已被拒绝的系统调用的访问）。总而言之，这看起来是一个合理的解决方案，可以让沙箱开发人员的生活变得更轻松。

也就是说，这段代码可能永远不会被合并，因为讨论已经转向其他可能性。

这种“灵活的 seccomp”将使 Linux 更接近于在操作系统中提供所需的功能，而无需编写如此复杂的帮助程序。

（与此答案内容基本相同的博客文章：http://geofft.mit.edu/blog/sipb/33.)

命名空间 ( unshare)

通过命名空间隔离（unshare基于的解决方案）——这里没有提到——例如，取消共享挂载点（与 FUSE 结合？）可能是您想要限制不受信任进程的文件系统访问的工作解决方案的一部分。

现在，更多关于命名空间的信息，因为它们的实现已经完成（这种隔离技术在 nme 下也被称为“Linux 容器”，或“LXC”，不是吗？..）：

“命名空间的总体目标之一是支持容器的实现，容器是一种轻量级虚拟化工具（以及其他目的）”。

甚至可以创建一个新的用户命名空间，这样“一个进程可以在用户命名空间之外拥有普通的非特权用户ID，同时在命名空间内拥有0的用户ID。这意味着该进程拥有完全的root权限对于用户命名空间内的操作，但对于命名空间之外的操作没有特权”。

对于执行此操作的实际工作命令，请参阅以下位置的答案：

和特殊的用户空间编程/编译

但是，当然，所需的“监狱”保证可以通过在用户空间中编程来实现（无需操作系统对此功能的额外支持;也许这就是为什么这个功能没有被首先包含在操作系统设计中的原因）；或多或少有并发症。

其中提到的ptrace-或者seccomp基于沙箱可以看作是通过编写沙箱助手来实现保证的一些变体，沙箱助手可以控制其他进程，这些进程将被视为“黑匣子”、任意 Unix 程序。

另一种方法可能是使用可以关心必须禁止的效果的编程技术。 （那么程序一定是你写的；它们不再是黑匣子了。）举个例子，使用纯编程语言（这会迫使你在没有副作用的情况下进行编程）就像哈斯克尔只会使程序的所有效果显式化，因此程序员可以轻松确保不会有不允许的效果。

我猜想，对于那些使用其他语言（例如 Java）进行编程的人来说，有沙箱设施可用。

那里的答案中还指出了一些积累有关该主题的信息的页面：

答案2

这是 unix 权限模型的一个基本限制：只有 root 可以委派。

您不需要成为 root 来运行虚拟机（并非所有虚拟机技术都如此），但这是一个重量级解决方案。

用户模式Linux是一个相对轻量级的Linux-on-Linux虚拟化解决方案。设置起来并不容易；您需要填充根分区（在目录中），至少使用启动所需的最少内容（ 中的一些文件/etc及其/sbin/init依赖项、登录程序、外壳程序和实用程序）。

答案3

我想您可能会幸运地LD_PRELOAD拦截对某些文件的访问，但这可能非常棘手。

答案4

从完整列表中我只需添加：

  • fakeroot（来自 debian package maintener）：它的目标是使用“友好”工具构建包。这不是完全隔离，但它有助于使用不同的用户和假设备以及其他特殊的伪文件构建包。

  • fakechroot（使用 fakeroot）。这个程序有很多错误。例如，“/etc/hosts”在 glibc 中是硬编码的：您无法通过此工具更改它。

  • qemu ：你需要编译一个linux内核，但结果非常快，而且这是一个具有真正root权限的“假”（即虚拟）机器。您可以构建并安装任何启动映像。

相关内容