我正在重制一个基于 Ubuntu 的发行版，该发行版仅供实时使用，主要用作浏览器，以便用户硬盘在线时不受病毒侵害。此实时浏览功能为 Linux 用户增加了安全性，但作为 Windows 和 Mac 用户硬盘的守护者，它的作用不大。这是一个很好的邀请，让用户了解 Linux 操作系统可以提供哪些功能来帮助保护他们选择的操作系统。我正在添加一个简单的老派教程，以便他们可以使用所有浏览器和用户空间自定义功能重制它。
大多数用户都希望密码管理器能够帮助他们登录帐户。我使用的是 Firefox，但一旦使用主密码打开 Firefox 密码管理器，任何知道如何发出请求的服务都可以不受阻碍地访问所有加密密码。因此，我决定使用独立的密码管理器，它将提供一些权限灵活性来帮助解决这些问题。Keepassx 一直是主要选择。
存在一个类似的问题，即恶意代码可以访问 Keepassx 数据库，因为恶意代码和 Keepassx 在在线用户空间中共享相同的权限。
为了增加安全性，我正在考虑更改 Keypassx 权限，以便在线用户无法访问 Keepassx 数据库，除非用户输入管理员密码。从逻辑上讲，这会使攻击者更难访问。不过，我对设置安全环境还不熟悉。因此我的问题...
考虑到用户将使用 Firefox 在线，强制 Keepassx 仅在 Ubuntu 上以 root 用户身份启动是一个好主意且安全吗？
答案1
在这一点上我可能错了，但据我理解，如果你赋予一个实用程序 root 权限，而它被恶意代码破坏，那么恶意代码也会获得 root 权限。
据我了解，出于这个原因，Ubuntu 处理安全性的方式与其他发行版不同。它不安装 root 用户。当该用户作为管理员需要 root 权限时，它会安装一个获得 root 权限的用户。一旦任务完成或达到时间限制，具有管理员访问权限的用户将失去 root 权限。这降低了恶意代码获得 root 访问权限的风险。
这就是为什么在 Ubuntu 中我们不使用“su”而是在终端命令前使用“sudo”。通过限制对 root 权限的使用，我们限制了恶意代码获取访问权限并造成损害的机会。
这是我的理解来源的文档：
Ubuntu 使用 sudo 而不是 su 或 root 的原因
我强烈建议你考虑一下 Ubuntu 开发人员这样做的理由。正是这些理由让我认为你打算做的事情是不安全的。
我引用官方文档：
默认情况下，Ubuntu 中的 Root 帐户密码是锁定的。这意味着您无法直接以 Root 身份登录或使用 su 命令成为 Root 用户。但是，由于 Root 帐户物理存在，因此仍然可以以 root 级权限运行程序。这就是 sudo 的作用所在 - 它允许授权用户（通常是“管理员”用户；有关更多信息，请参阅 AddUsersHowto）以 Root 身份运行某些程序，而无需知道 root 密码。
答案2
嗯，以 root 身份运行应用程序有两个不同的方面；其中一个方面可以提高安全性，另一个方面可能会危及安全性——我认为混合这两个方面可以解释你的困惑。
运行应用程序作为另一个用户（可能是 root 用户，但不是必需的）使另一个进程更难以访问该应用程序拥有/创建的文件并执行其他恶意操作（例如，发送 KILL 信号）。这很好。
如果某个应用程序恰好存在漏洞（即向其发送一些特殊格式的输入使其通过缓冲区溢出等方式执行某些代码），那么在利用该漏洞后，攻击者将能够以该进程的权限执行代码。从这个意义上讲，以 root 权限运行应用程序是不好的，因为它会将最高级别的权限授予攻击者。
现在您了解了以 root 身份运行更新管理器或许如果它包含一个错误，允许特制的 .deb 文件使其崩溃并使其执行某些代码，那就很糟糕了。但是，以超级用户权限运行某些应用程序（例如包管理器）是不可避免的，因为它们会修改系统的重要部分。
解决此问题的常见方法是在程序启动时执行所谓的“特权删除”；这通常用于运行 Web 服务器和其他可能被利用（并可从外部访问）的软件。这个想法很简单：程序以 root 身份启动，但尽快切换到具有尽可能少特权的用户帐户（无 shell 登录、chroot 到其主目录等）。这样，即使受到攻击，攻击者也只能获得非常有限的系统访问权限。此外，其他用户帐户（超级用户除外）将无权访问应用程序的文件
我不确定运行这样的桌面应用程序有多么容易。
实际上，在这种情况下，我认为网页浏览器作为非特权用户更有意义。当然，Google 也为我们提供了有关该主题的一些链接：
将这个想法发挥到极致（正如您在评论中所建议的那样）将为您提供一个与 Android 的工作方式类似的系统；在 Android 上，每个应用程序都在其自己的用户帐户内运行，因此它只能访问自己的文件。这可能在 Ubuntu 中存在一些问题，即如果您使用在受限帐户中运行的 Firefox 下载文件，它只能将其保存在自己的主文件夹中，因此无法在文本处理器（以另一个用户身份运行）中打开该文件...
关于启动器脚本，我猜想该脚本将以 root 身份启动并以各自的用户身份调用应用程序。该脚本显然需要只有 root 才能写入。阅读设置用户标识。
答案3
不，这不是个好主意。它可能会破坏，并可能允许升级到 root。
确保密码数据库不被以同一用户身份运行的其他进程意外或恶意泄露并非易事，但值得一试。但是，最好在 Keypassx 项目的上游完成这项工作，并且使用除以 root 身份运行之外的其他方法。