click 和 .deb 包之间有什么安全区别？

Question

安装一个随机的（讨厌的？）. deb 可能很危险，因为它会授予安装的应用程序和守护程序的所有权限，因为 .deb 有一些配置要求应用，如果用户在安装过程中验证了他的密码。

Click package 不需要密码（据我测试）。

单击包对系统/用户数据更安全还是相同？为什么？

一些非常值得回答的方面：

• click 和 deb 是基于同一个系统 (dpkg) 吗？
• apparmor 可以提供对没有密码或其他东西的应用程序的 root 访问权限吗？
• 是否会在安装时提示用户接受应用程序的访问权限（类似 android 的示例：此应用程序将能够扫描您的 /home 和访问网络）或在需要权限时运行（类似浏览器的示例）询问使用凸轮的权利）？
• 接近这个问题： .apk 和 click 是否相同（关于政策和用户故事）？
• 主要是：应用程序是否可以通过点击将我所有的私人数据发送到网络上而不让我明确知道它，或者它是否至少有用户验证的权利来这样做，或者无论如何它会在沙箱中被阻止？
• 诚然：点击包功能不那么强大（限制更多的东西），但更安全？

Answer 1

注意：我在 Ubuntu 安全团队工作，并帮助设计了 Ubuntu 的应用程序限制故事。为了清楚起见，我重新表述了问题。

问：“就系统和用户数据而言，点击包会更安全还是一样？”

A：总的来说，就系统和用户数据而言，点击包比 deb 更安全。

Click 包不包括像 deb 包那样在安装时以 root 身份运行的维护者脚本。点击包被简单地解包，然后如果点击声明，则使用系统提供的钩子。例如，单击可能声明使用桌面挂钩生成桌面文件或 AppArmor 挂钩为应用程序生成 AppArmor 配置文件。因为 deb 打包具有维护者脚本的概念，旨在允许对软件或系统进行广泛的定制，所以 deb 包只能从受信任的来源安装，例如来自像 Ubuntu 这样的发行版的签名存档。Click 软件包可能会直接安装，您可以合理地确定软件包安装不会破坏您的系统。然而，这只是故事的一部分——如果你从不受信任的来源安装了一个点击包，

单击的真正力量在于它与具有强大策略的软件存储库结合使用时。例如，从 Ubuntu App Store 安装的 click 包的安全性通常高于从受信任存档安装的 deb 的安全性。这是因为在 Ubuntu App Store 中，信任模型将应用程序视为不受信任*，并且制定了政策和检查以确保商店中的点击包具有适当的安全清单，因此在非常严格的限制下运行。与 Ubuntu 存档中的 deb 包相比——信任模型是软件和 deb 包被认为是受信任的，并且通常软件不会在限制下运行（尽管有很多例外，AppArmor 配置文件随软件一起提供）以防止安全漏洞）。

• 受信任的软件包也可以通过 Ubuntu App Store 交付。虽然不常见，但它们通常由 Canonical 开发，并且可能会或可能不会在限制下运行。

要回答您的具体问题：

问：click 和 deb 是基于同一个系统吗？

A： click 的低级包格式是 deb。但是，单击打包要简单得多，因为它使用声明性清单和挂钩，而不是传统的打包文件和维护者脚本。

问：AppArmor 能否在没有用户交互的情况下提供对应用程序的特权访问？

答： AppArmor 是 root 强大的，可以根据定义的安全策略允许或拒绝对系统资源（文件、DBus、网络等）的访问。单击包本身不需要运送 AppArmor 安全清单或运送“安全”的 AppArmor 安全清单。使系统安全的是点击和提供点击包的商店的策略的组合。通过 Ubuntu App Store 交付的点击包将使用非常严格的 AppArmor 策略，并且不允许在后台执行特权操作（例如，在此策略下运行的应用程序无法在后台执行系统上的程序，访问您的 facebook 帐户，窃取您的 gpg 或 ssh 密钥，操纵网络等）

问：是否会在安装时提示用户授予对应用程序的访问权限，就像在 Android 上一样？（例如，“此应用程序能够扫描您的 /home 和访问网络”）

答：不可以。使用低级工具可以在没有提示的情况下安装单击包本身。在 Ubuntu 上，点击包应该通过 Ubuntu 应用商店安装（见上文），并且由于 Ubuntu 应用商店策略结合点击功能和 Ubuntu 系统，不需要点击、无上下文的安装提示。Ubuntu 可以做到这一点，因为从 Ubuntu App Store 安装的应用程序在限制性的限制下运行（即它们不能在幕后做坏事），并且当应用程序需要额外访问时，它会使用受控 API 执行此操作，其中可能包括提示。

在特权 API 的情况下，我们有可信助手的概念，这样用户将有一个上下文提示来允许或拒绝访问（使用（可选）可撤销缓存，因此不会每次都询问用户）。例如，如果应用程序需要访问位置服务（受信任的助手），则在应用程序尝试使用位置服务时将提示用户允许访问，这提供了上下文，以便用户可以做出知情决定。视频和音频录制也会发生同样的情况。通常，我们根本不需要安全提示，我们可以根据用户驱动的与应用程序的交互来允许访问。例如，如果应用程序想要上传图片，则会出现一个对话框来选择图片。在幕后，因为应用程序不允许访问 ~/Pictures 目录，它将使用内容中心 API，该 API 将启动图库文件选择器，供用户选择要上传的图片。然后内容中心从图库中获取图片并将其提供给应用程序。在这种方式下，没有安全对话，只有用户的自然交互，但在幕后，有一个隐含的信任决定。

问：与此问题相关：.apk 和 click 在政策和用户体验方面是否具有相似的语言？

A：不会，由于上述原因，没有安装提示。为 Ubuntu 定义的点击包的 Android 权限和安全权限有一些相似之处，但不同且实现方式不同。

问：具体来说，通过单击，应用程序是否可以在我不知情的情况下通过网络发送我的所有私人数据，还是会以某种方式加以限制以防止这种情况发生？

答：如果您从不受信任的来源安装点击，是的，它可以做任何事情。如果您从 Ubuntu App Store 安装一个点击，不，应用程序无法通过网络发送您的所有数据，因为它无法访问它。当然，一个应用程序可能会做一件事，做另一件事，所以如果用户授予对位置服务的访问权限或让应用程序访问图片，那么该应用程序可能会因该数据而变得邪恶——但这就是评级的所在/reviews 和 App Store 安全策略生效。如果报告了此类应用程序，将对其进行调查。如果合适，该应用程序将从商店中删除，该应用程序将从安装它的任何设备中删除，并且开发者的 App Store 访问权限将被撤销。

Q：是否可以说click包比debs更安全，但功能更弱，因为它们受到更多限制？

A：从上面可以看出，答案并没有那么简单。单击本身可能会提供可以执行任何操作的软件。click 打包格式是有意为通用目的的，可以以多种方式使用，并且完全不特定于 Ubuntu。对于 Ubuntu，click、Ubuntu APIs、AppArmor 和 App Store 策略的组合为开发人员提供了一个非常强大的环境，可以以安全且易于使用的方式向用户交付应用程序。应用程序本身的效用取决于底层系统提供给应用程序的 API。将在 Ubuntu 的第一批出货手机上提供的初始 API 集将允许开发人员使用丰富的 API 和 SDK 创建各种有趣和有用的应用程序。