Toolbox: 隔离开发环境以抵御正在开发的代码中的错误和恶意软件

您想要一个没有 /home 的持久用户容器吗？ 只是想更好地理解需求/用例。 - 与仅运行标准的一次性 Fedora 容器相比？

考虑一个用于家庭和工作的 Unix 帐户。 对于工作容器，我可能更喜欢仅将我的工作目录装入容器。

考虑一个不受信任的 GUI 应用程序。 它可能只需要访问特定文件夹即可加载/保存文件。 它不需要访问我的 .ssh 文件夹和其他不相关的文件。

为了提高安全性，默认情况下，Chrome OS 不会从主机将文件夹共享到容器。 在那里，如果您想从您的主目录或 USB 驱动器向容器提供数据，您可以明确地共享它。

如果默认情况下将所有数据都提供给不受信任的容器，则容器化作为安全功能将失去重要价值！

@juhp我看到你在 Haskell 包方面做得很好。 假设您远程安装的 Haskell 软件包之一已被入侵。 Haskell 软件包是否需要访问您的 .ssh 文件夹或您的比特币钱包？ 为什么默认情况下将所有内容共享到您的 Haskell 开发环境中？

最近有一个 NPM 模块，如果安装它仍然可以本地比特币：
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

该模块很受欢迎，事实上我的团队已将其安装到我们的树中。 我们不符合触发比特币盗窃的其他标准，但如果我们的开发环境默认情况下无法完全访问我们的主目录，那么这种风险就会完全减轻。 没有员工会选择将他们的比特币钱包分享到这个开发环境中。

这是完全有效的，但会很难。

实际上，我认为最好的方法是让作为独立用户运行工具箱变得容易（暂时创建新的 uid，每个 uid 都有自己的/home ）——需要一个特权系统服务来做到这一点。

现在，如果您想共享一些文件，例如只读

是否可以从目录绑定安装中排除文件/目录？

为了确保我理解挑战，我看到挂载主目录发生在一行代码中

    --volume "$HOME":"$HOME":rslave

但这里的挑战仍然是让 GUI 应用程序和其他一些功能正常工作，因为这些功能期望容器内外的用户是相同的？

这实际上是一个相当重要的功能。 我认为默认挂载 home 没问题，但应该可以以不受信任的方式使用容器。 将 home 装入容器假定您信任容器，而在一次性容器中通常并非如此。 即使在像测试一些 NPM 模块这样的简单情况下，我也希望它不会破坏我的主文件夹，让我高枕无忧。

@markstos也许你可以测试你可以在没有 home 挂载的情况下做什么，或者如果只是挂载一个特定的目录（cwd）？

@juhp实际上，这对我来说是个

如果 Fedora 想要欢迎来自其他 Linux 发行版的用户，那么在容器中轻松运行他们的旧发行版将是一个不错的起点。

@markstos谢谢 - 我只是另一个 Toolbox 用户。 :-)
我完全同意扩展 Toolbox 以支持更多操作系统确实非常有用。
请注意，Toolbox 也可以在没有 Silverblue 的情况下工作（即在其他 Fedora 版本上）。

@juhp实际上，这对我来说是个

你之前是做什么的？ 您使用的其他工具/方法是否不适用于 Silverblue？

没有什么能阻止您使用一次性 VM（类似 QubesOS），或者就此而言拥有一个自定义脚本来实现该线程中的一些建议。 可以说，我们应该更加自以为是，并将类似 QubesOS 的功能构建到 Silverblue 中。

但无论如何，现有的虚拟机和容器技术是存在的。 事实上，今天的toolbox真的是一堆脚本，故意让podman与主机模糊。 如果您不想要集成，您可以从podman run ...因为这是默认设置。

@cgwalters我已经开始在我的个人笔记本电脑上使用 Chrome 操作系统，并且已经意识到通过Crostini项目在 VM 的容器中运行我的开发环境（以及几乎所有其他东西）的安全性。 我喜欢它支持 GUI 应用程序以及命令行应用程序。 我也喜欢容器默认是私有的。 我必须明确地与他们共享数据文件夹或 USB 驱动器。 另一方面，声音和航路支持会在这些容器中自动设置。
网址
我一直在评估在我的工作笔记本电脑上使用的类似解决方案。 一种选择是 Neverware 的 Cloudready——一种用于 PC 硬件的开源 Chrome 操作系统。 有时，某些端口会导致 Crostini 崩溃、数据丢失并且需要重新开始。 出于这个原因，我现在犹豫是否要在 ChromeOS / Crostini 上加倍努力。

Silverblue 看起来也很引人注目，直到我发现它似乎不支持开箱即用的 Ubuntu 容器，并且它与我不打算信任的容器过度共享我的个人数据。 我还看了 Clear Linux。 它具有在容器中运行几乎所有内容的相同概念。 我对与英特尔和 x86 的密切联系并不感到兴奋。 它也不是主要的桌面操作系统。 最后一个（默认？）选项是坚持使用 Ubuntu 作为桌面，并将我的更多开发工作转移到 LXD 容器中，Chrome 的 Crostini 正在使用这种容器。 即使主机操作系统不同，我也应该能够在我的工作和个人笔记本电脑之间复制 LXD 容器。 使用 LXD 模板，我应该能够设置模板共享足够的安装到容器中以支持 Wayland。

旁注：感谢您多年来对 Rhythmbox 的维护！

也许我误解了toolbox的使命。 从自述文件：

.. 这些系统的目的是阻止在主机上安装软件

为什么？ 默认情况下，默认情况下将您的所有个人数据共享到容器中，我认为不能声称提高了安全性。

剩下的潜在好处是隔离，因此您可以并排安装有冲突的软件版本。

如果始终共享行为仍然存在，更新文档可能会有所帮助，阐明toolbox将您的整个主目录共享到容器中，该行为不能被禁用，并且不应与不受信任的人一起使用容器。

我知道我可以直接使用 podman，但我对具有 GUI 集成的容器解决方案感兴趣。 在搜索如何使用podman完成此操作时，推荐使用toolbox ：

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos如果您有兴趣，我已经创建了 PR #298，它构建了一个 Ubuntu 19.04 映像。

我认为这里有些混乱。

我们的README.md几个月来有所增长和变化，可能有点难以掌握。 早些时候它曾经简单地说Hacking on OSTree-based Fedoras 。

如果您安装 Silverblue（或任何其他基于 OSTree 的操作系统），调试操作系统或设置开发环境的困难立即变得显而易见。 Toolbox 的存在就是为了解决这个问题。

.. 这些系统的目的是阻止在主机上安装软件

为什么？ 默认情况下是默认将您的所有个人数据共享到容器中，我
不要认为可以声称提高了安全性。

安全是一个超载的词。 Toolbox 对此没有任何声明。

几十年来，作为您的 UID 运行的任何进程都可以查看您的私人加密密钥、文档、照片等，甚至在您不知情的情况下将它们传输到地球的另一端。 这是自由软件客户端操作系统的现状。

Flatpak通过将每个图形应用程序和操作系统分离到它们自己的安全域中来改变这种情况。 Silverblue 使直接在主机操作系统映像中安装软件变得困难，从而巩固了这种分离。 因此，为了获得流畅的用户体验，您确实需要使用作为 Flatpaks 提供的应用程序。

然而，正如我在顶部提到的，这个锁定的操作系统映像存在其自身的一系列问题。 我们如何解决这些问题是便利性和安全性之间的权衡。 解决方案越激进，现有的 Linux 用户就越难采用 Silverblue。

目前，Toolbox 倾向于采用而不是安全性； 因为无论您是否使用 Toolbox，Silverblue 确实对自由软件客户端操作系统的状态进行了大量改进，将其交到用户手中将是一个积极的步骤。

另外，这不仅仅是关于安全性。 这也与稳定性有关。

测试传统的 Linux 发行版非常困难。 包和镜像总是由世界各地随机镜像的随机贡献者更新——组合爆炸只能通过精心设计的冻结系统来管理。 当出现问题时，用户也很难恢复更新，而且更新过程中断电之类的事情可能会无法挽回地破坏系统。

基于 OSTree 的操作系统改变了这一切。

我知道我可以直接使用 podman，但我对带有 GUI 的容器解决方案感兴趣
一体化。 在搜索如何使用 podman 完成该任务时，使用工具箱是
推荐的方法：

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

问题是为什么要使用 Podman 来运行图形应用程序？ :)

通常，Podman（或 OCI 容器）对于运行 GUI 应用程序来说是一个糟糕的选择。 这就是 Flatpak 存在且 Toolbox 不与之竞争的全部原因。

然而，存在重叠，因为 Toolbox 容器确实有一些桌面集成，并且在某些情况下，运行非 Flatpaked GUI 应用程序的能力在短期内非常有用。 可能是您想要的应用程序尚未经过 Flatpaked，或者可能 Flatpaked 版本缺少某些功能。 可能是您正在处理图形应用程序使用的某个库，并且您想快速运行一次性测试程序以查看您的库是否按预期工作。

Toolbox 确实可以在这种情况下提供帮助，但这与 Toolbox 的主要目标是容器化图形应用程序不同。 Toolbox 的主要目标是让您在基于 OSTree 的操作系统上完成黑客攻击。

现在，如果您使用像GNOME Builder这样的容器原生 IDE，它作为 Flatpak 提供，并自动设置一个容器来构建和运行您正在开发的软件，那么您根本不需要 Toolbox。

然而，并不是每个人都使用 GNOME Builder，像 Visual Studio Code 这样最流行的 IDE 并不是这样的容器原生。 因此，工具箱。

@debarshiray感谢您的深思熟虑和彻底的回应。 我上面给出的示例不适用于可能被 Flatpak 覆盖的图形应用程序。 我举了做Node.js开发的例子。 最近在 Node.js 依赖链中存在真正的恶意软件，可以从本地加密钱包中窃取。 SSH 密钥也很容易被盗。 虽然自述文件说该项目针对开发人员，但默认情况下与容器共享并不能保护开发人员免受这种攻击。

在使用任何不受信任的依赖项进行 CLI 开发时，Toolbox 无法防止个人文件被盗。 鉴于现代开源软件的复杂性，依赖关系树的某些部分肯定不应该被信任。

我发现当前的自述文件具有误导性：在容器中运行“完全没有特权”听起来像安全性，但它只是安全剧院——所有个人文件都可以在容器中访问。 上面您澄清了 Toolbox 不打算对安全性做出任何声明。 我认为这将是一个有用的声明，包括在自述文件中，以澄清尽管使用了容器，但这是一个方便而不是安全的工具。

@debarshiray感谢您的深思熟虑和彻底的回应。 我举的例子
以上不适用于可能被 Flatpak 覆盖的图形应用程序。 我给了
做 Node.js 开发的例子。 最近在 Node.js 中存在真正的恶意软件
可以从本地加密钱包窃取的依赖链。 SSH 密钥可能被盗
一样容易。 虽然自述文件说该项目针对开发人员，但
share-with-containers-by-default 并不能保护开发人员免受这种攻击。

是的，目前 Toolbox 只是尝试在基于图像的操作系统中重现传统的基于包的环境。

我发现当前的自述文件具有误导性：在容器中运行“完全没有特权”
听起来像安全，但它只是安全剧场——所有个人文件都可以在
容器。 上面您澄清了 Toolbox 不打算对安全性做出任何声明。
我认为这将是一个有用的声明，包括在自述文件中，以澄清尽管
容器的使用，这是一个为了方便而不是安全的工具。

提交 c047659c1d85ca982374da5c58ee7a24ba3847bd是添加该行的地方。 我相信@cgwalters 的意图是说您只能访问工具箱容器内的自己的 UID，而真正的根目录（即主机上的 UID 0）既不涉及也不可用。

我也有同样的问题。 我安装 Silverblue 是希望我能够运行我可能不完全信任的软件，而不必担心它会窃取我的 SSH 密钥和其他敏感信息。

意识到工具箱不允许我这样做是一个巨大的失望，并促使我重新考虑开始使用 Silverblue。 就个人而言，我不关心主操作系统的安装。 我总是可以重新安装它。 我想要真正保持隔离的信息位于我的主目录中。

是否可以更精确地指定共享主目录的哪些部分？ 如果可以只将工具箱所需的目录（可能是与桌面配置相关的目录等）列入白名单，这将解决很多问题。

现在，我完全意识到安全问题。 由于我已经使用 Qubes OS 好几年了，隔离问题是一个棘手的问题。 即使您保护主目录，这也不够，因为在容器内运行的程序始终可以利用容器之间的其他通信方式，例如剪贴板。 我知道这一点，并且我愿意接受其中的一些风险，以换取与完整 Qubes 安装相比工具箱之类的东西的便利性。

此处发布

该解决方法利用了toolbox作为 bash 脚本实现的事实，该脚本在需要查找/home/user路径的所有情况下都引用环境变量$HOME 。 因此，通过为对toolbox的特定调用设置环境变量$HOME会导致一个目录而不是整个主目录中充满有价值的个人文件的目录与可能不受信任的容器共享。

基于此，您似乎可以通过使用如下包装器启动工具箱来共享一个仅包含工具箱配置的空目录：

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

如果这将脚本命名为toolbox并将您的 $PATH 放在系统toolbox ，那么它似乎可以解决这个问题。 此解决方案未经测试。

此功能现在在tlbx分支中工作： https :

我也有同样的问题。 我安装 Silverblue 希望我能够
运行我可能不完全信任的软件，而不必担心它会窃取我的 SSH
密钥和其他敏感信息。

嗯……这似乎是误导。 如果您想以用户身份运行不受信任的软件，那么 Flatpak 已经可以减少您对丢失敏感信息的担忧。 如果您想要隔离的开发环境，那就是另一回事了。

此外，这些都不是 Silverblue 特有的。 这些问题已经存在了几十年，而且解决方案并不是 Silverblue 特有的——它们也适用于传统的基于包的操作系统。

该解决方法利用了toolbox作为 bash 脚本实现的事实
在$HOME的路径的所有情况下引用环境变量/home/user
需要查查。 因此，通过为特定的环境变量设置$HOME
调用toolbox会导致一个目录而不是你的整个主目录充满了有价值的
与可能不受信任的容器共享的个人文件。

是的，这是一个巧妙的技巧。 :)

然而，Toolbox 项目的主要目标是能够在基于图像（特别是基于 OSTree）的操作系统上设置各种各样的开发环境，其工作量与基于包的对应物所需的工作量大致相同。 使这些开发环境更安全绝对是一个合理的愿望，但这并不是迫在眉睫的待办事项，因为这个问题并不新鲜，而且已经永远存在了。

Silverblue 也不一定与安全有关。 我更多地认为它是对操作系统稳定性和健壮性的改进。 但是，它确实鼓励使用 Flatpak，因此从这个意义上说，它确实间接提高了安全性。

因此，确保与基于包的 Linux 发行版的功能相同是有价值的，即使它保留了一些现有的问题。 解决一些问题并使现有用户群可以访问解决方案总比什么都不解决要好。 :)

我将关闭此问题，以便未解决的问题列表不会失控，并继续大致反映当前待办事项列表中的项目。 但是，它仍然存在以供将来参考。

不过，我确实同意我们的README.md应该更容易阅读。

嗯，我不明白这个论点。 就因为一个问题老了，一直存在，就是不解决？？ 恕我直言，这不是一个好观点。
正如您所说，flatpak 做到了这一点：它逐步提高安全性并隔离应用程序。 他们也没有说“嗯，我们一直将应用程序作为 rpm 包发布，我们为什么要解决这个问题？”，他们只是解决了它。

我看不出为什么工具箱也不应该至少隔离主目录。 所以我想讨论可以在https://github.com/containers/toolbox/issues/348 中继续进行。

我认为工具箱的贡献者和维护者正在将此线程视为对投入到项目中的想法和工作的抨击。 我认为它应该被视为许多对这个想法感到兴奋的人所需要的功能。 我不反对开发允许您挂载 $HOME 以外的工作目录的功能。 这是一个可以大大改进功能和用例的特性，这也将提高采用率和兴趣。

我是那个建议在 #348 中更改 $HOME 变量的人。 这是一个hacky 解决方案，因为当您想要使用具有不同$HOME 目录的两个多个容器时，它会导致问题。 我担心的是，当用 go 重写工具箱时，这甚至不起作用。

很多人都在要求这个功能，它已经成为很多人采用工具箱、rpm-ostree 和 silverblue 的入门障碍。 即使它与安全无关，它也是一项功能，将为使用工具箱打开很多可能性。

如果可以的话，我愿意在这个问题上提供帮助，我认为其他人也愿意。 我希望此功能不会成为争论的焦点，也不会被排除在未来的工具箱版本之外。 在我看来，这是目前唯一缺少的东西。 就像因为退出最后 10 米而在马拉松比赛中获得 dnf 一样。 （双关语：））

这对我来说是一个交易破坏者。 之后我放弃了工具箱和 Silverblue
发现这个缺陷。

仅仅因为一个问题是老问题并且永远存在，
就是不解决？？ 恕我直言，这不是一个好观点。

没有立即要做的事情与不解决它是两回事。 有一种叫做优先级的东西。

正如您所说，flatpak 就是这样做的：它逐步提高了安全性和
隔离应用程序。 他们也没有说“嗯，我们已经将应用程序作为
rpm 包永远，我们为什么要解决这个问题？”，他们只是做了
解决这个问题。

我喜欢你对他们这个词的使用。

好的，很好，所以如果我解释正确，这可能仍然是未来的一个想法，只是不在您的“即时待办事项清单”上？ （虽然我猜它很容易实现，特别是如果你可以从叉子中挑选一些补丁）*

如果是这样，也许只是保持这个问题开放并将其标记为“需要帮助”——尽管你并不真正需要帮助，不知道......是什么阻止了你实现这个？ 我想你只需要说你接受关于这个主题的 PR 并且它将被实施。
我认为没有什么能阻止你这样做——而且你仍然可以实现功能对等，无论如何……这真的只是一个小功能。 ：思维：

* 是的，我看到并知道这现在已经用 Go 重写了，但也许这仍然有帮助——不知道。 至少它表明它很容易实现。

在这里稍微劫持一下这个问题，以防任何参与者想在https://gitlab.com/bkhl/etui上查看我的原型并提供反馈

当您想要一个更严格包含的开发容器时，它可以作为 Toolbox 的替代品。

@bkhl谢谢！ 书签。