子用户、利益还是责任？

Question

我正在linux上尝试各种沙箱解决方案。我习惯于在selinux沙箱中运行不受信任的程序(例如，web浏览器、pdf文档阅读器等)，我对此相当满意，但有一个问题:它只支持rhel/fedora。AFAIK其他发行版并不真正支持selinux (即使他们说支持selinux，他们也不提供可用的策略或文档)，而且即使提供了一个准工作策略，策略核心-沙箱也是不可用的(参见debian)。

什么是多发行版的沙箱解决方案？我正在尝试docker/subuser，它允许我启动一个docker容器，运行感兴趣的应用程序，并且只允许它访问文件系统的一部分。例如，我可以在一个码头容器中运行“chrome”，让它只访问我的下载目录。

这似乎是一个方便的解决方案，因为它独立于发行版，并且不需要我安装我计划运行的程序及其对主机的依赖。

但是，我不太确定“子用户安全”：https://github.com/subuser-security/subuser中有多少安全性。

首先，docker还不支持用户名称空间。这意味着每个“容器”都在我的主机上作为根用户运行，即使它是由lxc隔离的。这也意味着，如果我遵循子用户的建议，我必须将我的用户添加到docker组。因为dockerd以root方式运行，所以对它的访问意味着我可以作为root完全访问整个主机文件系统，我可以运行特权容器等等。如果这没有启用权限提升(我希望即使不是来自‘来宾’应用程序)，我不知道它是什么。

此外，假设我在子用户中运行chrome。现在，我在根用户下面的另一个沙箱中禁用了它的沙箱(少一个层)，运行一个chrome浏览器。简单地在没有特权的用户下使用它的沙箱运行chrome真的有好处吗？

我无法限制它对我的主目录的访问，但除此之外，我看不出有什么理由更喜欢子用户/docker。

还有其他独立发行版的解决方案吗？

我开始认为最不麻烦的解决方案就是简单地使用标准unix用户。每个应用程序都有一个用户，可能会安装一个应用程序及其在本地、~bin等项下的依赖关系。

哪个包管理器支持将包树作为用户安装在用户的主目录中？是否有任何第三方linux包管理器支持这一点？

如何在用户之间共享文件？我正在考虑在本地主机上运行一个非特权的ftp守护进程的可能性，比如说作为一个“标准”或“存储”用户，并使用虚拟用户将该家庭dir的部分(例如/ home /me/app/let下载)导出到其他用户、应用程序，并通过fuse安装。

这合理吗？

Answer 1

我是蒂莫西·霍布斯，“子用户”的作者。我希望您首先阅读我的文章关于子用户的安全理念，以便您能够看到我的目标。我的目标是保护广大用户免受工厂攻击，而不是保护特定目标用户免受NSA/其他邪恶组织的攻击。

First of all, docker doesn't yet support user namespaces. This means that every 'container' runs as root on my host, even if it's isolated by lxc.

虽然当前版本的子用户仍然将映像构建为根用户，但除非专门指定这样做，否则子用户不会以root用户的身份运行。

this also means that, if I follow subuser's recommendations, I have to add my user to the docker group. since dockerd runs as root, having access to it means that I have full access to the whole host filesystem as root, I can run privileged containers, etc. If this isn't enabling privilege escalation (even if not from 'guest' apps, I hope), I don't know what it is.

确实，Docker (因此，子用户)给予普通用户完全根权限。我确实认为这是码头的一个缺陷。如果码头工人不帮我，我一定会设法减轻这个问题。但是，在单个用户系统上，我不认为正常用户拥有根访问是一个安全问题。因为如果有人控制了正常用户，这和根一样糟糕。这确实是一个你想要保护什么的问题:系统完整性或者你的数据和你的隐私。

furthermore, let's say that I'm running chrome in subuser. Now I have a chrome browser running with its sandbox disabled (one less layer) inside another sandbox under the root user. Is it really a benefit from simply running chrome with its sandbox under an unprivileged user?

Chrome是一个特例。这是我遇到的唯一有这个限制的程序。我不建议您在子用户中运行chrome。

I'm starting to think that the least cumbersome solution would be to simply use standard unix users. One user per application, maybe install an app and its dependencies under ~local, ~bin, etc.

在设计子用户时，我当然考虑了这种方法。然而，用户之间共享文件要么是混乱的、不安全的，要么是两者兼而有之。此外，不能简单地将其他用户的x11窗口显示到用户的x11服务器上。您必须设置XPRA、VNC、RPC或其他网络解决方案。这是乏味的，子用户的主要目标之一是消除这种设置的单调乏味。

which package managers support installing a package, mantaining a package tree, as a user inside a user's home directory? are there any third party package managers for linux that support this?

有许多软件包管理器支持将程序安装为正常用户。您可以在子用户网站上看到一个不完整的列表http //subuser.org/related-projects.html (不足以发布超过2个链接)。只要向下滚动直到你到达零安装。当然，这些包管理器在安全性方面不做任何事情。

这合理吗？

子标识工具包http //ccl.cse.nd.edu/software/subid/ (不足以发布两个以上的链接)提供了一个名为subuserchown的工具，它可以帮助用户之间共享文件。