Linux 中如何保护互不信任的应用程序的文件

Linux 中如何保护互不信任的应用程序的文件

我正在运行 Ubuntu Linux 机器。当我运行由不同供应商(例如 Chrome 和 Firefox)编写的应用程序时,我注意到它们都在使用我的 uid 运行。但如果是这种情况,他们在文件系统上创建的任何文件也将具有相同的 uid。那么在 Linux 中,两个互不信任的应用程序如何保证文件彼此的安全呢?

  • 应用程序 A 使用 ACL 策略仍可能允许应用程序 B 读取 A 的文件 - 通过(用户、组、其他)的用户部分
  • 应用程序是否需要使用加密来保护彼此的数据?

答案1

字面上的答案是,不存在在您的帐户下运行的不受信任的应用程序。如果要运行不受信任的应用程序,请在不同的帐户下或在虚拟机中运行它。

典型的桌面操作系统(例如 Unix 和 Windows)和典型的移动操作系统(例如 Android 和 iOS)具有不同的安全模型。 Unix 是一个多用户操作系统,用户之间互不信任。应用领域被认为是可信的:用户的所有应用程序都在同一安全上下文中运行。服务另一方面,不太受信任:它们通常在专用帐户下执行,以减少出现安全漏洞时的影响。

Unix 安全模型如此工作有两个主要原因:

  • 消极的原因是历史:当设计 Unix 时,应用程序来自一小群程序员,并得到供应商声誉的支持或作为源代码提供,或两者兼而有之。在应用程序中很少有人担心后门。此外,很少有应用程序通过网络进行通信,因此触发和利用漏洞的机会相对较少。因此,没有强烈的动机将应用程序彼此隔离。
  • 一个积极的原因是功能:隔离应用程序使很多事情变得不可能。如果每个应用程序都有自己的数据区域,那么应用程序之间共享数据就会变得困难。在典型的 Unix 系统上,多个应用程序处理相同的数据是很常见的。由于 Unix 在“应用程序”和“操作系统”之间没有明确的区分,因此尤其如此。网络浏览器是一个应用程序。由于浏览器仅限于其自己的目录,因此无法将文件下载到您选择的目录中,这很烦人。登录时显示菜单和图标的程序也是具有相同基础的应用程序。文件管理器也是如此,根据定义,文件管理器需要访问您的所有文件。到处执行脚本的 shell 和其他解释器也是如此。当您从文字处理器打印文档时,这可能涉及将文档转换为可打印格式的应用程序,以及将数据发送到打印机的另一个应用程序。

尽管现在的应用程序作者比 40 年前多得多,但应用程序通常仍然通过带有信誉指示的可信渠道进行分发。 (这对于 Linux 来说明显比 Windows 更真实,这也是 Windows 下病毒更常见的部分原因。)发现有后门的应用程序会立即从 Linux 软件存储库中删除。

移动操作系统在设计时考虑到了不同的威胁。它们是为单用户系统设计的,但其应用程序来自完全不受信任的来源。

应用程序隔离正开始进入桌面 Unix 系统。一些发行版在安全框架下运行某些程序,例如应用装甲或者SELinux这限制了应用程序可以执行的操作。这些安全限制的代价是它们有时会导致无法实现所需的用途,例如阻止受限制的应用程序打开某些目录中的文件。

加密将完全没有用。加密仅保护数据在途中(通过网络)或在休息(存储在磁盘上),它不会保护实时系统上的数据 - 如果子系统 A 解密了其数据,那么操作系统将阻止子系统 B 阻止访问解密的数据,因此无论是否数据已被 A 解密或未加密存储。操作系统可能会对数据进行加密,但只是为了在存储介质被盗时保护数据。

如果您想运行您不信任的代码,最好的办法是在虚拟机中运行它。仅允许虚拟机访问应用程序需要的文件(例如,不要共享您的主目录)。

也可以看看为什么移动应用有细粒度的权限,而桌面应用没有?为什么移动设备的应用程序比桌面设备的应用程序受到更多限制?

答案2

我喜欢吉尔斯的回答,但还有另一个方面需要考虑:

unix 的一个原则是每个程序都应该“做好一件事”。

程序不应该变得如此庞大和复杂,以至于用户无法预测运行程序的结果。如果一个正确的 UNIX 程序接触到一个文件,那是因为你告诉它触摸该文件。程序应该做的事情不应多于或少于用户告诉它们的事情,这一想法阻止了它们以用户不希望的方式进行交互。

这个原则的一个极端例子是:几乎没有人再使用的旧 UNIX 邮件阅读器之一,elm在创建用于保存其配置文件 ( ~/.elm/) 和邮件文件夹 ( ~/Mail/) 的目录之前会请求您的批准。如果你说“不”,它会回复

Very well, but you may run into difficulties later.

我最近尝试运行的一些程序(抱歉我忘记了哪个)证明了相反的极端,它拒绝启动并且没有给出任何关于问题所在的线索。strace显示它想要创建一个名为 的目录~/.config/,但不能,因为我有一个名为该名称的常规文件。 (我曾经cp .config ~从内核源代码树中完成过,所以我有一个备份。)显然,现在认为在没有通知(更不用说批准)甚至最小错误检查的情况下踩踏用户主目录中非常通用的名称是合理的。

进步。

相关内容