0

我试图了解什么逻辑决定了用户是否可以使用特定的 MLS 敏感级别登录。起初我怀疑 pam_selinux.so 会读取 /etc/selinux/.../seusers 文件以了解哪个用户绑定到哪个 seuser，然后将用户限制为等于或低于 MLS 范围的高分量的灵敏度。

但是，在浏览其源代码后，我发现，在询问用户是否愿意从默认上下文更改其安全上下文后，pam_selinux 通过调用内核策略来检查新的 MLS 标签是否合适。

以下代码位于 Ubuntu libpam-modules 1.1.1-4ubuntu2 包中的 modules/pam_selinux/pam_selinux.c 中。

static int mls_range_allowed(pam_handle_t *pamh, security_context_t src, security_context_t dst, int debug)
{
  struct av_decision avd;
  int retval;
  unsigned int bit = CONTEXT__CONTAINS;
  context_t src_context = context_new (src);
  context_t dst_context = context_new (dst);
  context_range_set(dst_context, context_range_get(src_context));
  if (debug)
    pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range valid for  %s", dst, context_str(dst_context));

  retval = security_compute_av(context_str(dst_context), dst, SECCLASS_CONTEXT, bit, &avd);
  context_free(src_context);
  context_free(dst_context);
  if (retval || ((bit & avd.allowed) != bit))
    return 0;

  return 1;
}

在我看来，这个检查实际上是在内核策略中检查的，在 security_compute_av() 调用中可以看到。这颠覆了我对 SELinux 登录的理解。

所以，有人可以解释一下：

  • 用户选择的登录安全级别的有效性如何确定？

  • 该逻辑在策略、pam_selinux 和内核中究竟是如何实现的？

目前，我对类型强制多重、类别安全或基于角色的访问控制不太感兴趣，因此无需解释如果这些组件不影响 MLS 敏感性，它们是如何验证的。

4

1 回答 1

2

鉴于我也分享了“SELinux 将我的大脑折叠成两半”的问题，我想我可以提供帮助。首先，您需要记住自主访问控制和强制访问控制之间的区别。您还需要记住，用户空间定义了很多东西，但内核会强制执行它们。

首先，这里是用户空间与内核空间问题的部分列表：

  • 用户空间定义了一个有效的用户 ID，内核创建由该用户 ID 拥有的进程（数字，而不是名称）
  • 用户空间将权限和所有权放在 ext3/4 文件系统上的文件上，内核根据文件 inode 和每个后续父目录 inode 强制访问该文件
  • 如果两个用户在 中共享相同的用户 ID /etc/passwd，内核将授予他们相同的权限，因为执行是通过数字标识符完成的，而不是文本标识符
  • 用户空间向另一台主机请求网络套接字，内核将该会话与同一系统上的其他会话隔离
  • 使用 SELinux，用户空间通过定义角色、登录名和用户semanage，内核将它们编译成大型访问向量缓存 (AVC)，以便它可以强制执行基于角色的访问控制和强制访问控制
  • 同样在 SELinux 下，安全管理员可以semanage用来定义最小和最大安全上下文。如果您处于多级安全 (MLS) 配置中，并且在登录期间，用户选择了一些上下文，那么内核会针对 AVC 进行测量以确定它是否被允许。

采用多级安全配置可能有助于实现这一点。我参加了 SELinux 课程，我们接触了大约两个小时。大多数人不想去那里。曾经。我一直在使用 MLS 配置，所以我理解您所追求的编码决策背后的原因，但我同意修补 MLS 是一种非常痛苦的方式来理解 PAM 如何以及为什么像它一样工作。

自主访问控制 (DAC) 是用户空间（尤其是非 root 用户）可以定义谁可以访问他们控制的数据以及以何种方式访问​​的地方。想想文件权限。因为用户控制它，所以允许一个用户查看另一个用户拥有的进程和/或文件所需的工作量很小。通常，我们不太在意，因为优秀的管理员会假设任何一个用户都可能破坏整个盒子，因此所有用户都受到同等信任。这可能是很少的信任，但仍有一定程度的信任。

强制访问控制 (MAC) 是不信任用户空间的地方。并非所有用户都是平等的。从非 MLS 的角度来看，考虑在同一硬件上拥有 Web 服务器和数据库服务器的情况（它永远不会在 Slashdot 效应中幸存）。这两个进程唯一一次通信是通过 TCP 上的专用连接通道。否则，他们甚至不知道对方的存在。我们将在两种不同的上下文中操作它们，内核将强制分离。除非您更改上下文，否则即使以 root 身份查看进程表或在硬盘驱动器周围徘徊也不会让您更接近。

在 MLS 配置中，我无法告诉您有多少次尝试获取敏感性和上下文的随机组合，却因为选择无效组合而被拒绝。这可能会非常令人沮丧，因为您需要对现有策略（Red Hat 5 下的策略）进行大量探索/etc/selinux/才能/src/policy/policy知道它允许什么或不允许什么。

在 Strict 配置下，我可以清楚地看到为什么所有这些都是矫枉过正的。这仅仅是因为 SELinux对于简单的情况来说太过分了。尽管它还有其他功能可以部分赎回它，但其中最主要的是细粒度的访问控制，它强制执行管理员设置的权限。使用最多的一个领域是将服务守护程序限制为仅需要它们的基本访问权限。设置一个新的守护进程很痛苦，但它可以防止像共享库利用这样的琐碎利用进一步发展，因为有问题的进程可能被分配给一个角色，它不会让它运行非守护进程命令，比如/bin/lsshell . 在这些情况下，漏洞利用对你没有多大好处。

于 2011-04-11T03:28:32.770 回答