怎么运行flatpak应用
Flatpak使桌面应用程序可以在隔离的沙箱中运行，这可以显着提高安全性，因为它可以防止应用程序相互影响并影响主机系统。 但是，实际上，典型的应用程序仍然需要访问在其他应用程序和主机之间共享的服务和用户数据。 尽管存在一个长期存在的问题：如何管理用户机密，但通过增强门户网站机制周围的权限可以改善这种情况。
在本文中，我们介绍了管理Flatpak应用程序用户机密的方法。 尽管大多数应用程序可以透明地利用所提出的机制，但是某些应用程序需要代码修改。 还介绍了迁移步骤。
如何在Linux桌面上管理机密
在现代Linux桌面上，大多数机密信息（密码，令牌等及其相关属性）由守护进程gnome-keyring-daemon集中管理。 应用程序通过通过D-Bus公开的Secret Service API访问此守护程序。 如果应用程序使用客户端库（例如libsecret），则将在后台进行此过程。
注意：出于相同的目的，现在有一个名为libgnome-keyring的库已过时。 请注意，尽管有名称，但libgnome-keyring是与gnome-keyring分开的项目，它不是过时的，并且仍然保持秘密管理的核心作用。
在守护程序端，机密存储在文件系统中并进行加密。 除此之外，该守护程序不过是普通的存储服务，这意味着任何应用程序都可以将数据存储在其他应用程序也可以看到的任意“路径”上。 只要我们信任所有应用程序，此模型就足够了，但它否定了Flatpak的安全性目标之一： 通过将应用程序彼此隔离来提高桌面系统的安全性 。
因此，在安装使用Secret Service API的Flatpak应用程序时，要求用户向该应用程序授予必要的权限。 在下面的示例中，您可以看到该应用程序需要访问Secret Service API（ org.freedesktop.secrets ）。 如果用户不想允许该应用程序访问该服务，则他们唯一的选择是放弃安装：
$ flatpak
install org.gnome.Epiphany
…
org.gnome.Epiphany permissions:
ipc network pulseaudio wayland
x11 dri
file access
[
1
] dbus access
[
2
]
system dbus access
[
3
]
[
1
] xdg-download, xdg-run
/ dconf, ~
/ .config
/ dconf:ro
[
2
] ca.desrt.dconf, org.freedesktop.Notifications, org.freedesktop.secrets
[
3
] org.freedesktop.GeoClue2
Proceed with these changes to the Default system installation?
[ Y
/ n
] :
这显然是不希望的结果。
本地存储方式
解决此问题的基本思想是将机密存储在应用程序端，而不是主机端（ gnome-keyring-daemon ）。 这种做法类似于GSettings的最新工作，在GSettings中 ，应用程序将设置数据存储在本地文件中，而不是在主机上运行的dconf服务中。
但是，在涉及机密时，存在一个引导问题：应用程序在将机密存储在本地文件中时必须对其进行加密，但是尚不知道加密密钥。 要为应用程序提供加密密钥，我们依赖Flatpak门户机制，该机制位于应用程序和主机之间，以使二者通过受限的接口进行通信。
我们还添加了一个新门户 ，允许应用程序检索加密密钥。 首先，应用程序向门户发送一个请求（该请求包含写入了加密密钥的Unix文件描述符）。 然后，门户网站将请求委托给gnome-keyring-daemon中的后端实现，该实现通过文件描述符为沙盒应用程序发送唯一的加密密钥。
利用接收到的加密密钥，应用程序对机密进行加密，并将其存储在应用程序数据目录（ 〜/ .var / app / $ APPID / data / keyrings ）中，该目录已绑定安装，并且可以从主机和沙箱访问。
libsecret API
libsecret项目提供了两组不同的API。 一种是简单的API ，另一种是完整的API 。 前者提供了更简单，无状态的操作来检索和存储机密信息，而后者则提供了更完整的面向对象的API，该API将D-Bus接口映射到C API。
仅简单API支持本地存储。 如果您的应用程序已经在使用简单的API，则在Flatpak下运行时，它们将自动使用本地存储。 否则，要启用本地存储，需要将应用程序移植到简单的API。 以Epiphany中的迁移补丁为例。
两种API集之间的区别也使应用程序可以退出使用本地存储。 例如，如果您的应用程序是密码管理器，需要对用户密钥环的完全访问权限，则可以使用完整的API绕过本地存储。
密钥环格式
尽管理想情况下，我们应该能够对本地存储和gnome-keyring-daemon使用相同的密钥环格式，但我们意识到gnome-keyring-daemon使用的密钥环格式有局限性。 包括相关属性在内的秘密将作为单个块进行加密，这意味着它们可以消耗不必要数量的锁定内存。 同样，对属性进行散列而不使用密钥，这意味着可以猜测文件中存储了哪些秘密。
因此，我们决定在两个位置实现新格式的密钥环文件格式，而不是在两个地方实现，而是具有以下特征：秘密被单独加密，属性哈希现在是属性上的消息认证代码（MAC） 。
这种新格式基于该 GVariant序列化格式 ，除了标题，而这种变化使我们能够重用大部分的代码进行编码，解码和查找。
Flatpak秘密管理的下一步是什么
必要的补丁程序（当前）仅在相关组件（ xdg-desktop-portal ， gnome-keyring和libsecret ）的Git存储库中可用。 它们将包含在GNOME 3.36之前的下一版本中。
如果您是开发人员，则在此方面仍有改进的余地。 在此将不胜感激您的帮助：
会话密钥环： Secret Service API支持“会话”密钥环，仅在用户会话期间有效。 本地存储后端尚不支持此功能。 可以使用Linux内核中的会话密钥环来实现此代码。
管理和备份应用程序：应用程序机密现在存储在多个位置，而不仅仅是主机密钥环。 如果有一个用于管理应用程序机密和进行备份的工具，将非常有用。 通过增强GNOME的Seahorse来查看应用程序的机密，应该可以实现此过程。
在线帐户门户：如今，将Web应用程序与基于Web的访问委派协议（例如OAuth 2.0）集成在一起是很常见的。 gnome-online-accounts支持这些协议，后者依次使用gnome-keyring-daemon来存储令牌。 在线帐户的门户界面对于限制每个应用程序的访问非常有用。
新密钥环格式的更广泛采用：尽管新格式具有多个优点，但目前仅由libsecret在应用程序端使用。 如果主机端的gnome-keyring-daemon也使用相同的格式，那将是有益的。
强化重新安装过程：默认情况下，应用程序的密钥环文件（ 〜/ .var / app / $ APPID / data / keyrings ）与其他数据一起保留。 如果应用程序ID被不受信任的发布者重用，则这种持久性很容易受到攻击。 当前，我们建议使用--delete-data选项以确保删除了此类应用程序数据。 如果发布者的ID与该应用程序相关联，则可以改进此过程。
摘要
本文介绍了一种为Flatpak应用程序提供用户密码的机制。 该机制是根据以下原则设计的：
- 最小化主机界面。
- 让应用程序通过Flatpak门户与主机交互。
- 以通用数据格式存储应用程序数据。
尽管该机制是透明的，但只要您使用libsecret ，就只能通过libsecret的简单API启用该机制。 为了顺利过渡，我们建议将应用程序迁移到此API。 GUADEC演示文稿（ 幻灯片 ， 录音 ）中提供了有关项目背景和设计原理的更多信息。
翻译自: https://opensource.com/article/19/11/secrets-management-flatpak-applications
怎么运行flatpak应用
539
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
