openSUSE:安全文档

安全

openSUSE 发行版相关的安全文档。

权限包

目的

permissions 包是 SUSE 特有的包，用于控制发行版中许多全局系统文件和安全敏感软件包的权限设置。它关注以下类型的基于文件或目录的权限：

文件的传统 UNIX 文件所有者和组分配。
传统的 UNIX 用户/组/世界访问权限位。
特殊文件模式位，如 setuid 和 setgid 位或 sticky 位。
能力位。

这些设置对于整体系统安全非常重要。例如，配置不当的 /tmp 目录可能会导致安全问题。此外，文件上的 setuid、setgid 和能力位授予程序特殊权限。SUSE 安全团队试图尽可能减少此类程序的数量。由于将用户体验与最大安全性结合起来并不总是可行的。

可用配置

为了让系统管理员更好地控制设置，permissions 包提供了可以配置的不同配置：

easy 配置侧重于易用性，更多的程序功能开箱即用，无需用户干预。这也意味着更大的安全攻击面。它可以用于典型的单用户桌面系统，当可用性优先于更严格的安全时。
secure 配置更注重安全性，并禁用某些程序权限。这可能会导致某些程序功能不可用或行为不方便。它可以用于典型的服务器或多用户主机。
paranoid 配置是一组严格锁定的设置，在生产环境中完全不可用，因为许多程序功能将停止工作。只有当安全性是主要要求并且您愿意将配置调整到可以完成系统任务的状态时，才应使用此配置。

您可以在 /usr/share/permissions/ 中查找不同的配置，文件分别名为 permissions.easy、permissions.secure 和 permissions.paranoid。

文件格式

这些文件的结构是基于行的，每行非注释行具有以下格式：

/path/to/file    <owner>:<group>    <octal-mode>

配置自定义

预定义的配置设置不应由系统管理员编辑。要自定义单个文件权限，可以使用文件 /etc/permissions.local。在此文件中找到的条目将覆盖预定义配置中定义的条目。但是，您应该只在了解影响的情况下才执行自定义。错误的权限设置很容易破坏您的系统或系统的安全性。

配置自定义不会立即生效。您需要运行 `ckstat` 才能使其生效。有关更多信息，请参阅下文。

更改活动配置

活动的 permissions 配置在配置文件 /etc/sysconfig/security 中配置。其中变量 PERMISSIONS_SECURITY 确定活动配置。但是，更改此变量的内容不会立即进行更改。当前配置在安装或更新需要特殊权限的软件包时隐式应用。您也可以通过调用 permctl 显式应用当前配置的配置：

permctl --system

permctl 命令还有许多其他选项，允许您检查在不实际更改任何内容的情况下会发生什么。

polkit 认证框架

什么是 Polkit？

polkit 认证框架是 Linux 桌面中使用的机制，用于细粒度管理系统中的访问权限。

传统上，Linux 上存在着一种强大的权限分离，其中 root 用户可以执行任何操作，而普通用户只能访问定义良好的文件和接口。普通用户可以成为某个组的成员，从而扩展相应用户的特定目的的权限（例如，允许访问声音硬件的 audio 组）。但是，这种权限是固定的，不能仅在某些情况下或在特定持续时间内授予。

以普通用户身份登录时获得更高权限的常用方法是完全切换到 root 用户。这可以通过命令行中的 su 或 sudo 工具或类似图形工具（如 kdesu 和其他查询普通用户 root 密码的包装器）来实现。这种方法存在一些问题：

它是一种全有或全无的方法：新的应用程序完全以 root 身份运行，即使只需要以 root 身份执行少量操作。不必要地以 root 身份运行应用程序被认为是不良做法，可能会造成安全问题。
它缺乏灵活性：如果需要执行特权操作，则需要与普通用户共享 root 密码。同样适用于所有非特权用户，而不会考虑上下文，例如是否是本地交互式用户或远程后台用户等。

这就是 polkit 的用武之地。它允许更细粒度地管理授予系统中的权限。例如，它允许配置谁允许挂载可移动存储设备以及他们需要什么类型的授权。详细说明其工作原理如下节所述。

典型的认证流程

为了实现细粒度的 Polkit 认证，通常在后台运行一个小型特权服务（一个守护进程），普通用户可以与之通信。在 Polkit 中定义了不同的活动，称为动作，可以单独配置。一个动作首先是一个唯一的名称，可以是 org.freedesktop.hostname1.set-hostname。因此，现在一个非特权程序可以请求一个特权服务来执行动作 org.freedesktop.hostname1.set-hostname。非特权程序还可以传递其他参数，例如在这种情况下要设置的系统hostname。

现在由后台服务来确定非特权程序是否允许执行请求的操作。后台服务使用 Polkit 框架来找到答案。为此，Polkit 框架区分三种不同的用户上下文：

allow_active：这指的是登录到本地的，在活动本地会话中运行的用户。活动会话意味着您已登录到图形桌面环境，例如。这是最可信的用户上下文，因为它指的是可能坐在机器前的交互式用户。
allow_inactive：这基本上与 allow_active 上下文相同，但指的是当前未处于活动状态的用户会话。它可能意味着终端已切换到文本模式（例如通过 ctrl-alt-f1），并且认证请求仍然来自图形用户会话。另一种情况可能是用户已在图形模式下切换到另一个用户。
allow_any：这是最弱的用户上下文，指的是任何其他用户，例如远程登录的用户（SSH、VNC）或其他不相关的程序。

对于这些上下文中的每一个，Polkit 都配置了一个授权设置。可用的设置如下：

auth_admin：这意味着请求用户需要输入管理员（即 root）密码才能认证该动作。
auth_admin_keep：这与 auth_admin 类似，但如果同一用户程序稍后再次请求相同的动作，则初始认证将被缓存，无需再次输入密码。
auth_self：这意味着请求用户需要再次输入自己的密码才能认证该动作。
yes：这意味着无需进一步的认证要求即可授予该动作。
no：这意味着永远不会授予该动作。

有了这些信息和配置，Polkit 执行以下操作：

它确定认证请求来自哪个用户上下文，例如，如果您登录到常规桌面环境并触发 Polkit 认证，则用户上下文将为 allow_active。
它确定此用户上下文的配置设置。根据其值，特权操作将立即授予（yes），或者将出现密码提示（auth_self、auth_admin）。在后一种情况下，只有成功输入密码后才能授予特权操作。最后，特权操作可能会立即被拒绝（no）。
此决策过程的结果将报告回 Polkit 的特权服务，并且特权服务仅在 Polkit 授权后才会执行特权操作。

因此，正如我们从 Polkit 中看到的，它并不自行行动，而总是代表系统中的其他支持 Polkit 的程序。有许多程序提供 Polkit 支持，例如 systemd、NetworkManager、libvirt 等。

配置 Polkit 设置

不幸的是，Polkit 框架的配置并不容易。涉及多种不同的机制。首先，使用 Polkit 的单个软件包会运送所谓的 policy 文件，这些文件可以在系统目录 /usr/share/polkit-1/actions 中找到。这些策略文件是 XML 文档，定义了各种 Polkit 动作及其授权设置。这是 org.freedesktop.hostname1.policy 文件中的一个片段：

<action id="org.freedesktop.hostname1.set-hostname">
    <description gettext-domain="systemd">Set host name</description>
    <message gettext-domain="systemd">Authentication is required to set the local host name.</message>
    <defaults>
        <allow_any>auth_admin_keep</allow_any>
        <allow_inactive>auth_admin_keep</allow_inactive>
        <allow_active>auth_admin_keep</allow_active>
    </defaults>
</action>

此片段定义了 Polkit 动作 org.freedesktop.hostname1.set-hostname 的所有三个用户上下文（any、inactive、active）的授权要求。这些授权设置由软件包开发人员预定义，不应直接在策略文件中进行更改。

在 OpenSUSE 上，有一个 SUSE 特有的软件包，称为 polkit-default-privs，它进一步自定义了 Polkit 配置。存在三个预定义的配置 easy、standard 和 restrictive，分别在文件 /etc/polkit-default-privs.easy、/etc/polkit-default-privs.standard 和 /etc/polkit-default-privs.restrictive 中定义。在这些文件中，您将找到以下形式的行：

<action-id> <ANY-USER-AUTH>:<INACTIVE-USER-AUTH>:<ACTIVE-CONSOLE-AUTH>

例如，行 org.freedesktop.hostname1.set-hostname auth_admin:auth_admin:yes 表示对于 set-hostname 动作，其他用户上下文和非活动用户上下文的认证要求为 auth_admin，而活动用户上下文的认证要求为 yes。如果所有三个 auth 字段应具有相同的值，则该行也可以写为 org.freedesktop.hostname1.set-hostname auth_admin，而无需任何冒号分隔符。

与 permissions 包描述的类似，easy 配置适用于单用户桌面计算机，其中唯一用户始终也是系统的管理员。standard 配置是适用于多用户系统的设置的混合。restrictive 配置是最保守的 polkit 配置，主要适用于安全意识强的人员和服务器系统。

当前活动的 polkit 配置可以在 /etc/sysconfig/security 中通过配置变量 POLKIT_DEFAULT_PRIVS="..." 进行配置。但是，更改此变量不会立即生效。您需要运行程序 set_polkit_default_privs 才能重新生成活动的 Polkit 配置。

除了基线 Polkit 配置之外，您还可以通过将行输入到文件 /etc/polkit-default-privs.local 中来自定义单个 Polkit 规则。此文件不会被更新覆盖。请小心不要过度放宽设置，因为许多 Polkit 动作通常需要 auth_admin 授权，通常具有很大的威力。此文件中的设置还需要通过调用 set_polkit_default_privs 重新生成当前的 Polkit 规则。

除了 Polkit 的声明式配置文件之外，还存在运行更复杂的脚本来确定 Polkit 授权的可能性。这些脚本是用 Java Script 编写的，位于 /usr/share/polkit-1/rules.d 和 /etc/polkit-1/rules.d 中。每当需要做出授权决策时，Polkit 框架都会按字母顺序处理这两个目录中的脚本。首先返回授权决策的脚本决定结果。通过这种机制，Polkit 也允许 root 用户拥有所有权限，并且 polkit-default-privs 以这种方式实现配置支持。但是，只有高级用户才应考虑使用这种方法。

调试 Polkit

确定为什么某个 Polkit 动作需要管理员密码或突然出现某个认证窗口可能很难以理解。这是因为许多不同的组件和配置项正在相互交互。此外，开发人员在可用性方面并不总是优先考虑。本节试图提供一些关于如何了解 Polkit 正在发生的事情的指针。

Polkit 认证代理

Polkit 使用一种称为 agent 的机制，它有助于从用户那里获取密码，并向用户显示身份验证请求。这些 agent 需要在用户上下文中运行。如果您登录到像 Gnome 或 KDE 这样的完整桌面环境，那么这样的 agent 已经可用，您无需担心。当远程运行、在控制台或从轻量级桌面环境运行时，您可能需要显式启动这样的 agent。例如，对于文本模式，可以使用程序 pkttyagent。它在控制台上的使用有些笨拙，并且也不支持所有 Polkit 功能，但它是一个开始。

检查动作和测试授权

您可以使用 pkaction 工具获取有关单个 Polkit 动作的更详细信息，如下所示

$ pkaction --action-id org.freedesktop.hostname1.set-hostname --verbose
org.freedesktop.hostname1.set-hostname:
  description:       Set host name
  message:           Authentication is required to set the local host name.
  vendor:            The systemd Project
  vendor_url:        http://www.freedesktop.org/wiki/Software/systemd
  icon:
  implicit any:      auth_admin_keep
  implicit inactive: auth_admin_keep
  implicit active:   auth_admin_keep

然而，这里显示的授权设置只是在 /usr/share/polkit-1/actions 文件中定义的 供应商预设。这并未考虑 polkit-default-privs 执行的设置。

您还可以使用工具 pkcheck 检查某个进程当前是否有权执行某个 Polkit 动作

$ pkcheck --action-id org.freedesktop.hostname1.set-hostname --process $$
[...]
$ [ $? -eq 0 ] && echo "authorized"

如果当前进程被授权执行给定的动作，该工具将返回零退出代码。如果需要输入密码进行授权，则不会返回零。

调试 polkitd

Polkit 使用在后台运行的中央守护进程，称为 polkitd。此守护进程管理 Polkit 启用程序和后台服务与 Polkit agent 之间的通信，该 agent 查询密码并显示授权消息。因此，polkitd 是调试的好地方。

似乎没有配置文件来启用调试，并且默认日志消息有些稀疏。但是，您可以在 root shell 中重新启动 polkitd 以获取更多信息

root # G_MESSAGES_DEBUG=all /usr/lib/polkit-1/polkitd --replace

运行此命令将导致可能已经运行的 polkitd 实例被替换，并运行一个新的实例在前台。任何 Polkit 请求都将导致消息打印到控制台。请注意，这种方法可能会干扰正在运行的应用程序或系统中的其他用户。